Kbase 13068: PROCESS EVENTS IMMEDIATE DISPLAY MULTITASKING INTERVAL
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/10/1998 |
|
PROCESS EVENTS IMMEDIATE DISPLAY MULTITASKING INTERVAL
ISSUE
=====
Under Microsoft Windows, the following V6 code does not work as it
did in Version 6:
status default "This is my status default line".
define variable a as integer.
do a=1 to 500:
display a.
end.
Explanation
===========
By default, the Windows product ships with the settings set to
maximize performance at the expense of screen drawing. Windows has
a non-preemptive task manager which means that all applications must
cooperate with the operating system and give up CPU in a timely
fashion in order for each application to behave correctly. The way
this is accomplished is by looking at the application's message
queue. If the application does not do this, then it will eat up all
of the CPU cycles for itself. On the other hand, if an application
is not looking at its message queue, it can never receive the PAINT
messages that notify it to draw certain areas of the screen. The
above program falls into this category.
In order to assist 4GL developers in this area, several 4GL
attributes and statements have been added and are described in
detail below.
STATEMENT: PROCESS EVENTS
Placing this statement in your 4GL code is a way of telling PROGRESS
to process any outstanding messages in the applications message
queue which will potentially cause other applications on the system
to be able to receive CPU time. This statement is useful in polling
situations when you want to check for the user pressing a cancel key:
define button b_cancel label "CANCEL".
define cariable test as logical.
form "Processing..." skip b_cancel with frame x title "test".
ON CHOOSE OF b_cancel test = FALSE.
test = TRUE.
REPEAT:
IF (test) THEN
DO:
/* some processing */
END.
ELSE
LEAVE.
PROCESS EVENTS.
END.
In this case PROCESS EVENTS will cause the click to be detected
(if there is one), which causes the test variable to be set, and the
loop to exit the next time through.
In the original example, placing PROCESS EVENTS after the DISPLAY
statement in the DO loop will yield V6 behavior, another alternative
is to set IMMEDIATE-DISPLAY as described next.
ATTRIBUTE: SESSION:IMMEDIATE-DISPLAY
This session attribute controls whether we draw immediately upon
receiving PAINT messages or wait intil we reach an I/O blocking
state. The default is NO. In the original example above, adding
a SESSION:IMMEDIATE-DISPLAY statement before the DO loop will cause
the program to behave just like Version 6. It can also be set at
startup via the PROGRESS.INI file.
ATTRIBUTE: SESSION:MULTITASKING-INTERVAL
This session attribute controls how often the PROGRESS engine checks
its message queue outside of an I/O blocking state. By default the
value is 0 which means that PROGRESS never checks the message queue.
Setting this value to 1 will cause the loop to get executed every
time through. This will give you maximum Windows compatibility at the
expense of slower performance. Setting this value to 9999 will give
you minimum Windows compatibility with better performance. The actual
checking of the message queue occurs after every statement in RUN
mode and after every statement is processed in COMPILE mode.
Progress Software Technical Support Note # 13068