Enter key to open cell for editing

Perhaps I am missing something, but when I am on a cell in a data sheet and press enter, nothing happens. In Panorama 6, the cell would open for editing, with the contents selected. Now it seems I have to click on the cell, which is really inconvenient. Is this a bug or a feature? Is there a work-around?

If you press tab when the cell is closed, it will open.

But I notice this anomaly: often a form will open with some field selected. One would expect that typing would automatically appear in that field; but often nothing happens until you click or tab to open the field. There’s nothing to indicate that this apparently selected field is in fact closed. I think any selected field should be available for entry without any other actions. I find this annoying and I’m a long-time member of the choir; I expect others without that commitment would be turned off by this, along with the issue I’ve mentioned before about selected fields that look empty turning out to have data in them after all if you click on them. I see that one on a daily basis.

Pressing tab seems to work, but it is hard to break an old habit.

This isn’t something that was done intentionally. I have added the line of code so that pressing the Enter key now opens the current field for editing, in both the data sheet and form. As Dave mentioned, the tab key already did that, and pressing any character also opened the editor and inserted that character.

I would expect that, and that is what it does in my tests. I tried it with both standard Text Editor objects and when using the pop-up editing option. If you can come up with a sequence where that doesn’t happen, please let me know.

Sorry, I don’t recall that. Could you either find the old thread and bring it to my attention, or open a new thread here with details about what you are talking about? The only way I know of to have a non-empty cell look empty is if the cell has multiple lines, but the first line is blank. Panorama 6 was the same way.

I was not certain whether this was deliberate or not, but I thought if it was not, it would be trivial to fix. I am glad it was.

OK: First here’s an example of an empty-looking field that’s not actually empty (I’ve redacted personal information that appears on the actual forms):

Note the First Name field. Here’s what it looks like when I have clicked the “empty” field:
How I got here: a button on a form in another DB calls this procedure (please ignore whatever parts of the procedure are irrelevant but I don’t know which those are):

first=«First Name»
last=«Last Name»
nm=«First Name»+«Last Name»
Openfile "New Panx Alex Mail"
Field «FullName»
find FullName=nm
if (not info("Found"))
        «First Name»=first
        «Last Name»=last
        «Workshop #»=ser
        «Comments»= wksh
        «Date Active»=today()
        Openfarform "NewPanxAlexWorkshop","Entry"
    Field «FullName»
    Find «FullName»=nm
        case Form=""
         case Form="Energy"
        «Workshop #»=ser
         if «Comments»  NOTCONTAINS  wksh
            Comments= «Comments»+wksh
        «Date Active»=today()
    OpenFarform "NewPanxAlexWorkshop","Entry"
The form with the anomaly is in NewPanAlexMail, the posted-to DB. What the procedure did in this particular instance was to update this person's address, phone, and e-mail.

I’ll start a new thread about the other issue mentioned here.
Thanks as always,

Here’s an example of the other issue:

When I exit the Address field, a procedure is called that takes me directly to the Zip field. Here’s the procedure:
Field Zip
The result is shown in the screen shot. If I try to type in the zip code in the apparently selected Zip field, I just get a beep. I must click in the field to be able to enter anything. I looked a little in Help to see if there was something like an openfield statement that I could include, but there isn’t.

More info: in the datasheet, when I exit the Address field, the Zip field is selected and I can type in it immediately.
And more: I had the .toZip procedure in both the field definition in the datasheet and the code for the field on the form. I thought perhaps the redundancy was messing things up, so I removed the code from the field in the form; but it made no difference.

In the first instance, I notice that you are using red text. I wonder if that is causing the problem, especially since your system is using red highlighting. That could also explain why no one else has reported this.

For your second question, you cannot currently use the field statement to switch fields in code that is run after data entry. That is a known problem. I am probably going to eventually come up with a special way to do this, but for now, it is impossible to do reliably.

Nope, sorry. I changed all those fields to black, went through the post procedure again, looked at the posted-to form and there was a blank field again, this time Address (also black).

Well, if you want me to look at it, I’ll have to have an example file in-hand so that I can duplicate the problem on my computer, with the debugger running.

About switching fields, I’ve been doing it with that field switching statement so I could go directly to the Zip field and have it fill in the city and state with the city(Zip) and state(Zip) functions. So I thought well, don’t be rigid, just put the Zip field before the city and state fields and then you’ll be fine. But woe is me. I did that on the data sheet, but then when I filled in the zip code, the city and state fields got filled with “–”, as if city(Zip) couldn’t find the appropriate city. Why would that happen? Can the zip lookup only work on fields before it in the DB? And no matter where I put the Zip field on the form, it tabs in the order of the data sheet. Hmm.

On the subject of things not opening when they should, I was doing some Fill with Formula…s from the Morph menu, and when the dialog box opens, the box is not chosen for editing. Annoying!

Well, the tab order in your form must be set to Data Sheet Order. Sounds like you want to switch it to Natural.

It couldn’t care less what the order of the fields are. There must be something else going on.

I understand, it’s a perfectly valid thing to want to do, and I have databases that do that. But for now, you just can’t do it in Panorama X. The problem is that Panorama X has it’s own ideas of what the next field should be, and it doesn’t like it if a procedure tries to fight it on that. My plan is to make it so that a procedure can tell Panorama that it wants to skip to a different field, and then Panorama will do that after the procedure is done, overriding Panorama’s normal field switching behavior.

Bill, is it possible that you have another object in front of the text?

Interesting suggestion, but no, I don’t. And the “blank” field isn’t always the same one.

That was it. I forgot about tab order. I switched it to Natural and now my form works as I want it to when I put the Zip field before the City and State fields. Thanks.

So now the only remaining issue is this business of “blank” fields, which is still appearing. If nobody else is experiencing it, I may eventually rebuild the DB and see if there was something in the conversion. I accept that data is reliably transferred between P6 and PX, but forms are something else. I won’t waste your time on this until I’ve done that, in a month or so.

This appears to be a problem linked to the Pop Up Editing option in the Text Editor Object. Here is a demo of the problem with the TEOs set to Pop Up Editing:

With this option turned off the populated fields are not blanked when changing records and everything is properly updated.

Brilliant! It’s true that all my problem fields were set to Pop Up Editing, and when I changed that, it appears that the problem is no more. I’ll keep watching but it looks as if you’ve found it.

Thanks much!


26 June2017 at 1:02 PM

June 26
This appears to be a problem linked to the Pop Up Editing option in the Text Editor Object. Here is a demo of the problem with the TEOs set to Pop Up Editing:

With this option turned off the populated fields are not blanked when changing records and everything is properly updated.


William Conable*, Alexander Workshops, LLC*
| Mobile: 509-270-7492
815 Villard St.
Cheney, WA 99004


Designed with WiseStamp - Get yours