Returning to the core need expressed here:
stam wrote: ↑Fri Apr 16, 2021 4:07 pm
I have a setup where a complex set of graphics that creates a summary parameter - i was hoping to use that as a trigger to update a database every time a value is changed, which will in turn change the summary parameter. i.e., instead of having to add the updating command to every graphic...
There are at least two built-in ready-to-use ways to have multiple controls modify one field with extra stuff beyond setting the text itself:
- Handle it in any script of relevant scope
- Handle it with a setProp handler
Neither requires replicating the additional handling. The db binding (or anything else you want to do) is every bit as centralized as if you'd written a textChanged message, but without the overall performance degradation of a new message that would impeded all operations involving text display.
Let's briefly look at each:
Handle it in any script of relevant scope
In each control the script is about as lean as it could possibly be, a one-word command with one argument:
Code: Select all
on mouseUp
SetMainTextWithBinding "Some text to add to the field."
end mouseUp
In a card, stack, or library script we define the handler:
Code: Select all
on SetMainTextWithBinding pText
put pText after field "Main"
-- DB update stuff goes here
end SetMainTextWithBinding
Handle it with a setProp handler
Here each control set a virtual property of the field as the trigger for the multistep operation:
Code: Select all
on mouseUp
set the uBoundText of fld "Main" to "Some text to add to the field."
end mouseUp
...where the field, card, stack, or a library can define how to handle that virtual property:
Code: Select all
setProp uBoundText pText
put pText after the text of the target
-- DB update stuff goes here
end uBoundText
Which is "best" is partly a matter of taste, and partly a matter of the workflow you develop with: virtual property handler (getProp/setProp) are handy but affected by lockMessages, where custom handlers are not. If you have total control over everything in play you can have confidence that no other script will have messages locked at the moment the setProp is triggered.
Personally I use the less glamorous option is just putting a handler in a relevant script, keeping things simple enough and I never need to ask myself whether messages will be locked when it's invoked.
The important thing here is that the code in each control used to trigger the text change is dirt-simple, possibly a bit briefer than whatever was in place to set the text before. And the full scope of the handling -- both displaying the text change and dealing with the DB stuff -- is fully centralized in one place for robust and easy maintenance, just as it would be if it were handled in a textChanged message (but without the performance hit of having the engine take on yet another message).
The challenge in this specific case isn't so much finding a comfortable solution for multiple triggers of a single set of custom handling instructions.
The challenge is a challenge at all only because it's retrofit, a solution not anticipated in the code as originally written.
With just about any non-trivial program there will be times we'll want to revise things based on what we've learned since we first started crafting our app. While it would be wonderful to have simple mechanisms we can drop in place so we don't need to change code to reflect changing needs, refactoring/retrofitting is indeed rarely simple and often tedious.
Accommodating change is work, in any human activity, including coding.
While exploring options for one-size-fits-all solutions like reliance on an idle handler or other such things may be useful for learning and sometimes even prove a great solution for the task at hand, I would caution against the temptation to bypass normal with-the-grain message handling unless it's absolutely necessary, after all with-the-grain options have been explored and somehow proven untenable for the unique case at hand. There be dragons. Every gray hair on my head was hard-earned from spending hours in the meadow hunting for magic ponies that never appeared, when all I needed to do was sit down, roll up my sleeves, and revise a few lines of code.