In the loop of a RunDialog, if a Text Editor object is denoted as ‘FgName, a variable, and has in its procedure code
Select «Name» contains «FgName»
Resume {}
should that enable a search of the db when the user tabs through that field?
I have more questions than answers.
First of all, your title uses the word “background”, what do you mean by that? The Select statement cannot run as a background process - in other words, the Panorama UI will not be responsive while the Select statement is running. But maybe you don’t mean a background process, maybe you are thinking of running the selection in the window behind the dialog? I don’t think you can do that either.
You say this code is in the loop of a run dialog. The resume statement doesn’t ever go in that loop. The resume statement needs to go in the button or object that you want to trigger an action.
You say “when the user tabs through that field”, but I think you mean tabs through that variable.
Anyway, you really haven’t stated what your goal is. So as a wild guess, it sounds like you want to list the names that mage FgName in the dialog. I think that should not be done with select, instead you should put a Text List (or Matrix) in the dialog form, and set up the query in the Text List. If you do that, the search can be done in the background - it can even be set up to run as you type each key.
I can’t think of any situation where running a select statement when tabbing out of a text editor would be a good idea. Or doing a sort or any other operation that rearranges the entire database, or even moves to a different database field. When tabbing from editor to editor, you’re code is being run in between Panorama’s code for closing the previous editor and opening the next one. That Panorama code really doesn’t expect your code to do anything more than basic calculations.
The last paragraph refers to any code for tabbing, but for a dialog I also wouldn’t expect changes to happen to the database while the dialog is open. Instead I would expect the dialog to be used to set up the options for the proposed change, which won’t actually happen until you press the Ok button, or whatever the action button is that closes the dialog.
I am needing to know if a person is already in a +50,000 person db with as little typing as possible.
If the name is Maria Gonzalez, it takes a lot of typing as there are more than 20, so then there is the need for DOB, with that sometimes in multiples.
Seeing the results as the data is acquired speeds up the process tremendously. If the user types AAlmo into the last name field, they might immediately see that the desired person already exists, they press OK and we move on to the next stage.
The RunDialog is used to gather this data as the user can continue through many data fields that would be necessary if the person was new but stopping as soon as they find the person already exists.
By ‘background’, I meant that the Datasheet will be visible behind the RunDialog and I would like to see the results of the changing of the selection based on the entries into the variables that appear within the RunDialog.
The Select statement and the Resume {} are both in ‘Procedure’ of the TEO. That way I was hoping to only have it be an issue as I left that TEO variable.
I tried to accomplish all of what I need with the Text List but given that my record count is >50,000, the results have been less than acceptable with inconsistent results and speed. Names would appear, then disappear, inspiring little confidence which then caused the users to switch to ‘new person’ mode which then resulted in duplicate entries for the same person. It is imperative that we do not create multiple records for the same person. Given that the average human is lazy, my challenge is part psychological, part technical.
I have previously always just used multiple GetTextDialogs with Select/SelectWithin between each of them. I’ve just been attempting to accomplish with one dialog what RunDialog theoretically could do.
By ‘background’, I meant that the Datasheet will be visible behind the RunDialog and I would like to see the results of the changing of the selection based on the entries into the variables that appear within the RunDialog.
Not possible.
The Select statement and the Resume {} are both in ‘Procedure’ of the TEO.
What’s the point of the resume then?
Based on what you are trying to do I’m going to again suggest using a Text List. That’s exactly what the Find/Select dialog does. The speed is if anything going to be faster than using the Select statement, it certainly won’t be slower.
Note: For the fastest performance, make sure the Name field is close to the left edge of the data sheet. It’s not a huge difference, but as a field is moved farther to the right, access to the field gets a bit slower.
Names would appear, then disappear
If you turn off the “Update Variable Every Key” option then it will only do the search when the user hits Enter or Tab. That would be equivalent to what you’ve been doing with the Select statement.
In any case, I’m puzzled by your performance issues. I just tried the Find/Select dialog on the 313,000 record FAA Aircraft Registration demo database, and it’s nearly instantaneous when searching a single field. This is on a 4 year old laptop with an M1 processor. Perhaps your customers are using much older computers? Note that the Find/Select dialog is built using RunDialog, with a form that uses a variable edited by a Text Editor object and a Text List. There are no private APIs used by the Find/Select dialog, it would be possible for any customer to build a duplicate of this dialog using off-the-shelf Panorama components that are all fully documented. (That said, I’ll grant that creating this dialog took me multiple weeks to create, it’s very complicated. But that’s because it changes on the fly, not because it uses any non-standard components.)