An event trigger when data is added to a field

[Lance]

Is there a way to trigger a function when I add data to a field with code? Something like "on textChanged" ?

put "test data" into field "Data"

then i want that event to trigger another function to update some buttons that become enabled with there is data available in field "Data"

thanks.
Lance

[Klaus]

Hi Lance,

not directly, but you can do something like this.
Script of field:

Code: Select all

on closeField
   ## Sent when field is closed (left) and its content has changed.
   ## your stuff here....   
end closeField

Then force this behaviour of the field with:

Code: Select all

...
put "test data" into field "Data"
send "closefield" to fld "Data"
...

Best

Klaus

[dunbarx]

Yep, something I would have bet money could not possibly be true. The "textChanged" message is not sent when the text changes in a field via script.

Weird. And moreover, WHY???

Anyway, why not just do your task when you load the new data? In other words, instead of invoking a message, just:

Code: Select all

put "test data" into field "Data"
doYourStuff fld "Data"

You already explicitly enter data into the field, so just keep going in the very next line.

Craig

[dunbarx]

I suppose you should test to see if the text has indeed changed, that is, you did not put the very same contents of that field back into that field. That may not always be a valueless thing to do, however, so mentioning it just in case.

Craig

[stam]

I've had this same issue and also posted this exact same question.
Long and short of it is that there is no textChanged when setting text by code.

What I did was I created a command in the field's script, and passed the new text as a parameter, eg

Code: Select all

on setFieldText pText
   set the text of me to pText
   // do the other stuff that's supposed to happen
end setFieldText

so then instead of

Code: Select all

put <text> into field <field name>

I instead use

Code: Select all

dispatch "setFieldText" to field <field name> with <text>

hope that helps,
Stam

[dunbarx]

Well, at least two people have wanted that "feature" to be "updated". Is this worth making an enhancement request?

Make that three, with me, just because.

Craig

[stam]

Between bringing Create, LC10, WASM and compiled scripts forward I doubt they would have the appetite to alter the language at this late stage... but I guess you never know.

[dunbarx]

So much of this long running debate is about getting the word out. The four items Stam mentioned are major enhancements.

Full page ad in the Times? Kudos on the forum?

I believe a free limited version is and always was essential. Not everyone saw instantly that LC was a much better new HC. And I would up the number of lines one can save from ten to 25. Ten lines is not enough to make an address book. That loses nobody who might one day want to buy a subscription.

Craig

[FourthWorld]

Text manipulated by user actions can take many forms, including typing, cutting, pasting, drag-n-drop, etc. Having the text changed message to handle all of them is a godsend.

In contrast, the one thing we know about text being manipulated by script is that the scripter is in control of how that happens.

When that control benefits from being centralized, the common solution of writing an accessor handler as Stam demonstrated allows for that with minimal effort.

I would not expect an enhancement request to make such control even more convenient to become a high priority on any timeline which could benefit current projects in production.

[Lance]

Thanks for all the replies, appreciate it. The "dispatch" idea from Stam looks like my most likely solution. Sounds like everyone would really like a textChanged to be trigged when setting text by code. Seems logical to me.

I may be in a position to at least get this in front of the LC team. I have had the LC service team working on a major software project for my company for the last couple years. It is a full replacement of my legacy food distribution software. Purchasing, accounting...etc. All being done from scratch in LC. Project is about 70% complete and moving along nicely.

So i will reach out to Scotland and see what they think on getting the textChanged trigger to be included. Worth a shot.

thanks
Lance

[FourthWorld]

Mark Waddingham is a very thoughtful API designer. When he chose to implement the textChanged message many years ago, I'd venture to guess that his decision to make it a catch-all for system events while leaving scripted changes up to the scripter was not mere slouch.

Moreover , at this point, with the message having been used in production environments as-is for so many years, expanding its scope would likely have consequences for shipping products which would be difficult to anticipate and recode for. One of the distinguishing benefits of LC over many other systems is the fierce defense of backwards compatibility, that code written yesterday will work today even as the engine evolves.

I suspect given these two factors (the original reason for making its scope focused exclusively on system messages, and how long the message has been relied on for that designed purpose in shipping apps), his inclination would be to consider a new message instead of expanding the scope of the existing one.

But of all the language elements the engine offers, messages are among the most challenging to implement. Each one has at least some relationship with the very different OS APIs needed for implementation, and has to be considered in light of all other relevant messages to ensure no side effects. And then there's the performance hit inherent in adding new any new messages to the queue.

Mark may well be excited at the prospect, but given the nature of the task, the priority queue currently on their plates, and the easy availability of a scripted solution, I'd be surprised if they were in a position to act on it for quite some time.

[Lance]

Some good points RIchard. It potentially could cause issues in terms of backwards compatibility. I wonder if you could simple add some sort of command in the main open stack event like "set fieldTextChangedEvent to true" if you wanted this this new trigger to work?

Lance

[FourthWorld]

A global property to govern scope would be one way to handle it, but in addition to doubling the implementation/testing/documentation commitment it may still have side effects with any third-party code that doesn't take that into account.

Stam's accessor handler gets the job done well, and reminds us of the benefits of factoring UI from business logic in general.

Many software architecture models are based around separating concerns, and the three basic domains of a software system tend to fall into the categories of UI, data, and logic. Getters and setters for handling values within the model allow each part of the system to operate with less dependency on the others.

For example, most systems I've made are subject to changes in data storage. I can write the storage handling in place throughout the UI code the user will trigger, or have that UI code call a central library to handle storage. If I choose to use a library to centralize storage mechanics, I can change just four CRUD storage handlers without changing much or even any of the UI code throughout the system that calls those.

Separating concerns through getters and setters carries those benefits in the other direction as well, liberating UI. I might start a system with an integer value displayed in a field, and later replace that field object with a slider, making the value a little easier for the user to change and much easier to conceptualize how it relates to the full range of allowable values. Later on I might change that again to become a custom control that shows a more concrete representation of what the value does, such as a holding tank for an industrial process or the number of armored units in a wargame's battalion.

Where I have a habit of separating concerns, I have more flexibility for accommodating change as the system evolves. And along the way, the decoupling of UI, data, and logic simplifies unit testing, and opens the door to sequenced automated throughput testing in a more meaningful and affordable way.

All that for the low cost of a couple lines of script. I'm sold.

[heatherlaine]

Greetings all,

Just to clarify why this is the way it is, the word from Mark Waddingham is that a general mechanism to do this would really slow things down because it would trigger a message every time any text was changed in any field. However he does think that a field property could be created to register for such a message on field by field basis. This would then only slow things down for that one field.

So potentially something like that could get added, at some point in the future, depending on how urgent the need for such a feature might be

Best Regards,

Heather

[stam]

Thanks for all the replies, appreciate it. The "dispatch" idea from Stam looks like my most likely solution. Sounds like everyone would really like a textChanged to be trigged when setting text by code. Seems logical to me.

Hey Lance,

Another variation of that, which I use a lot in groups, is to use custom properties with getters and setters. With a field you don't need a getter, because the text is the text property of the field.

however the setter may be helpful:

Within the field's script:

Code: Select all

setProp textContent pText
   set the text of me to pText
   // do whatever else needs to be done
    
   pass textContent // if you want to actually store this as custom prop, but not actually needed
end textXontent

And then instead of dispatching to a handler in the field, just set it's custom property to the text you want:

Code: Select all

set the textContent of field "field name" to <text>

I use this *a lot* in groups (for example the skComboBox I recently posted - at least 1/4 of the script is getters and setters).

Hope that helps,
Stam