Announcement

Collapse
See more
See less

RESOURCE$ function use with PB Forms 2.0 generated application

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • RESOURCE$ function use with PB Forms 2.0 generated application

    I have been using PBForms 2.0 with PBWin 10.4 and was looking for a way to automatically tie the PB Forms Version Editor version info to label text in an "About" dialog. I came across the "New" RESOURCE$ function in the PBWin help file (it also appears in PBCC 6.04), but I have not been able to get the function to work. The compiled exe file properties list the version info set by the Version Editor until any modification or addition is made to the #RESOURCE metastatement(s) in the .bas file. The function itself returns a zero-length string.

    Has anyone used this function successfully with a PBForms Version Editor-produced resource file? Looking for a clue...

  • #2
    From Help for #RESOURCE
    .. RES and PBR resources cannot be mixed with any other resources. Once you add a PBR or RES resource, you cannot add any other #RESOURCE metastatements in your program.
    PBForms uses .pbr file, while you're trying to add new #RESOURCE statements. Will not work! Either make the resource edits in PBForms (or other method in .pbr), OR move all items from the .pbr to new #RESOURCE statements in the .bas.

    Cheers,
    Dale

    Comment


    • #3
      #RESOURCE statements are not supported by PBForms 2.0. You can place them in the generated code in a PBWin version that supports them, so long as they are not inside a PBForms tagged block. You would also need to remove or comment out the #RESOURCE meta statement PBForms adds that points to a .PBR.

      As far as tying the PBForms version to your code in an about dialog, that would need to be done manually in the code. You've probably noticed the #PBFORMS CREATED V2.01 line at the top your code processed by PBForms. This is used by PBForms to make sure your code is current when you load it either directly or in the interactive mode with the F7 hotkey. When the code is from an earlier version, PBForms asks if you want to upgrade the code. Hopefully this will be the case in future versions of this visual designer. But if you still want it in an about box, this would be a manual task. I'd suggest using a string equate with the version info that would then be easily editable for future version as desired.
      Last edited by Richard Angell; 14 Feb 2017, 07:04 PM. Reason: corrections in paragraph 1
      Rick Angell

      Comment


      • #4
        Thank you Richard and Dale. You have confirmed what I have concluded from my extended attempts to avoid a little typing. I just thought it would be neat if the PBForms Version Editor inclusions could be accessed through the RESOURCE$ function. Maybe in a future incarnation?

        Comment


        • #5
          PBForms 2 was designed to work with PBWin 8 and 9. PBWin 10 (and PBCC 6) has improvements and additions in the resource area. If Mr. Z. had the chance, I'd bet PBForms 3 would have worked better with those changes.
          Dale

          Comment


          • #6
            [It would be] neat if the PBForms Version Editor inclusions could be accessed through the RESOURCE$ function.
            I'm not a PBForms user, but...


            If "PBFORMS.EXE" or whatever the executable file is called has a version resource, you could read it using conventional resource functions.

            I would not hold my breath for this because neither PBEDIT.EXE nor PBWIN.EXE uses version resources. (Truth is stranger than fiction!)

            But it's worth a quick check. I have a function here somewhere to read a version resource in another executable file.. yeag, ghere is is..

            Code:
            ' get version of any file
            ' removed leading space from major 8/24/07
            FUNCTION FileVersionString(szFile AS ASCIIZ) AS STRING
              LOCAL major AS LONG, Minor AS LONG, Build AS LONG, SubBuild AS LONG
              LOCAL ResSize AS LONG
              LOCAL ffi  AS VS_FIXEDFILEINFO PTR
              LOCAL  ret AS LONG
              LOCAL Buffer AS STRING, DLLDate AS STRING
            
              Major=0: Minor = 0:  Build = 0
            
              ResSize = GetFileVersionInfoSize (szFile, ret)
              IF ResSize= 0 THEN
                FUNCTION = "No Version Info"
                EXIT FUNCTION
              END IF
            
              Buffer = SPACE$(ResSize)
              Ret =  GetFileVersionInfo(szFile, %NULL, ResSize, BYVAL STRPTR(Buffer))
            
            ' ** Read the VS_FIXEDFILEINFO info
              VerQueryValue BYVAL STRPTR(Buffer), "\", ffi, SIZEOF(@ffi)
              Major        = @ffi.dwProductVersionMs  \ &h10000
              Minor        = @ffi.dwProductVersionMs MOD &h10000
              Build        = @ffi.dwProductVersionLS MOD &h10000  ' this is for MY software which uses VERSION_MAJOR, VERSION_MINOR, 0, VERSION_BUILD under FILEVERSION
            '  SubBuild     = @ffi.dwProductVersionLS \  &h10000
              ' combine
            
            ' 8/24/07 WAS:
              FUNCTION = STR$(Major) & "." & TRIM$(STR$(Minor)) & "." & LTRIM$(STR$(Build))   ' & "." & LTRIM$(STR$(SubBuild))
            ' changed to: (to remove leading space)
              FUNCTION = FORMAT$(Major) & "." & FORMAT$(Minor) & "." & FORMAT$(Build)   ' & "." & FORMAT$(SubBuild)
            
            
            END FUNCTION
            ' --------------------------------------------------------------------
            NOTE: I don't use the conventional version number fields so adjust for your needs.

            MCM




            Michael Mattias
            Tal Systems Inc.
            Racine WI USA
            mmattias@talsystems.com
            http://www.talsystems.com

            Comment


            • #7
              Thanks for the example, Michael. I had already arrived at the MSDN pages covering GetFileVersionInfoSize and GetFileVersionInfo functions. You guys are a terrific RESOURCE!

              Comment


              • #8
                Hi John,

                See Terry Webb's post for an example of how to use VersionInfo data in your app without needing to extract it with the GetFileVersionInfo API.

                You'll need to prevent PBForms adding a .pbr statement to your source by changing the Code Options in the Code Generation tab of it's Options dialog.

                You can continue to use Themed Dialogs and Controls ("Use XP/Vista Look/Feel") by adding a #RESOURCE MANIFEST statement outside of the #PBForms Begin/End Includes code block.

                (The XP look won't to be applied to dialogs and controls while in design mode, whatever the setting in the General tab of the Options dialog).
                Rgds, Dave

                Comment


                • #9
                  See Terry Webb's post for an example of how to use VersionInfo data in your app without needing to extract it with the GetFileVersionInfo API.
                  That's nice BUT... using the PB intrinsic RESOURCE functions only works for THIS executable. The GetFileVersionInfoxxx functions retrieve the info for EXTERNAL files.

                  Regardless, I was struck by this...
                  Code:
                  #RESOURCE VERSION$       "My Custom String", "Add your own string ..."
                  The doc for the #RESOURCE VERSION$ statement says...
                  Finally, you will add one or more of the string version metastatements, to provide extensive information about the file. The first string literal parameter chooses one of the following predefined names. ...
                  That would seem to preclude the use of "My Custom String" as the first literal. And, I thought I had tried using my own string anyway and found it did not work. I guess I had better try that again, and if it really does work I'll put a note in the Doc forum about it.

                  That is my biggest impediment to using the #RESOURCE functions... as I'd like to include..

                  Code:
                  #RESOURCE VERSION$     "Compiler" , "PB/Windows 9.0.5"
                  ... so one can tell which version of the compiler was used to create the executable; this has been important to me because I have frequently gone literally years between maintenance sessions. Right-click, properties, version is a whole lot quicker than digging thru the libraries (code and paper) to figure out which tool I need to use today.

                  Using a *.RC script file + RC.EXE + PBRES.EXE to add this literal to the version info was the only way I could do it.. except maybe now there actually is "another way."

                  MCM
                  Last edited by Michael Mattias; 16 Feb 2017, 10:57 AM.
                  Michael Mattias
                  Tal Systems Inc.
                  Racine WI USA
                  mmattias@talsystems.com
                  http://www.talsystems.com

                  Comment


                  • #10
                    Dave,
                    Originally posted by Dave Biggs View Post
                    You'll need to prevent PBForms adding a .pbr statement to your source by changing the Code Options in the Code Generation tab of it's Options dialog.
                    There is no option to enable or disable pbr compilation in PBForms 2.0. The option exists in PBEdit settings for the compiler. Turning this option off after deleting the subject pbr file leads to a "Resource file error" when attempting to compile the subject app.

                    Terry Webb's example is helpful by providing a compilable, working example of usage of the PB #RESOURCE metastatements.

                    The PBForms' Version Editor string info keys are apparently hard coded and not subject to alteration. I manually modified the PBForms-produced rc file with Michael's proposed "Compiler" entry as the last in the block, compiled res and pbr files manually and then compiled the exe using PBEdit; right-clicked the exe file in Explorer and clicked properties. The version info showed the new value plus all the others (appaarently alphbetically sorted). However, reopening the app code in PBForms stripped the addition.

                    Using Michael's FileVersionString function gives me what I was looking for when called thus:

                    Code:
                    sVer = FileVersionString(EXE.NAMEX$)

                    Comment


                    • #11
                      If you want the version string for "this executable" you don't need "FileVersionString" (although you can use it)... you only need this one..

                      Code:
                      ' Get version string of current Executable. Use FileVersionString to get for another file.
                      ' return program version string from resource file as "Major.minor build nnnn"
                      ' changed 5/27/03 to return major.minor.build, build used to be format$=0000, now it's just
                      ' a number. e.g., was "2.2 Build 0003" now is "2.2.3"
                      ' STANDARD PROGRAM VERSION STRING  format: major.minor.build
                      
                      FUNCTION ProgramVersionString() AS STRING
                      
                        LOCAL major AS LONG, Minor AS LONG, Build AS LONG
                        LOCAL szFile AS ASCIIZ * %MAX_PATH
                        LOCAL ResSize AS LONG
                        LOCAL ffi  AS VS_FIXEDFILEINFO PTR
                      
                        LOCAL  ret AS LONG
                        LOCAL Buffer AS STRING, DLLDate AS STRING
                      
                        Major=0: Minor = 0:  Build = 0
                      
                        GetModuleFileName BYVAL %NULL, szFile, SIZEOF(szFile)
                        ResSize = GetFileVersionInfoSize (szFile, ret)
                        IF ResSize= 0 THEN
                          FUNCTION = "Error"
                          EXIT FUNCTION
                        END IF
                      
                        Buffer    = SPACE$(ResSize)
                        Ret       = GetFileVersionInfo(szFile, %NULL, ResSize, BYVAL STRPTR(Buffer))
                      
                      
                      
                      ' ** Read the VS_FIXEDFILEINFO info
                        VerQueryValue BYVAL STRPTR(Buffer), "\", ffi, SIZEOF(@ffi)
                        Major      = @ffi.dwProductVersionMs  \ &h10000
                        Minor      = @ffi.dwProductVersionMs MOD &h10000
                        Build      = @ffi.dwProductVersionLS
                      
                        FUNCTION = LTRIM$(STR$(Major)) & "." & TRIM$(STR$(Minor)) & "." & LTRIM$(STR$(Build))
                      
                      END FUNCTION
                      Or, if you want to get the same thing for a DLL your process has loaded..

                      Code:
                      ' --------------------------------------------------------------------
                      '  GET THE VERSION STRING FOR A LOADED FILE GIVEN ITS INSTANCE HANDLE
                      '  THis is the same as ProgramVersion string except it uses hLib
                      '  to get the file name instead of BYVAL %NULL)
                      '  Added 9.22.08
                      ' ----------------------------------------------------------------------
                      
                      FUNCTION hInstanceVersionString (BYVAL hlIb AS LONG) AS STRING
                      
                            LOCAL major AS LONG, Minor AS LONG, Build AS LONG
                        LOCAL szFile AS ASCIIZ * %MAX_PATH
                        LOCAL ResSize AS LONG
                        LOCAL ffi  AS VS_FIXEDFILEINFO PTR
                      
                        LOCAL  ret AS LONG
                        LOCAL Buffer AS STRING, DLLDate AS STRING
                        Major=0: Minor = 0:  Build = 0
                      
                        GetModuleFileName BYVAL hLib, szFile, SIZEOF(szFile)
                        ResSize = GetFileVersionInfoSize (szFile, ret)
                        IF ResSize= 0 THEN
                          FUNCTION = "Error"
                          EXIT FUNCTION
                        END IF
                      
                        Buffer    = SPACE$(ResSize)
                        Ret       = GetFileVersionInfo(szFile, %NULL, ResSize, BYVAL STRPTR(Buffer))
                      
                      ' ** Read the VS_FIXEDFILEINFO info
                        VerQueryValue BYVAL STRPTR(Buffer), "\", ffi, SIZEOF(@ffi)
                        Major      = @ffi.dwProductVersionMs  \ &h10000
                        Minor      = @ffi.dwProductVersionMs MOD &h10000
                        Build      = @ffi.dwProductVersionLS
                      
                        FUNCTION = LTRIM$(STR$(Major)) & "." & TRIM$(STR$(Minor)) & "." & LTRIM$(STR$(Build))
                      
                      END FUNCTION
                      These are all very, er, um, "Mature" procedures....from the comments at the start of my file containing all my "commonly-used-functions" ...

                      Code:
                      '   Original created 4/13/01.
                      '   Added and significantly upgraded for PB DLL 6.11  June 2002 ( 6/02/02 - 6/7/02)
                      '   Move to PB/Win 7.0 folder 7/26/02
                      '   08/20/02 Add function FileInformation (formatted date/time/size)
                      '   10/25/02 Add function GetTempWorkFileName (szTempFileName) (calls API GetTempFileName)
                      '   12/17/02 Add function ProgramVersionString ("major.minor.build", this module)
                      ' .... 
                      '   03/10/04 Added function fileversionstring (szFile)
                      MCM
                      Michael Mattias
                      Tal Systems Inc.
                      Racine WI USA
                      mmattias@talsystems.com
                      http://www.talsystems.com

                      Comment


                      • #12
                        Originally posted by Michael Mattias View Post

                        I would not hold my breath for this because neither PBEDIT.EXE nor PBWIN.EXE uses version resources. (Truth is stranger than fiction!)
                        This is the second time recently that you've said PBEDIT.EXE doesn't use version resources. And the second time I've posted a screen shot of the Version info: Click image for larger version

Name:	PBEditVerInfo.jpg
Views:	1
Size:	29.6 KB
ID:	758210

                        --
                        [URL="http://www.camcopng.com"]CAMCo - Applications Development & ICT Consultancy[/URL][URL="http://www.hostingpng.com"]
                        PNG Domain Hosting[/URL]

                        Comment


                        • #13
                          My bad, it's only the COMPILER (PBWIN.EXE) which does not have version resource. PBEDIT.EXE (the editor) does use a version resource.

                          For the compiler, PB uses the file "last modified" timestamp as the "version indicator." A time of "10:04 AM" EST means version 10.0.4
                          Michael Mattias
                          Tal Systems Inc.
                          Racine WI USA
                          mmattias@talsystems.com
                          http://www.talsystems.com

                          Comment


                          • #14
                            Hi John,

                            The #RESOURCE metastatements available in PBWin10 can be added to source code generated by PBForms.

                            However, PBHelp tells us "RES and PBR resources cannot be mixed with any other resources.
                            Once you add a PBR or RES resource, you cannot add any other #RESOURCE metastatements in your program".

                            There is no option to enable or disable pbr compilation in PBForms 2.0. The option exists in PBEdit settings for the compiler.
                            Turning this option off after deleting the subject pbr file leads to a "Resource file error" when attempting to compile the subject app.
                            That option in PBEdit is for compiling the .rc script - either to a .PBR file OR to a .RES file only.
                            If the option is turned off, using the RC compiler in PBEdit will generate a '.res' file in the subject app folder.

                            If the source code in the .bas file is still pointing to a '.pbr' file that doesn't exist, there will be an Error when trying to compile the executable. The error message will normally indicate which line caused it.

                            Please note.
                            If there are any PBForms code blocks in 'TestApp.rc' then #Resource "TestApp.pbr" is automatically added to 'TestApp.bas', in the 'PBForms Includes' block.

                            1. By default, PBForms will create new Programs with 'Themed' dialogs.
                            A 'PBForms Manifest' block is added to 'TestApp.rc'. (At the same time a file "XPTheme.xml" is created in the TestApp folder).

                            This behaviour is optional, it can be prevented by clearing the 'Add XP/Vista Look/Feel' check box in PBForms Options:
                            Menu/Tools/Options - Code Generation tab - Code Options section.

                            2. Anytime you access the Version Info Editor (Ctrl+Shift+V) in PBForms design mode, a 'PBForms VersionInfo' block is added to 'TestApp.rc'.
                            The only way to remove the VersionInfo block from the resource script is manually in PBEdit (or some other editor) it can't be removed from within PBForms.

                            3. If you add a Menu using the PBForms Menu Editor (Ctrl+Shift+M) AND add text in the 'Prompt' field a 'PBForms String Table' block is added to 'TestApp.rc'.
                            Deleting all text in the "Prompt' field of the Menu Editor dialog will remove the 'String Table' block from 'TestApp.rc'.

                            If all PBForms code blocks in 'TestApp.rc' are deleted, the #Resource "TestApp.pbr" statement is removed from the 'TestApp.bas', automatically By PBForms.

                            You can check the DDT and RC code via the PBForms View Menu while making changes, to see what the data will look like when eventually saved.
                            Rgds, Dave

                            Comment


                            • #15
                              Originally posted by Michael Mattias View Post

                              That's nice BUT... using the PB intrinsic RESOURCE functions only works for THIS executable. The GetFileVersionInfoxxx functions retrieve the info for EXTERNAL files.

                              Regardless, I was struck by this...
                              Code:
                              #RESOURCE VERSION$ "My Custom String", "Add your own string ..."
                              The doc for the #RESOURCE VERSION$ statement says...


                              That would seem to preclude the use of "My Custom String" as the first literal. And, I thought I had tried using my own string anyway and found it did not work. I guess I had better try that again, and if it really does work I'll put a note in the Doc forum about it.

                              That is my biggest impediment to using the #RESOURCE functions... as I'd like to include..

                              Code:
                              #RESOURCE VERSION$ "Compiler" , "PB/Windows 9.0.5"
                              ... so one can tell which version of the compiler was used to create the executable; this has been important to me because I have frequently gone literally years between maintenance sessions. Right-click, properties, version is a whole lot quicker than digging thru the libraries (code and paper) to figure out which tool I need to use today.

                              Using a *.RC script file + RC.EXE + PBRES.EXE to add this literal to the version info was the only way I could do it.. except maybe now there actually is "another way."

                              MCM
                              In a previous post, I mentioned that ANY string could be used. You replied that you had never tried it as it was not documented as such and, I believe, assigned this a documentation bug.
                              I am far too lazy to try to find it again.

                              Cheers, Mike.
                              There are only two speeds for computers: fast enough, and too bloody slow.
                              And there are 10 types of programmer -- those that know binary, and those that don't.

                              Comment


                              • #16
                                Right-click, properties, version is a whole lot quicker than digging thru the libraries (code and paper) to figure out which tool I need to use today.
                                Any string can be used and will show up in Right-Click, Properties, Version in WinXP. Unfortunately Win7 and above Properties, Details shows a lot fewer infos & no custom items
                                Rgds, Dave

                                Comment


                                • #17
                                  Originally posted by Dave Biggs View Post
                                  Any string can be used and will show up in Right-Click, Properties, Version in WinXP. Unfortunately Win7 and above Properties, Details shows a lot fewer infos & no custom items
                                  That explains it. I've tried a custom string a few times and had no success, but never used XP to view the result.
                                  --
                                  [URL="http://www.camcopng.com"]CAMCo - Applications Development & ICT Consultancy[/URL][URL="http://www.hostingpng.com"]
                                  PNG Domain Hosting[/URL]

                                  Comment


                                  • #18
                                    it would be neat if the PBForms Version Editor inclusions could be accessed through the RESOURCE$ function. Maybe in a future incarnation?
                                    While waiting for the next version of PBForms..

                                    RESOURCE$ can't access data in the VersionInfo Block generated by PBForm Version Editor.
                                    As another option, it is possible for you to add a Stringtable to the .rc file manually - which RESOURCE$ can access.
                                    Code:
                                    // .rc file
                                    ..
                                    //#PBForms End VersionInfo
                                    
                                    #define FileVer  601
                                    
                                    STRINGTABLE
                                    BEGIN
                                        FileVer, "1.00.0001\0"
                                    END
                                    
                                    
                                    ' .bas file
                                    ..
                                    #PBForms End Constants
                                    
                                    %FileVer = 601
                                    ..
                                    
                                    Control Set Text Cb.Hndl, %IDC_LABEL1, "FileVersion: " + Resource$(String, %FileVer)
                                    Rgds, Dave

                                    Comment

                                    Working...
                                    X