Triggering versus posting functions and events
Triggering
In PowerBuilder, when you trigger a function or event, it
is called immediately. Its return value is available for use in
the script.
Posting
When you post a function or event, it is added to the object’s
queue and executed in its turn. In most cases, it is executed when
the current script is finished; however, if other system events
have occurred in the meantime, its position in the queue might be
after other scripts. Its return value is not available to the calling
script.
Because POST makes the return value unavailable
to the caller, you can think of it as turning the function or event
call into a statement.
Use posting when activities need to be finished before the
code checks state information or does further processing (see Example
2 below).
PowerBuilder messages processed first
All events posted by PowerBuilder are processed by a separate
queue from the Windows system queue. PowerBuilder posted messages
are processed before Windows posted messages, so PowerBuilder events
that are posted in an event that posts a Windows message are processed
before the Windows message.
For example, when a character is typed into an EditMask control,
the PowerBuilder pdm_keydown event posts
the Windows message WM_CHAR to enter
the character. If you want to copy the characters as they are entered
from the EditMask control to another control, do not place the code
in an event posted in the pdm_keydown event.
The processing must take place in an event that occurs after the WM_CHAR message
is processed, such as in an event mapped to pdm_keyup.
Restrictions for POST
Because no value is returned, you:
-
Cannot use a posted function or event as an operand
in an expression -
Cannot use a posted function or event as the argument
for another function -
Can only use POST on the last
call in a cascaded sequence of calls
These statements cause a compiler error. Both uses require
a return value:
|
1 |
IF POST IsNull( ) THEN ... |
|
1 |
w_1.uf_getresult(dw_1.POST GetBorderStyle(2)) |
Asynchronous processing in EAServer
Using POST is not supported
in the context of calls to EAServer components. For
how to simulate asynchronous processing by posting a call to a shared object
on an EAServer client, see
the SharedObjectGet function in the online Help.
For information about asynchronous processing in EAServer, see the EAServer documentation for the
ThreadManager and MessageService modules.
TriggerEvent and PostEvent functions
For backward compatibility, the TriggerEvent and PostEvent functions
are still available, but you cannot pass arguments to the called
event. You must pass data to the event in PowerBuilder’s
Message object.
Examples of posting
The following examples illustrate how to post events.
Example 1
In a sample application, the Open event of the w_activity_manager window
calls the functions uf_setup and uf_set_tabpgsystem.
(The functions belong to the user object u_app_actman.)
Because the functions are posted, the Open event is allowed to finish
before the functions are called. The result is that the window is
visible while setup processing takes place, giving the user something
to look at:
|
1 |
guo_global_vars.iuo_app_actman.POST uf_setup() |
|
1 |
guo_global_vars.iuo_com_actman.POST uf_set_tabpgsystem(0) |
Example 2
In a sample application, the DoubleClicked event of the tv_roadmap
TreeView control in the u_tabpg_amroadmap user
object posts a function that processes the TreeView item. If the
event is not posted, the code that checks whether to change the
item’s picture runs before the item’s expanded
flag is set:
|
1 |
parent.POST uf_process_item () |