showlater

The showlater statement defers the display of text and graphics until the procedure is finished.


Parameters

No parameters.


Description

This statement defers the display of text and graphics until all currently running procedures are finished. (This includes any subroutines called after this statement is used.)

To understand this statement, let’s first review how display normally happens. As a procedure runs, Panorama normally updates the display immediately as actions are taken. For example, consider this code that modifies three database fields.

First = "Bob"
Last = "Wilson"
Phone = "555-1212"

If you watch closely as this code runs, you’ll see that Panorama actually updates the display 3 times as this code runs - first to display the first name, then the last name, and finally displaying the phone number. In the example above this happens so quickly you might not notice it, but if you run actions that display the entire window this will be more noticeable. When you run the code below you’ll clearly see the window flash three times as the the code runs.

field State
sortup
field City
sortupwithin
select zipdistance(90001,Zip) < 50

In many situations you really don’t need immediate display of each change – it’s fine if the display doesn’t update until the entire procedure is finished. If you put a showlater statement at the top of the procedure, that’s exactly what will happen. Here’s a revision of the first procedure that doesn’t flash three times, only once at the end.

showlater
First = "Bob"
Last = "Wilson"
Phone = "555-1212"

Notice that you don’t need to tell Panorama update the display, it does that automatically when the procedure is finished. You also don’t need to tell Panorama what needs to be displayed, it keeps track of that itself.

Here is a revised version of the sort/select example that only flashes the screen once:

showlater
field State
sortup
field City
sortupwithin
select zipdistance(90001,Zip) < 50

Some Implicitly Triggered Procedures Automatically Defer Display

Procedures are usually triggered explicitlly by pressing a button or using a menu, but Panorama also has a variety of Implicitly Triggered Procedures that run automatically when specific actions are performed, for example when a record is modified or a form is brought to the front. Some of these procedures are triggered while Panorama is in the middle of performing another task that cannot be interrupted by updating the display. When running these particular procedures, Panorama automatically defers display until the procedure is finished running. It’s essentially as if you had put a showlater statement at the top of the procedure.

The implicitly triggered procedures that automatically defer display are:

Implicitly triggered procedures that are not listed above do not defer display (unless you include a showlater statement).

EndShowLater

When the showlater statement is used all display is normally deferred until the end of the procedure, but you can use the endshowlater statement to update the display immediately. All operations after the endnoshow statement will update the display immediately (unless you use the showlater statement again).

Note: You should not use the endnoshow statement in an implicitly triggered procedure that automatically defers display (see above). Panorama won’t stop you from doing this or throw an error, but this may cause incorrect operation.

The info(“showlater”) function

Use the info(“showlater”) function if your code needs to find out whether or not Panorama is currently deferring display. For example you could use this in a subroutine to find out if the code that called the subroutine has already started deferring display. You can also use this in an implicitly triggered procedure to double check whether Panorama has automatically deferred display during this procedure.

ShowLater vs. NoShow

Panorama’s noshow statement performs a similar function to the showlater statement. However, the internal operation of these statements are slightly different. To understand the difference, let’s review how Panorama normally updates the display when a change is made.

  1. Code makes a change to the database, either to an individual field (for example an assignment), a column (for example formula fill) or the entire database (for example sorting.
  2. Panorama analyzes each window associated with the database to determine what area of the window (if any) need to be updated. For example if an individual field has been modified, any open forms will be analyzed to see if any objects display that field (this usually happens because the formula associated with the object contains the field name). If there is any area that needs to be displayed, Panorama passes the co-ordinates of the area to the operating system.
  3. Panorama pauses execution of the code to give the operating system a chance to perform the run loop and actually update the affected areas. To learn more about this step, see Understanding the Run Loop. When the run loop finishes, the Panorama code resumes.

When the showlater statement is used, the third step is skipped. Panorama still analyzes what areas need to be displayed, but it doesn’t actually give the operating system a chance to display the changes. This eliminates extra flashes, and it also eliminates the problem of the operating system run loop interfering with the internal operation of Panorama when certain implicitly triggered procedures are run.

When the noshow statement is used, both the second and third steps are skipped. If you are performing a lot of operations, this will be slightly faster because Panorama isn’t taking the time to analyze what areas of the screen need to be updated. Usually this speed difference is insignificant, but if you are using a form with hundreds of objects and your procedure makes hundreds of changes, the difference may be noticeable. Note: Since step 2 has been skipped, your code must eventually explicitly specify what areas to display using showline, showfields, showpage, showvariables etc.

Here is an example of a procedure that clears out all of the line items in the current record. In it’s simplest form, the display is updated for each field immediately as the procedure runs.

looparray dbinfo("lineitemfields",""),cr(),fname
    set fname,?(datatype(fname)="Text","",zeroblank(0))
endloop

Running on an M1 processor with a database with 132 line item fields (33 line items with 4 fields for each line), the code above takes 205 milliseconds to run (about 0.2 seconds).

Adding the showlater statement doubles the speed, to 101 milliseconds.

showlater
looparray dbinfo("lineitemfields",""),cr(),fname
    set fname,?(datatype(fname)="Text","",zeroblank(0))
endloop

Using noshow is over 6 times faster, only 13 milliseconds.

noshow
looparray dbinfo("lineitemfields",""),cr(),fname
    set fname,?(datatype(fname)="Text","",zeroblank(0))
endloop
showline
endnoshow

Of course you might not notice an 88 millisecond difference in the real world. The noshow statement is slightly more complicated to use, so you’ll have to decide if the performance difference will be significant for your application.


See Also


History

VersionStatusNotes
10.2NewNew in this version0.