How to make a TEO active for data entry

In a form, I have two Text Editor Objects which display the contents of the fields TagNum and Weight. Clicking on a button triggers a procedure which loads a tag number into the first TEO and pauses the procedure, waiting for me to enter a weight in the second TEO - this entry triggers a resume statement which allows the procedure to store the weight and load another tag number.

After the tag number is displayed, I want the second TEO to be active for data entry so that I can type in a weight without having to click in the TEO first.

I had this working until I made a few modifications to fix another problem and now I can’t get back to it. What’s the secret?

I would think that you give different names to the two objects and make the one that you want to be active by name.

But I wonder why you would want to have two text editor objects if you are only changing one. That seems like it could lead to problems. If you are not expecting anyone to change the tag number, then it should be displayed in a text display object.

I’m not really sure I understand what you are going for, but you may find this help page useful.

Hmm, if you just want a procedure to open an object for editing, give that object a name, then use this code:

objectaction "object name","open"

This is the same as Panorama 6, except that instead of objectaction you would say superobject (which will still work). This is described on page 670 of the Panorama 6 “Formulas & Programming” PDF file. Unfortunately, this is not yet included in the Panorama X help.

Good point Bruce, thanks.

And Jim’s solution is the one I needed - I was looking for an object action something like “active” and skipped straight past the “open” option.

I’m still having difficulties with this issue. I have these Text Editor Objects in a form:


Each of the Cartage and Fees & commissions objects calls this section of code in a procedure:

elseif info("formname") contains "livestock purchase" and (Button contains "gross cost" or Button contains "cartage" or Button contains "commission" or Button contains "quantity")
    TaxStatus = "GST-payable"
    «Fees & commissions» = zeroblank(«Fees & commissions»)
    Cartage = zeroblank(Cartage)
    «Nett purchase price» = zeroblank(«Gross cost» + Cartage + «Fees & commissions»)
    «GST paid» = zeroblank(?(TaxStatus = "GST-payable",round((«Nett purchase price»/11),0.01),0))
    «Average price» = zeroblank(?(Quantity > 0,round(«Nett purchase price»/Quantity,0.01),0))
    message Button

A terminated entry in the Cartage field tabs to the Fees & commissions field where the blue bezel highlights and disappears. In order to enter data into the Fees & commissions fields, I have to click in it first.

If, however, I disable the procedure call for the Cartage field, the Fees & commissions field highlights with a bezel and I can enter data immediately. That’s no help of course because the other values won’t be updated.

In an attempt to see what was happening, I put the last two statements in:

    message Button

With the procedure call for the Cartage field restored, I get this when I tab out of the Cartage field:


Now this really baffles me because it appears that just tabbing into the Fees & commissions field is triggering the procedure except that the Button values are being displayed in what looks to me like the wrong order. Is that really what’s happening?

And, as a further source of confusion, on a similar form (the first was cattle purchases, this one is cattle sales), when I tab out of the Fees & commissions field, its cursor stays, switching on and off, while a second cursor is in the next field I click in:


The problem is because the Save statement is removing the focus from the tabbed new Text Editor. If all of your TEOs are named in the object’s Attributes panel you can simply add this code around the Save statement:

let actOb=info("activeobject") 
objectaction actOb,"open"

Thanks Gary - I’ll check that out.

It’s clear that the save statement does a lot more in the background than I had thought.

Good catch Gary, I’m glad you saw that because I didn’t think of it when I read Michael’s post. But you are absolutely correct.

I have a slightly different suggestion for the fix though – how about simply removing the save statement and let auto-save do it’s thing? It seems kind of excessive to force a save after every single cell entry. Also, forcing a save like this will clear the Undo stack, eliminating the ability to perform multi-level undo.

I’m also not sure that the suggestion of using objectaction “open” will work – for sure it won’t work if the tab key is pressed. Code that runs in response to completion of editing a cell runs in a special mode because other stuff is going on.

In fact, the more I think about it, my strong suggestion would be to not use the save statement in this context.

Well, in my tests it worked with the tab key as long as the tab options are set in the Properties panel. :roll_eyes:

Ok, I didn’t try it but I’m surprised because Panorama itself is going to try to open another object for editing, based on the tab order. That’s why I added a feature in Panorama X 10.1 specifically to allow you to control the tab order on the fly without having to use objectaction.

Gary’s code doesn’t help - I still get multiple error messages. Jim’s suggestion is logical and works well - up to a point. I then find that, if the value in the Fees & commissions field is zero and I Tab out of it and then click anywhere else in the form, I get this error message:

There is no error message if I use Return or Enter to terminate a zero value. Both Return and Tab are flagged as termination keys.

Tab ordering was initially set to Natural. When I changed it to Data Sheet Order, the problem disappeared. Nevertheless, it should not have occurred should it?

It sounds to me like maybe one or more of your Text Editor objects was linked to a variable, rather than a field? When you use Data Sheet order, only text editor objects associated with fields are included in the tab order.

No - all of the fields I referred to are linked to fields. What else might be happening?

That’s the only reason I can think of why using Data Sheet order might make any difference.

I;ll do a bit more sleuthing - I would really like to get to the bottom of this.