The script that you attach to the button is what is executed on the button click event, so I'm confused by your description.
What triggers run when you click a button, how do you have that set up?
ok - thanx wim - let me try again:
there is a field in a portal row with its triggers OnObjectExit on field and portal row etc .. and a button in a portal row. now i am in the field in one row and click the button in another row.
if i click the button it triggers to leave the field just because of the row change.
my challenge is - that i need the triggers to escape (or behave differently) when the button is clicked.
since the button causes the triggers to fire i wish i could let the scripts know that the button has been applied but i don't see any way to do this. the script of the button will be last to be executed and the button object doesn't indicate that it has focus or anything to let the triggers know of its state.
so is there a away to track a button's click before it's script runs - unfortunately setting a flag on the button script call as a script parameter excutes as well only when it's its turn in the execution stack order ..?
Won't work. There is a definite sequence to how events are executed. An event has no knowledge of any "upstream" events or events that will happen after itself. This reference may help:
thanx wim that's what i feared.
that seams to be a major restriction and demand for something like a new object attribute "buttonClicked" within
So - if I understand correctly, u have onExit script triggers applied to fields inside a portal and the act of pressing a button in this same portal but on a different portal row than the row containing the cursor/active field is something u want to drive the logic inside ur onExit script i.e."We are leaving the field now and doing so because a button got pressed somewhere else. Let I, the onExit script trigger, act differently than i would if this button wasn't ever pressed !"
I think that u r visualizing the button event happening and then the onExit event happens. I'm visualizing this as event #1= mouse cursor touches screen outside of the active field, thus firing event #2, the onExit script then the mouseDown event happens, this also triggers the button.
So at The moment when onExit occurs, there would be no way for it to be aware of a future event,
It is only aware of the cursor touching an xy value outside the field.
That being said - perhaps u cld experiment with selecting a script trigger other than onExit to do the work u want. Perhaps there is a moment just after the buttonEvent that cld work?
Perhaps the button event itself ? U didn't say what the onExit script is trying to accomplish.
The time space continuum challenges can be tough !
U might also try a script trigger on the portal itself but u will have to drive ur logic with something other than the button (I would say a test of "is active record the record in this portal row?, if no the press is elsewhere ).
Have you considered using an OnTimerScript with a very short delay to trigger the script that is presently the exit handler on the field?
Suppose we denote Script A to be the real exit trigger script that needs to branch conditionally depending on the nature of the field exit scenario.
1) On the field in question, instead of Script A, attach an on exit handler which triggers a simple script that we'll call Script B
2) Script B is little more than an OnTimer script step which will invoke Script A in some small interval, e.g. .3 seconds, with a script parameter of "FIELD"
3) The button on the portal row is configured to directly invoke Script A, with a script parameter of "BUTTON"
4) If we exit the field without the button click, the OnTimer will fire Script A with the "FIELD" parameter.
5) If we click the button, the button will invoke Script A with the "BUTTON" parameter.
6) The first thing that Script A does when it is invoked is that it clears the OnTimer from any (further) firing.
7) The next thing that it does is check the supplied script parameter so that it can branch conditionally based on the circumstances that invoked it.
I'll attach an example I threw together when I was checking to see if this possibility seemed feasible.
Thanx Steve great thinking - and yes i use OnTimer scripts when i need to implement co-routines and attach to the stack order in sequence..
Unfortunately in this case the complexity it adds - because i would need to rewrite the triggers within filemaker - would be overkill.
i would need to maintain a stack of the calls - as well as to maintain the location where the script has been stacked and all attributes just for the sake of looking ahead of the execution stack
and then the ExitScript with ScriptResult Zero event - to abort an event would be extremely hard to work around.
i would end up sitting there for an eternity ..
anway - very much appreciated.
(i got a little bit closer though by using not buttons but fields containing buttons and using the OnEnter trigger to run the button - but still cannot branch within the needed triggers)
( i also tried to use checkbox fields with globals as the button because it checks the flag but still the OnExit trigger won't know of the click)
i consider this as a semantic gap within filemaker script triggers and request a feature as explained earlier to check for the button's object events.
thanx very much again Steve!
and appreciate the example file!
It will depend on what other buttons and fields that you have outside the portal as to whether this will work, but could it help to set some global variables only in the OnObjectExit script trigger, and leave the other steps to a 'OnRecordCommit' script trigger or the script that runs when you click on different buttons. For example, the 'OnObjectExit' script might just help determine the values (set global variables) in that portal row to then determine the action that will occur when the record is committed or another button is clicked. You could clear the variables with the subsequent script triggers or scripts.
thanx stephen - i cannot break the logic - it is all uncommitted - i have a hierarchial transactional portal and all triggers are precisely minimized for their purpuse. i just need to branch within one trigger on that button's state which seams to be impossible.
You could just set a global variable to test against.
I think both stephensexton and Mike Duncan are pointing you in the right direction. Logic may seem like you could put a parameter in your button to tell the OnExit script what (not) to do but, as you've seen, you hit that point too late in the process.
Instead, try adding a parameter to your OnExit trigger. There are several ways of doing this - depending on whether or not you already have a parameter there, and your preferred method to handle parameters. If you're not already using a parameter there, one option would be:
Then, at the top of your script, add:
If [ Get ( ScriptParameter ) ≠ "OnExit" // if parameter is not "OnExit"
Exit Script ( 1 )
Don't forget the 1 at exiting script, or else you won't exit the field.
Does this help?
thank you Debi - what you suggest doesnt work. the click event cannot be read by any preceding trigger that's the challenge.
Sorry - set up a real test and see the problem more clearly now. So I'm wondering more about what reelsteve asked: could you use a different trigger than OnExit? What are you doing with the triggered script? What version of FM?
i am on FM12v4 - thanx Debi - all suggestions here are very much appreciated. the solution is to write a new trigger logic with OnTimer script triggers and tracking everything. which is overkill - but i am used to this - so i should give it a try - i am used to mirror entire tables in key-value pairs in global var space as work arounds .. it's like programming a turing machine ..