Still having a problem with a form that has about 15 text edit superobjects. When I try to type in any field, the text always appears in the note field. All fields have unique names assigned, I just can’t type in them. If I double click text in a field, it is highlighted but if I type something new, it always enters the type in the notes field.
Suggestions?
If you can send me a file that demonstrates the problem, I think that would be the only way to get this resolved.
@JeffK’s file was a contact database, and he had code that would run when the user finished editing the Address field. The purpose of this code was to immediately jump to the Zip code field. Here is Jeff’s original code:
SuperObject "ZipSO","Open"
This code will normally work, but it won’t work when it is triggered by editing completion. I think the problem is that at that time Panorama hasn’t yet finished closing the previous superobject, so it gets into an endless loop until it crashes.
Forcing Panorama to jump to another field after a field is edited is something that I have had on my radar, but haven’t gotten around to yet. However, I did come up with a workaround that solves Jeff’s immediate problem. Here is a revised version of the code that does work:
starttimer "jumptozip",
"code",{SuperObject "ZipSO","Open"},
"repeat",1,
"scope","window"
What this code is doing is delaying the superobject statement until Panorama has finished it’s current operations. At that time it can run without problems. We only want this to happen once, so the repeat option is set to 1. I don’t think the scope option is really necessary in this case, but it doesn’t hurt anything either and I think is tidy.
I think that any code that is triggered by editing that changes window configuration or editing status will need to be wrapped in a timer like this. If your code just changes variable and field values, it can run directly when triggered, but if the code changes the window configuration (and opening a superobject counts as configuration change) it cannot run immediately, but needs to be delayed until Panorama is in it’s normal run loop. I’ll be adding a new statement, probably called something like executesoon or executeasap to make this easier, but under the hood it will be using this same timer mechanism. So if you make this change now it should continue to work.
In @JeffK’s database this code was triggered from a property on the database field. So the code will run whenever the Address field is edited, no matter what window is being used. So this code will run even in the data sheet. However, it won’t work in the data sheet, since obviously there is no superobject in that window. I would recommend either moving the code into the Address object, or adding a test in the code to make sure it only runs in the appropriate form.
By the way, in Panorama X the superobject statement has been renamed objectaction, which is more descriptive of what it actually does. But superobject will still work.
I would suggest adding an entry for superobject in the Help, that explains this. When I select superobject in a procedure and use the “Lookup in Help” popup function, it takes me to info(“activesuperobject”) which is not very helpful.
And when I get a runtime error for superobject the error explanation refers to objectaction which is again confusing.
Yes, it is mentioned at the very bottom of the objectaction help entry, but I can’t get there until I discover the new name some other way.