[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

4.20.3.3 Sending and Receiving Signals

AWS supports signal sources and sinks. A signal is simply a bit of information that lets someone know that something happened. A signal source is an object that gives out signals. A signal sink is an object that receives them. A signal slot is a conduit that manages a connection between sources and sinks. All AWS components are signal sources. They are derived from `awsSource', and thus support all the functionality of that class.

Signals are very distinct from Events. Signals are usually not sent for vents like `MouseDown', etc. A signal usually indicates that something important happened to the source. Good examples of signals are `TextChanged' for a text-box or `ButtonClicked' for a command button. These indicate that the user has gone through a series of complex motions, and has triggered the component to do something that it was programmed for. Signals do not include extra parameter information, simply a 32-bit value that indicates what happened.

Signals are unique to each component. Therefore, you never have to worry about namespace conflicts. For instance, if you want notification when a command button is clicked, you can connect your "button clicked" handler to the button like this:

 
awsSlot slot(mySink);
slot.Connect(cmdbutton,
  awsButton::sButtonClicked,
  doSomethingUsefulTrigger);

The parameter to the slot is the class that contains your sink. This can be any class derived from `iAwsSink'. For the connect call, the first parameter is the signal source that you are connecting to, the second is the signal you want notification of, and the final parameter is the identifier of the trigger you want activated on the sink when signaled. A single slot can map between a number of sources, signals, and triggers. To get the trigger identifier (which may change every time your application is run) you merely need to call GetTriggerID() on the sink with the name of the trigger that you want.

 
unsigned long trigger = mySink->GetTriggerID("LoginUser");

What this means is that you don't have to override the `awsButton' class to find out what's going on. In fact, you don't even have to know about the button. All you need to know is that it supports the signal. If it doesn't support the signal, by the way, you will simply never get any information about it. Your slot will never become active.

A slot maps back to a sink's trigger. A single slot is always bound to a single sink, but there may be other slots bound to the same sink. When a trigger gets activated, it's passed in a reference to the source of the signal. That way it can get any information that it needs out of that source. A trigger could use this information to find out what type of component the source is and cast it to the correct type. The primary means for doing that resides in the GetProperty() and SetProperty methods. These allow you to request a property by name from a random component. If the component does not support the property, the call will fail in a graceful manner.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]

This document was generated using texi2html 1.76.