Peg Signals - Casio ClassPad 300 Programming Manual

Sdk programming guide
Hide thumbs Also See for ClassPad 300:
Table of Contents

Advertisement

If you load message pTarget values with pointers to application objects, you must insure
that the object is not deleted before the message arrives. When a user defined message
contains a non-NULL pTarget value, there is no verification that the pTarget field of the
message is a valid object pointer. For this reason, in some situations it is better to use
NULL pTarget values, and route messages using object IDs. If PegPresentationManager
is unable to locate an object with the indicated ID, the message is simply discarded.
There are also differences between these methods in terms of the order in which things
are done. If you push a message into PegMessageQueue, the sending object immediately
continues processing, and the target window will receive and process the new message
after the sending window returns from message processing. If you call the receiving
window's message handling function directly, it will immediately receive and process the
message, in effect pre-empting the current execution thread. While these differences are
generally inconsequential for user-defined messages, they can be very important for PEG
system messages.

Peg Signals

Messages are used to issue commands or send other information between objects that are
part of your user interface. In the previous section we learned that a common use for
user-defined messages is to provide notification to a parent window when a child control
has been modified. This usage is so common, in fact, that PEG has defined a simplified
method for defining these messages and a corresponding syntax for receiving them. This
method is called signaling, and the messages sent and received via signaling are called
signals. Signals are designed to simplify your programming effort by reducing the
complexity associated with windows and dialogs containing a large number of child
controls.
PEG defines many different signals that can be monitored for each control. Whenever the
control is modified by the user, the control checks to see if you have configured it to
notify you of the modification. If you have, the control automatically generates a unique
message number based on the control ID and the type of notification. The message source
pointer is loaded to point to the control, and the message is then sent to your parent
window or dialog.
To receive a signal, PEG defines the SIGNAL macro, which is used in your parent
window message processing function. The parameters to the SIGNAL macro are the
object ID and the notification message in which you are interested. The SIGNAL macro
is a shorthand method for determining the exact message number sent by a control with a
given ID and corresponding to one of the possible notification types.
A simple example of using SIGNALs is detecting a button click. To send a signal, your
button must be created with an Object ID greater than 0. For example, here is the
creation on the save button taken from the AddressBook example that came with the
SDK:
27

Hide quick links:

Advertisement

Table of Contents
loading

Table of Contents