3 Replies Latest reply on Mar 19, 2009 2:57 PM by TSGal

    conditional formatting and script trigger bug

    sonata

      Summary

      conditional formatting and script trigger bug

      Description of the issue

      When using a script trigger and conditional formatting together, the cursor may end up in a field that is not only out of the tab order, but also is set to disallow entry in Browse! See BizTalk post:  http://biztalk.filemaker.com/?14@@.59b4b511  Subject: cautionary tale Demo file is attached to that post Thanks, Jim Schliestett   

        • 1. Re: conditional formatting and script trigger bug
          philmodjunk
            

          Which script trigger and what conditional formatting expression?

           

          This doesn't sound like a bug, but rather expected behavior. Removing a field from the tab order doesn't make a field inaccessible, it just means that the field is no longer in the cycle of fields you will enter if you press tab (or enter, return if you select that behavior).

           

          Likewise, setting a field's behavior to deny entry in browse and/or find mode only prevents the user from tabbing into or clicking into the field. It does not prevent a script from putting the cursor into a field. This is not only expected but desirable behavior not a bug.

           

          Conditional formatting doesn't appear to be a factor here, but given the brief post I could be missing something.

          • 2. Re: conditional formatting and script trigger bug
            sonata
              

             

            This is not what I would call expected behavior. Did you check the example file from the BizTalk Technical Discussion list? Or perhaps you are not on that list. I just wanted to report a bug to FMI, not have another conversation here. But I can see that without a text-based step-by-step description, people who cannot access the other list will not be able to see what I am talking about. 

             

            I was attempting to implement the filter routine that results in found items being highlighted, as seen at the Roadshow last week. Everything worked just fine, with one exception: it appeared that the conditional formatting interfered with the filter script, and as a result, the cursor did not get reset to the proper field (that is, the global filter field). Instead, it went into to a data field. 

             

            Note that no fields were in tab order, and the data fields were set to disallow entry in Browse mode. And yet, there was the cursor in that field, ready- absent access restrictions- to make unexpected modifications to data. There is no programmatic expectation that said field would be entered.

             

            What this means experientially is that after a letter is typed in, the find executes, the found fields get highlighted... and the cursor gets set in a data field instead of back into the global filter field. The user, expecting to continue typing into the filter field, will instead type into a data field.

             

            -------

             

            Filter script (g_filter OnObjectModify):

             

            If [ not IsEmpty(Curious::g_filter) ] 

            Set Variable [ $cursor; Value:Get ( ActiveSelectionStart ) ] 

            Enter Find Mode [  ] 

            Set Field [ Curious::character; Curious::g_filter ] 

            New Record/Request 

            Set Field [ Curious::sound; Curious::g_filter ] 

            Perform Find [  ] 

            Set Selection [ Curious::g_filter; Start Position: $cursor ] 

            Else 

            Show All Records 

            End If 

             

            Conditional on searched fields::

            PatternCount ( Self ; Curious::g_filter )

            results in light red fill color.

             

            -------

             

            If conditional formatting is removed, the filter works as expected. On its own, the conditional formatting works as expected. But not the two together. In fact, as Lyndsay Howarth pointed out, data loss can occur in ways other than that which my example shows, when using this combination of conditional formatting and a script trigger.

             

            John Morina posted a workaround, wherein a shadow global field is created, populated by an auto-enter calc using the Evaluate function; this field is used in the conditional formatting calc instead of the filter field. Darren Terry also noted a problem with conditional formatting apparently causing a step in a triggered script to fail.

             

            My sense is that the evaluative process of conditional formatting can somehow interrupt the flow of a triggered script, causing the focus to change in ways not programmatically expected. Data loss can occur; the title of my post to the BizTalk list was "cautionary tale".

             

            Jim Schliestett

             

            • 3. Re: conditional formatting and script trigger bug
              TSGal

              sonata:

               

              Thank you for the post.

               

              I have forwarded the file (which I was easily able to duplicate the problem) and your last post to our Development and Software Quality Assurance (Testing) department for review.

               

              Thanks for taking the time to document this and report it.

               

              If any additional information becomes available, I will report it here.

               

              TSGal

              FileMaker, Inc.