If a push button is clicked while a text editor object is still active, the TEO is not automatically closed and the edit is not updated in the field.
Is this a bug or missing feature?
I could add a closeactiveobject statement to every button, or enable the “Update Variable Every Key” check box for all TEOs.
Either way, anything would be easier that training users to hit enter/tab before clicking any button.
This is a feature. It allows you to make a button that does something with the edited text. For example, you might have a button to do a find within the text.
In most buttons you do want to add the closeactiveobject statement, but it’s not added automatically because otherwise you could never have a button that worked with the edited text itself. The same applies to menus, etc.
FYI that option only works for variables, not fields in a database. So that would only be a possible solution for variables.
Thanks for the explanation Jim.
Could you add an option for push buttons to choose if the button should close or not an active object when pressed? This way you don’t loose the feature in case someone needs to use the button the way you describe.
If possible, I think that this option should be enabled by default for new buttons, as it is how most buttons are used.
I’m not sure why buttons should be a special case. What about Action menu items? Or other various ways of triggering procedures, like Hotkeys? It seems like this should be an option on each procedure. But then, what if a procedure is both called as a subroutine and triggered by a button? I don’t see a really clean solution, so my inclination is to leave it as it is, especially since it has already worked this way for over 25 years. I’m not absolutely saying no, but I think this is a change not to be made without really thinking it through.
Hugo, I’m guessing that later on, months or a year from now, you’ll be glad if the action of closing an active object - your TEO - is controlled in one place instead of having to visit all the possible places to change it - see the list of possible triggers Jim just pointed out.
When you get into a situation where you have to fix someone else’s, or your own, program and you find yourself having to look at every control to find where it’s misbehaving, you might be thinking, “Gee I could have put that action in a procedure and just called that procedure from all those triggers. That way, if the action needs to be changed, I only have to change it in one spot.”
A related example was a request to change a person’s business address. So simple. Just go to where the address is stored and modify it there. But noooooo. Not that simple. The person had put the address in three different places and in three different forms (Fix Text - label, TextEdit Object, and Flash Art). There were about 26 forms and they all had to be visited to see if they contained the address and in what format. The “Just change xxx to yyy” was a little more time-consuming than expected.
So instead of having all those triggers do an “action”, consider putting the action code (close the active object) in one place and just call that action with the various triggers. If you need more flexibility, You can condition the action with a CASE statement for each trigger.
Actually Paul he’s talking about one line of code that will have to be put in multiple places. It would be silly to put one line of code in a subroutine. What Hugo is essentially asking for is to eliminate that line of code and replace it with a checkbox – and he wants that checkbox to default to ON.
The fact is, Hugo is not wrong – this needs to be put into most procedures triggered by an action (especially in a form window) and most people probably aren’t doing it.
Yes, my point is weak when there is only one line of code. But I’m guessing that, over time, that one line can expand a bit. 