The executeasap statement executes the specified code at the first possible opportunity, non-atomically.


This statement has one parameter:

code – code to execute in the next run loop.


This statement executes the specified code at the first possible opportunity. The code will be executed non-atomically, so it is always allowed to display data changes, switch window configurations, and save datatabases.

Usually the only reason to use this statement is to allow atomic code to trigger non-atomic code (see Understanding the Run Loop). For example, suppose you want a dialog sheet to appear asking for a name every time a new record is added to a database. You can’t normally do this with the .NewRecord procedure, because that procedure is not allowed to open new windows with a statement like gettextdialog. But by using the executeasap statement, you can postpone the operation of the gettextdialog for a fraction of a second, until after Panorama has finished creating the new record. At that point it is safe to do whatever you want.

executeasap {gettextdialog Name,
    "Prompt","Enter this person's name",

Though the executeasap statement makes it safe to do whatever you want, we recommend that you think long and hard about whether you really want your database to work in this unusual way. If you need to use the executeasap statement to accomplish your task, you are probably creating a very non-standard user interface that probably goes against the best modern practices in UI design.

Also if you’re not careful, the executeasap statement could get you into an endless loop that can only be cut short by forcing Panorama to quit. For example, suppose you put the code above into an execute( formula in a text display object. Simply displaying the object would trigger the dialog, then closing the dialog would display the object again, opening the dialog again, ad infinitum. So look out for this situation.

See Also


10.2NewNew in this version.