8 Replies Latest reply on Feb 18, 2013 12:59 PM by RonSmithMD

    Odd Get (InstalledFMPlugins) Behavior

    RonSmithMD

      Just in the last couple of days have I implemented the new plug-in updating process to streamline client support for PaperCutPro, my EMR/Practice management software. There is an odd behaivor or perhaps even a bug in the Get (InstalledFMPlugins) routine worth knowing about and which I don't recall being documented in the discussions. I have not found this in the FileMaker documentation either that I have seen so far.

       

      My solution has a startup script set for the OnFirstWindowOpened File Option script trigger. I implement a Startup Plugin Check script as part of that startup routine which compares a plugin table in the database with the plugins returned by the Get (InstalledFMPlugins) function.

       

      The odd thing is that the results of the Get (InstalledFMPlugins) is different when it runs as part of this triggered startup script as opposed to when it is run after the startup script has finished and during user interaction with the solution. Here is what I see when I do a Get (InstalledFMPlugins) after the startup has run and completed.

       

      2empowerFM Developer Assistant v2.67;2.67.2.0;Enabled

      2empowerFM v2.37;2.37.2.0;Enabled

      360Works Plastic;1.84;Enabled

      FaxPack;7.6;Enabled

      FMGrowler;1.0.2;Enabled

      InsideScan;2.5a16;Enabled

      myFMbutler PrinterSwitch;2.1.0;Enabled

      SMTPit Pro;SMTPit Pro 4.1.13;Enabled

      Troi Activator Plug-in;3.1;Enabled

      Troi Dialog Plug-in;5.5.7;Enabled

      Troi Encryptor Plug-in;1.0;Enabled

      Troi File Plug-in;6.1.1;Enabled

      Troi Serial Plug-in;3.2;Enabled

      Troi Text Plug-in;1.0;Enabled

      Troi URL Plug-in;3.0;Enabled

      Web Publishing;12.0v3;Disabled

      xDBC Data Access Companion;12.0.3;Disabled

      xmCHART;3.4.6;Enabled

       

      Yet here is what the function returns during startup as verified using the Script Debugger.

       

      2empowerFM Developer Assistant v2.67;2.67.2.0;Enabled

      2empowerFM v2.37;2.37.2.0;Enabled

      360Works Plastic;1.82;Enabled

      FaxPack;7.6;Enabled

      FMGrowler;1.0.2;Enabled

      InsideScan;2.5a16;Enabled

      myFMbutler PrinterSwitch;1.7.1.0;Enabled

      SMTPit Pro;SMTPit Pro 4.1.13;Enabled

      Troi Activator Plug-in;3.1;Enabled

      Troi Dialog Plug-in;5.5.7;Enabled

      Troi Encryptor Plug-in;1.0;Enabled

      Troi File Plug-in;6.1.1;Enabled

      Troi Serial Plug-in;3.2;Enabled

      Troi Text Plug-in;1.0;Enabled

      Troi URL Plug-in;3.0;Enabled

      Web Publishing;12.0v3;Disabled

      xDBC Data Access Companion;12.0.3;Disabled

      xmCHART;3.4.6;Enabled

       

      The two plugins that I would call your attention to are 360Works Plastic and myFMbutler PrinterSwitch. The reason that I had noticed these two first was when I checked the the user extension space where FileMaker Pro puts updated versions of the plugins as dictated by the plugins I have stored in the Plugins tabe, these two were repeatedly being replaced and the previous copies put into the Saved folder within the user extension space.

       

      After a little more investigation, I found that I have indeed the older versions of 360Works Plastic and myFMbutler PrinterSwitch in the FileMaker Pro extensions folder than I do in the user's extension folder.

       

      What this means is that during the triggered startup script the Get (InstalledFMPlugins) does not check the user extension space at all! Whether this is a bug or by necessity or design, I don't know, but it is something you need to know if you too are implementing an autoupdate of plugins as I am. The practical implications for me are that my routine would repeatedly download at startup any newer versions of the plugins if there were older versions present in the extensions folder contained in the FIleMaker Pro application folder itself. This seems not only a wast of bandwidth, but possibly a source of odd FileMaker Pro behavior or maybe even crashes. I won't be able to assess that untill this next week when the routines are deployed.

       

      The safest way I see to avoid this is to make sure that if you implement plugin autoupdating by the new FileMaker Pro 12 methods, that you ensure that all the non-default FileMaker Pro plugins are not present in the application's extension folder.

       

      Feedback and comments?

       

      Ron Smith, MD, http://www.ronsmithmd.com

      PaperCutPro, http://www.papercutpro.com

        • 1. Re: Odd Get (InstalledFMPlugins) Behavior
          psijmons

          This is what the FMI documentation says:

           

          • The "Install Plug-In File" script step supports the new location only.
          • Plug-ins installed in the old location still work and take precedence of ones stored in the new location. This is due in part to the new location not being aware of different versions of FileMaker being installed on the system. If a specific solution requires a specific version of a plug-in, FileMaker checks the EXTENSIONS folder inside the application directory first before looking for the plug-in in the new location. Therefore, if your solution requires a specific plug-in version it is recommended that you manually copy the plug-in into the old location so that it works properly.

           

          http://help.filemaker.com/app/answers/detail/a_id/10097/~/installing-and-updating-plug-ins-in-filemaker-pro

          So I would say this is expected behaviour, not a bug.

          • 2. Re: Odd Get (InstalledFMPlugins) Behavior
            RonSmithMD

            I think you misunderstand the point. The point is that Get ( InstalledFMplugins ) returns different results in the triggered startup script script than it does in a script that runs after the startup script runs and the database is open. I'm not saying there is anything wrong with how FileMaker treats the different extension locations.

             

            From the iPhone of Ron Smith

            • 3. Re: Odd Get (InstalledFMPlugins) Behavior
              psijmons

              As soon as the file opens, the plugins may load ?

              When you run the startup script with the debugger open (not yet the file open), what do you see?

              The file should really be closed when you do this, not visible via the top menu Window > Show windows

              • 4. Re: Odd Get (InstalledFMPlugins) Behavior
                databuzz

                FYI it's also worth noting that the location for installing plugins has changed with the 12.0v3 updater. On Mac OS X it's now:

                 

                /Users/username/Library/Application Support/FileMaker/FileMaker Pro Advanced/12.0/Extensions/

                 

                The knowledegebase article hasn't been updated to reflect this.

                 

                Andrew

                • 5. Re: Odd Get (InstalledFMPlugins) Behavior
                  RonSmithMD

                  I see the results that only show the plugins, versions, and enablements of the FileMaker Pro extensions folder, and not the user's extensions folder. The file has to be opened already, because the script is triggered by OnOpenWindow in the File Options and I'm seeing the script go through the all the steps of the startup script.

                   

                  Again, the version information returned during the startup script execution is not reflecting the versions in the user's extension folder, until the startup script has completed execution. If I manually run a script that simply does the Get (InstalledFMPlugins) call in a Show Dialog script step, then version in formation does show the user's extension folder versions.

                   

                  Ron

                   

                  Ron Smith, MD, 'The Pediatric Guide For Parents'

                   

                  Want to know more about me and my family? Take a look at the free ebook about my daughter below.

                   

                  Forever And A Day For Laura Michelle

                  • 6. Re: Odd Get (InstalledFMPlugins) Behavior
                    RonSmithMD

                    Yes, but again, it is not the location of the plugins or the fact that the user's extensions take precedence, it is what the Get (InstalledFMPlugins) call returns when included in a startup script as opposed to what it returns in a script that runs after the startup process is completed.

                     

                    Ron

                     

                    Ron Smith, MD, 'The Pediatric Guide For Parents'

                     

                    Want to know more about me and my family? Take a look at the free ebook about my daughter below.

                     

                    Forever And A Day For Laura Michelle

                    • 7. Re: Odd Get (InstalledFMPlugins) Behavior
                      BowdenData

                      Ron,

                       

                      Sounds like a bug in the Get (InstalledFMPlugins) function to me but the following works for me for FMP12. Your setup sounds quite similar.

                       

                      • Table in the dB that has a record for each extension with the following basic fields
                        • Container field to hold the extension
                        • Text field named "pluginVersionCmd" that holds the version command string for that plugin
                        • Text field that holds the version number of the plugin that is in the container field
                        • An unstored calc field that is equal to Evaluate( pluginVersionCmd )
                      • During the Startup Script, switch to a layout based on the Plugin Table that has as the very least, the unstored calc field on it. Make sure the found set is the plugins that you need (probably all in your case). This will cause the calc field to update.
                      • Loop through the found recs checking the unstored calc field. If it is "?", then plugin is not loaded (no matter where it is located in the file structure). If it has value, compare it to the value you have in the container field and decide if you need to update or not.
                      • During the loop, call the InstallPlugin command if plugin is not loaded or you want to update it.

                       

                      HTH.

                       

                      Doug

                      • 8. Re: Odd Get (InstalledFMPlugins) Behavior
                        RonSmithMD

                        That setup is similarly to mine. I loop through all the plugins in the table comparing the required version with the same one returned from a call to Get (InstalledFMplugins).

                         

                        Do this to see what I'm seeing.

                         

                        Put an older version of one of the plugins in your FileMaker Pro applications extensions folder and a newer one in the extensions folder for FileMaker Pro in your home space. (I'm runny a Mac too by the way).

                         

                        Open FileMaker Pro. Then open script debugger and start your application that has a startup script. Just for kicks step into it a couple of steps, then look at the Dataviewer and do a watch for Get (InstalledFMplugins) and see if you don't see the older version and not the newer one.

                         

                        That's what I'm seeing.

                         

                        What that means is that if you have an older version in your FileMaker Pro applications extensions, and you are using your routine to check for and update plugins from a plugin table, you will be updating that plugin every time if you are using the plugin versioning information from Get (InstalledFMplugins) during the startup script.

                         

                         

                        Ron Smith, MD, 'The Pediatric Guide For Parents'

                         

                        Want to know more about me and my family? Take a look at the free ebook about my daughter below.

                         

                        Forever And A Day For Laura Michelle