Triggering versus posting functions and events – PB Docs 126

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:

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.

note.png 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:

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:


Document get from Powerbuilder help
Thank you for watching.
Was this article helpful?
Subscribe
Notify of
guest
0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x