My experience and expectation is that GetText pauses a procedure to receive input. I have a procedure in which it’s inconsistent, but mostly cruises on with the GetText dialog sitting on the screen.
The GetText appears reliably:
Let lvDataSet = "Data Set Name"
gettext "Name of Data Set?",lvDataSet
If lvDataSet = "" Stop EndIf
But more often than not it continues to run. I’ve been unable to make it pause and resume when one of the buttons is pressed. The procedure runs to completion properly but without the requested input.
I can’t imagine why it wouldn’t pause. I tried your code and it paused every time. Though I had to add some additional code at the end, otherwise I had no way to know whether the code was continuing or not.
My form does have two text lists, but neither has a query or Background set. Mine is preceded with:
SelectAll
RemoveAllSummaries
Let lvData = ""
ArrayBuild lvData,cr(),"",exportline()
It’s followed by some Case statements that determine a path. Then there’s a SaveDialog. Typically the SaveDialog appears on top of the GetText and works using the default value of the GetText. After runnign teh GetText is still on the screen.
The hardest part of analyzing this one is that if I run it repeatedly, there are times that it pauses at the GetText, but then fails to resume when I click OK.
Just now I determined that it stops at the GetText if I had previously clicked Cancel to close the GetText after the procedure has fully run.
This was exactly my fix. Sorry that I left that out from my original comment.
I also confirmed that this error only occurs when you have “enough” records. To me, this means that the procedure logic is affected by how long selectall takes to perform the task. With this in mind, I’m wondering if eventually, with more records, wait 1 would have to be changed to wait 2, and so on.
Hugo, with the second database you sent me I was able to duplicate this behavior. Sorry it took so long for me to get to it.
I was able to eliminate this behavior by clearing out the ∂ field. It would still work even if the Background option is checked. In other words, even with Background checked, the alert pauses properly, as long as ∂ is empty. Of course with ∂ empty the counter below the text list will not update.
Actually, another way to “fix” the problem is to leave ∂ set to _liveSearch and turn off Background. In that case the alert or dialog will also work correctly.
The problem here isn’t with selectall, and it isn’t with the message or gettext statement. It’s a more systemic problem related to how the run loop interacts with the Text Display capability of updating an external counter object as it searches.
I’m going to assume you’ve watched my session about the run loop. When an alert or dialog pops up, Panorama puts any procedure on hold until the button is pressed. A procedure also gets put on hold when you update the display. For example, the selectall statement causes windows to refresh, and the code after the selectall statement won’t run until that refresh is complete.
Apparently when the Text Display object updates the count in the background, it is incorrectly resuming any procedure that is on hold, for example if there is an alert. This is happening after the selectall statement has run, as the Text Display object searches the elements in the list (Matrix objects are going to have the same problem). So in this case, the alert pops up, but meanwhile in the background the Text Display object is searching the list to figure out what to display, and that causes the paused procedure to resume.
This may or may not be an easy problem to fix. I know that there are some other tricky issues in Text List/Matrix updating that continue to be unresolved. For now, I think if you need to combine a Text List/Matrix with a modal dialog or alert, it would probably be best to either not use the Background option, and/or not display an external record count.
It’s actually not how long selectall takes to perform the task, it’s how long the Text Display object takes to scan the database. (Also note that the same issue would occur after any operation that changed the database display - select, sort, etc.)
Maybe. But maybe not, because Text Display objects by default only display a maximum of 5,000 cells. If you increased that, and had a bigger database, you might need a longer wait. But I think a better solution would be as I described above, either disabled the Background option or clear out the ∂ option. Or don’t use a modal alert or dialog.
