8 Replies Latest reply on Sep 5, 2012 12:00 AM by areohbee

    Strange nil value problem

    willodotcom

      Hi everyone,

       

      I've been working on a Lightroom plugin for and I have an interesting problem, where values that should be not nil prior to export (ie they must be true for the export button to be enabled) are then nil afterwards. It happens for some users of the plugin, but not all, and the tricky thing is I can't reproduce it myself.

       

      The user selects an event for their photos etc via a dialog and then exports.

      There is an observer function on several variables to check if the chosen parameters are correct/sane etc.

       

      After checking several variables the last one is :

       

      function DialogSections.updateCantExportStatus( propertyTable )

       

      ..

      .

       

      if propertyTable.loggedIn and propertyTable.finishedLoading and propertyTable.chosenEvent and (propertyTable.category or propertyTable.auto_create) then

                               propertyTable.LR_cantExportBecause = nil

                               propertyTable.LR_canExport = true

              return

      end

       

      The problem occurs later in the processRenderedPhotos function.

      I get a copy of propertyTable via:

       

      function FTPUploader.processRenderedPhotos(functionContext, exportContext)

                local exportSession = exportContext.exportSession

                local exportParams = exportContext.propertyTable

      and then immediately afterwards in the code, for some users the following error is triggered:

      if not exportParams.chosenEvent then

                                    LrErrors.throwUserError( LOC "$$$/Upload/Errors/InvalidParameters=Please choose an event from the dialog before exporting." )

                                    return

                end

       

      So it seems the chosenEvent variable is nil, when it had to be not nil in order for the export button to be able pressed in the first place. The button enabled/disabled state is working correctly.

       

      Is it right to assume that propertyTable variables are visible between the dialog being displayed and the export taking place?

       

      The fact that it only happens to some people makes me think some kind of race condition, but that last if-clause is the only place where the export button is set to be enabled.

       

      If anyone has seen this kind of thing happening before, I'd really appreciate any help!

       

      Best regards,

       

      Chris.

        • 1. Re: Strange nil value problem
          areohbee Level 5

          Hi Chris,

           

          I probably won't be able to help - I've never experienced such strange behavior. Just a couple comments FWIW:

           

          Default state of cantExportBecause is false (i.e. *can* export).

           

          So if updateCantExportBecause has not been called, that would be a case when one could export, despite chosenEvent being false.

           

          For example, if you've just loaded Lightroom, then choose to export via preset chosen on context menu, export dialog box will never have been displayed, and start-dialog will never have been called.

           

          Let us know how this turns out, OK?

           

          Rob

          • 2. Re: Strange nil value problem
            wepurol

            Hey Chris

             

            Although it is hard know without any knowledge of your code I would bet on a race condition too.

             

            There is a note about parallel tasks in the Lightroom SDK programmers guide:

             

            IMPORTANT: Each of the providers (the export service, filters, and Lightroom's built-in rendering engine)

            runs in its own task (using LrTasks), so these loops operate in parallel. It is likely that each provider will be

            running simultaneously. Several photos can be in process simultaneously by different providers. This

            allows the overall export operation to complete much more quickly than it would if every photo had to go

            through all of the steps before the processing of the next photo could begin.

             

            Not sure if processRenderedPhotos() itself can be mutli-threaded aswell - at least I cannot see any hint that it actually is mutlithreaded out of this note.

             

            Do you have an export filter or something which is writing chosenEvent aswell?

             

            Maybe you could add some debug output which counts the number of processed photos etc. to figure out if it is a race-condition problem.

            1 person found this helpful
            • 3. Re: Strange nil value problem
              areohbee Level 5

              wepurol wrote:

               

              Not sure if processRenderedPhotos() itself can be mutli-threaded aswell - at least I cannot see any hint that it actually is mutlithreaded out of this note.

               

              There is one task for export service, one task for each filter, and one task for rendering, per export.

               

               

               

              Reminder: It's *NOT* a good idea to rely on variables being set by export dialog box (or start-dialog) - it may not have been invoked before the export was initiated.

               

               

              Another thing that screwed me up a bunch of times in the beginning:

              start-dialog is called every time you switch to the export dialog box, so if you follow the examples in the SDK, and add observers in start-dialog, you can get multiple change handling functions called each change - generally not what you want.

               

              Better to use the "long" form of addObserver which depends on an ID to assure only one observer is registered, when you only want one.

               

              Also, errors in change handling functions (observers) are just ignored, by default (and button handlers, and ...). Make sure you have error detection to be sure critical things you *think* are being done *are* being done...

               

               

              Rob

              1 person found this helpful
              • 4. Re: Strange nil value problem
                DawMatt Level 3

                Hi Chris,

                 

                Rob Cole wrote:

                 

                For example, if you've just loaded Lightroom, then choose to export via preset chosen on context menu, export dialog box will never have been displayed, and start-dialog will never have been called. 

                My guess is Rob's suggestion here is what you are experiencing.

                 

                Any property table field defined in your export service's exportPresetFields table is persistent across sessions, and will be stored in any preset created for that export service. Those fields will also be included if the user chooses the context menu's "export with previous settings" option. Any other property table fields may be not be set if the user triggers an export via the context menu (i.e. without opening the Export dialog).

                 

                Its easy enough to test this. Do an export the normal way, then immediately afterwards use the File -> Export with Previous menu option to try to repeat that export. If the guess is correct you will hit your nil issue with that second export.

                 

                Matt

                1 person found this helpful
                • 5. Re: Strange nil value problem
                  willodotcom Level 1

                  Thanks everyone for your responses! It's great to see such an active dev community here.

                   

                  The problem was trying to export 'the normal way' ie using the dialog.

                  I had a response back saying that clearing the preferences of the plugin and reinstalling seemed to solve the problem.

                  It seems strange to me, as even if a stored nil preference for the variable was present, wouldn't it be overriden by the choices in the dialog?. I will keep an eye on this issue, as I don't think it's solved completely.

                   

                  Thanks Rob with the tips regarding the observer functions - I'll remember those in future!

                   

                  Thanks again,

                   

                  Chris.

                  • 6. Re: Strange nil value problem
                    areohbee Level 5

                    willodotcom wrote:

                     

                    ...clearing the preferences of the plugin and reinstalling seemed to solve the problem.

                    Hmm. So, were you ever able to reproduce the problem, or you suggested to your user(s) to do this and it worked.

                     

                    PS - I have had messed-up preferences before which caused some problems.

                     

                    This is one reason I was hoping Adobe would have 2 options when removing a plugin:

                    1. Clear preferences.

                    2. Clear catalog tables.

                     

                    With those, it would be easier to re-add a plugin and have it function more like it would for first-time users.

                     

                    Cheers,

                    Rob

                    • 7. Re: Strange nil value problem
                      willodotcom Level 1

                      Alas no I was never able to reproduce it, making it much more difficult to find out what was going on.

                      The user noticed that his old settings were present after uninstalling/reinstalling so he tried removing them and presto.

                      The user had recently upgraded to LR4 apparently, perhaps that confused things; although I had done exactly the same thing and had no problems.

                      • 8. Re: Strange nil value problem
                        areohbee Level 5

                        Ah - thanks for explaining.