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.
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_ﬁlter) ]
Set Variable [ $cursor; Value:Get ( ActiveSelectionStart ) ]
Enter Find Mode [ ]
Set Field [ Curious::character; Curious::g_ﬁlter ]
Set Field [ Curious::sound; Curious::g_ﬁlter ]
Perform Find [ ]
Set Selection [ Curious::g_ﬁlter; Start Position: $cursor ]
Show All Records
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".
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.