5 Replies Latest reply on Oct 11, 2012 11:59 AM by philmodjunk

    Weird script behavior....can u help?

    synergy46

      Title

      Weird script behavior....can u help?

      Post

           I am using FM12Adv in OSX.

           I have a table called Members

           There are 2 fields MEMBERS:: TYPES and Members::ValidType  (numeric 1 or 0)

           Members::Types has these dropdown values:  Yearly, Honorary, Life, Special

           When a user selects one of the values in TYPES, the field Members::ValidType =1

           When I delete one of the Members::Types,  Members::ValidType gets set to 0 in the following script:

           In the script $$MemTypes="Yearly Honorary Life Special"

           When the deleted ::TYpe is NOT found the $$VALUELISTFOUND gets 1 if found.

           The weird behavior is that I have taken 3 member records whose Last Names start with "B":
           (Brown, Baker, Black) and deleted their membership TYPE from the dropdown.

      When the script runs it works through the Brown and Baker by assigning a 0 to Members::ValidType.  When it gets to Black, the Set Field DOES NOTHING. I can watch it and VALIDTYPE stays 1????????????

      settype.jpg

        • 1. Re: Weird script behavior....can u help?
          philmodjunk

               You have some odd steps here

               Set Variable [$$CurrentType ; value: Members::Type]
               Set Field [Members::Type ; $$CurrentType]

               makes no sense. But it also does no harm as it only sets the type field to the value it already has.

               Nothing jumps out as obviously wrong here. Is the current layout a layout based on the Members table occurrence?

               When you say that you can "watch" it, does that mean that you are using FileMaker Advanced's Script Debugger to step through the script?

          • 2. Re: Weird script behavior....can u help?
            synergy46

                 FYI, there is a calculated special function that kicks in when I set field. 

                 Out of frustration I started trying things that I knew 'would not work'. 

                 Background:  I have 2 windows open:  Setup and Membership.

                 The portal row that is deleted is in Setup.

                 The script (as you can see) does a Select Window (Membership) 

                 Apparently that does not matter:  When I manually executed a Close Window (Setup) after deleting the portal row, everything worked.

                 Do you have any ideas as to 'why'?

            • 3. Re: Weird script behavior....can u help?
              dkimerling

                   Just an idea, and I'm not sure how the ValueExists() works, but is it possible that when you deleted the membership type for Brown you replaced it with a space instead of an empty field.

              • 4. Re: Weird script behavior....can u help?
                synergy46

                     Each  members::Type is derived from a field in a Setup::Type portal. 

                     The phenomena occurs when I delete a Setup::Type portal row.

                     What should happen is that any Member record would now have a TYPE that is NOT a valid type (it is orphaned).  In this situation, *ALL* members who have a Members::Type that is not in the 'new' Setup:Type list are invalid and should have their Members::ValidType field set to 0 (zero). 

                     Leaving the Setup Window open (and using Select Window (Membership) causes the problem.

                     Closing the Setup Window immediately AFTER deleting the portal row causes the script to act as expected. 

                     The question is "Why?"

                • 5. Re: Weird script behavior....can u help?
                  philmodjunk

                       Maybe you need a Commit record to take place before you switch windows. If you open a record for editing in one window, you cannot edit the same record in another window. You will be locked out just as though two users were trying to edit the same record in a file shared over a network. Normally, this produces an error message unless Set Error Capture[on] is used to supress it. I haven't suggested this earlier because I didn't know about the other window and I don't see that step in your script.