Section XX : an explanation by example of FOX messaging system
---------------------------------------------------------------

Now that you have read about what FOX can do and why it does it, in this section we will be discussing some real world examples which build on some of topics discussed so far.  One of the main justifications for a section such as this one, is the statement, "I still don't understand exactly what message is sent when, why and to whom.  Perhaps one of the experts should paint some UML sequence diagrams to illustrate."  We may/will get to some of the UML a little later in the discussion, but first we will be focusing on what messages are being set where, and so on.


Ok, let me try and explain with an example.  We will be creating a menubar with associated menupane, a toolbar with a button and textline and a statusbar.  This example is typical of the classical GUI that is prevelant in most 'modern operating system' applications.

[insert picture or two of any old app - probably the one we are building]

As we can see from the first picture, the menubar is at the top of the window, the toolbar sits below the menubar and the statusbar sits at the bottom of the applicaiton window.  Picture two is showing the state of the application, without the toolbar shown and with the mouse pointing to the toolbar menu entry.  You will notice that the statusbar shows some useful help information regarding the entry that the mouse is pointing to.

So back to the example, the menubar will activate a menu popup which will contain two entries.  An entry to show/hide and indicate status of the toolbar and an entry to show/hide and indicate status of the statusbar.   The toolbar contains two buttons, a button to quit the application, as well as a button to hide the toolbar.  The rest of the window is filled with an line of text (in big font of course!).  The statusbar shows relevant information pertaining to the application or to widgets as necessary.

The examples we are going to explain is a general explanation of some message types used throughout your applicaiton as well as throughout FOX itself.  Hopefully this will explain the WHAT, WHO, WHERE, WHEN, WHY, HOW of the FOX messaging system, at least for some simple examples.  All this will be done by explaining what messages are generated by who, in a step-by-step example.

The first example is an explanation of *the* major message type.  The second example is a more powerful demonstration highlighting the two-way facilities of the message system.  In particular the second major message type is demonstrated.  The third example will highlight the use of the FXDataTarget object.  The fourth example highlights message sources and destinations other than widgets - this is a continuation from example 3.  While the fifth example, provides a discussion of the FXApp class, and how it relates to the preceding examples.



Example 1
---------

A user clicks on the 'Hide' toolbar button (lets call the button 'buttonHide'), which  generates a SEL_COMMAND (Footnote: see chapter to brush up on message types) of the message identifier that it is currently configured with.  This message is forwarded to the currently configured target object.  Quite often the target and message id for the object is defined when the object was instantiated, though these can be changed at runtime.  The result is a toolbar button action, as you would expect from a toolbar in any modern application.


Aside:

I will be including lines of code to indicate what is happening where.  To create a button [footnote: You can find the definition of FXButton in the "Class Index"] in the application constructor:

  toolbar = new FXToolbar ( this )
  buttonHide = new FXButton ( this, "Hide", NULL, this, ID_TOOLBAR );

This is all you will need for these examples.  You will notice that the 'target' is the 'this' member, while the message is ID_TOOLBAR.  In this case, the target is your application and the message is defined in your appplications' class definition, ie some class unique enum.  In other examples, the target could be another widget or even a non-widget such as the FXDataTarget.  The message could be any message that is identifiable by the widget, by the class itself or by any of its parent classes.

Associated with this message identifier (ID_TOOLBAR), will also be a mapping:

  FXMAPFUNC(SEL_COMMAND,  app::ID_TOOLBAR,  app::someMethod)

For those of you familiar with the term 'callback', this is the technique that connects the widget action to the application method.  The benefit of using message id's and message types, is that any fully flegged FOX object (ie anything derived from FXObject), not just a button, can 'use' the callback, or in FOX terms, "any FOX object can use the mapping of the type and id, to an action".

So, the FXMAPFUNC is saying, "the target object is the application (ie the 'this' pointer is pointing to the app class), therefore your applications' method is called".

And the "someMethod" method that gets executed may or may not do anything with the GUI, or it may daisy chain the command onto another destination (as explained in example 2).

Note: we have mentioned that the button is mapped to the action, but have said that any FOX object is capable of using this mapping.  For a further explanation of how this is acheived, see example 4.

One more thing we need to re-interate on here.  Whenever a FOX derived class (eg, a widget or your application) is defined and implemented, we *always* FXDECLARE and  FXIMPLEMENT the class.

Now, onto the example...

The user presses buttonHide, by moving the mouse over the button and pressing the left mouse button.  I have specifically mentioned here which mouse button and the mouse movement for the reason that, as you will later in example 5, many events are generated for various reasons.

The result of the user pressing the mouse button is that:
- buttonHide captures the mouse click event that is generated by the GUI environment
- buttonhide figures out that it needs to show itself as pressed-in, at which point the button graphic is drawn pressed-in,
- since most people like the idea of being able 'undo' the button press by moving the mouse out of the geometry of the button, no event is generated on a mouse button press
- we now release the mouse button, while the mouse is inside the geometry of buttonHide
- buttonHide generates a message of type SEL_COMMAND with id of ID_TOOLBAR (remeber, this was the id the the object was constructed with.
- the message routing system comes into play via the use of commands such as:

  target->handle(this,MKUINT(message,SEL_COMMAND),NULL);

- notice that by specifying 'target', we now have all we need to activate the message routing.  This is achieved via the 'handle(...)' method.  [footnote: the handle() method is automatically added to every class during an FXDECLARE/FXIMPLEMENT.  This is how we can send evey FOX object a message, whether it understands it or not.]
- the handle method looks up the routing map for the target, then calls the appropriate method.
- therefore, the application (being the target in this buttonHide example), procedes to execute the functionality of the mapped method. This can involve a simple variable change (or even doing nothing at all), to a complete graphic re-draw, or even a completey unrelated task in another thread.  If the target doesn't contain an FXMAPFUNC of the message type and id, the message is ignored.
- finally, the action is considered complete.


Tidbit 1
--------

This completes example 1, but just to wet your appetite, here is a little more info which will help you understand example 2.

Once the action is complete, FXApp generates a SEL_UPDATE event, which (in essence) gets mapped to all widgets. ie in each widget, an FXMAPFUNC captures a SEL_UPDATE, in a similar manor to our buttonHide example.  The trick here is that, only widgets which could have possibly changed, ie, buttonHide on the toolbar, are sent the SEL_UPDATE of the message id of the system (ie the system id is zero (0) ).

The benefit of this SEL_UPDATE, is that the button can query the application, to figure out what it is meant to be doing.  So, for example, if you want the toolbar button to become checked in, even when you dont press the button, but when you do change the variable holding that info, then this technique enables that 'button update' functionality.


Example 2
---------

With every menubar, there exists a menupane.  A menupane can show various entries.  In our example it contains an entry which indicates whether the toolbar is currently being shown.  It does this by placing a tick-mark next to the menu entry.  It also provides as a means for the user to re-show the toolbar if it has been hidden.

  menubar = new FXMenubar ( this );
  viewmenu = new FXMenuPane ( this );
  new FXMenuTitle ( menubar, "&View", NULL viewmenu );
  new FXMenuCommand ( viewmenu, "&Toolbar", NULL, this, ID_TOOLBAR );

Note: You will notice that in example 1 I defined a button with a message of 'this' and ID_TOOLBAR.  I then associated an FXMAPFUNC for this button.  Now when I want to use that same functionality but from a different widget, I just need to specify the _same_ message type and id - I dont have to add another FXMAPFUNC entry.

Currently the toolbar is shown.  The 'menubar->toolbar entry' (now known as toolbarEntry) has a tick next to it.  How did toolbarEntry know that the toolbar is being shown?  In 'tidbit 1', I mentioned the concept of a SEL_UPDATE - we will now contiue that path.

- FXApp generates a system SEL_UPDATE for toolbarEntry.
- toolbarEntry understands the SEL_UPDATE request and so generates a 'question' as follows:

  target->handle(this,MKUINT(message,SEL_UPDATE),NULL);

- remember, the target (the app) and the message (ID_TOOLBAR) were specified in the constructor of the FXMenuCommand, when the menupane was created.
- since our app knows whether the toolbar is shown or not, we can 'respond', with something similar:

  sender->handle(this,MKUINT(answer,SEL_COMMAND),NULL);

- where 'sender' is the source of the origonal message (toolbarEntry) and the answer is something silimar to ID_CHECK or ID_UNCHECK.
- toolbarEntry then draws a tick-mark based on the anser that it gets
- the SEL_UPDATE is now complete - you will notice that nowhere did we speciically get the toolbar to tell the toolbarEntry to show a tick, only that "whoever sent a question to us, here is the answer"

We have now demonstrated the 'two-way' nature of messages in FOX, and it is the basis for all widgets in FOX.  One point to note, this SEL_UPDATE process is continually undertaken at the end of all other processing.  For example, we press a button which activates an action.  Once the action is complete, a round of SEL_UPDATES occurs.

In example 1 I mentioned that we could daisy chain the events.  Since the SEL_UPDATE from the system, is just another type of FXMAPFUNC'ed message, the toolbarEntry has daisy chained the SEL_UPDATE onto another destination, in this case the app.

As a final note for example 2, I mentioned that the app knows whether the toolbar is shown.  It knows this by explicately asking the toolbar for its current state.  Given that all FOX widgets work the same way, we could have (and probably should) directly connect the toolbarEntry, to the toolbar, as shown:

  menubar = new FXMenubar ( this );
  viewmenu = new FXMenuPane ( this );
  new FXMenuTitle ( menubar, "&View", NULL viewmenu );
  new FXMenuCommand ( viewmenu, "&Toolbar", NULL, toolbar, FXWindow::ID_TOGGLESHOWN );

This change directly connects the toolbarEntry to the toolbar shown status.  The result is that our app no longer needs to concern itself with figuring out what mappings need to take place, and what FOX objects needs to be managed.

A final note on widgets:
By connecting the toolbarEntry to the toolbar, the toolbar responded by catching SEL_UPDATE, then generating a SEL_COMMAND.  It /should/ catch this message type, since, it is the object that knows its own state (rather than ave some third party, such as the app, to maintain the widget status) but in some widgets that strategy may not be appropriate

[footnote: FOX has tried to use common names for common types of functionality - ie, an FXMenuCommand reacts to an ID_CHECK by putting a tick next to the text, where as an FXButton will show the button as pressed in, while a radio button will show it as 'checked'.]

Thus, the GUI state information flow is maintained by widgets self updating themselves based on other information.  In some cases that information comes from other widgets, while some may come from your application, while some may come from variables themselves.  The state information is not only unidirectional (from a widget to some handler in your application) but also the other way round.

In most other GUI's mechanisms there is a callback from the widget to the handler, to inform the program that something has been changed by the user.  Unique to FOX however, is that there is another callback with which the GUI updates inself to reflect the state of the application; in most other GUI toolkits this is done by having the program explicitly fill in the various widgets with their correct value.  In small applications, the FOX method may seem unnecessary - in fact it can seems quite cumbersome to come to grips with using a two-way message paradigm, but once applications get larger (beyond even just a few widgets in complexity), the FOX mechanism is far superior.  You simply, "Implement the callbacks for the SEL_UPDATE handler to update the values shown in the GUI; you do not need to worry at all about WHEN or WHERE these values have been changed in the program".

The best bit is that once your widget is defined, you never need to change the mappings - a widget can only know how to draw itself a certain way (which, when you think about it, it makes sense - a button only knows how to draw its state base on a few events) and because the GUI updating mechanism runs "in the background" it does not interfere with the normal operation of your program.


Tidbit 2
--------
As there are sometimes many widgets which change one particular data value in your program, it is often desireable to write code in a way that makes it oblivious to the actual widget type or the reverse, to make the widget  oblivious to the data type.  It it would also be nice to not have to map a message id for each type of widget.

A cool idea was that instead of obtaining the value like:

long MyApp::onCmdValueChanged(FXObject* sender,FXSelector,void*){
  FXSlider *slider=(FXSlider*)sender;
  FXint myint=slider->getValue();
  ...
  return 1;
  }

We write it by using a message:

long MyApp::onCmdValueChanged(FXObject* sender,FXSelector,void*){
  FXint myint;
  sender->handle(this,MKUINT(ID_GETINTVALUE,SEL_COMMAND),(void*)&myint);
  ...
  return 1;
  }

Take a look at the code closely.  You will notice that the first entry is simplier to read, which contracdicts with the statement 'every line of code that you dont write, is one correct line of code'.  In fact, since we are now using the handle() method for accessing the object, we now nolonger need to concern ourselves with unusual object method names.  The second block will execute on all FOX objects, which the first wont even compile if the object doesnt have the getValue() method.

Using this technique, it gives now us a facility to ask an object for a value from which we can do something with it, ie. FXLabel, FXTextField, FXSlider, and so on, all understand this message, but of course they each implement this message in different ways:- in the case of FXTextField, for example, the text may first be converted to an int.

How is this useful?

Example 3
---------
Now that we have a way to pass information from one widget to the next, irrespective of the type of widget, we can now do some funky stuff.

Wouldn't it be useful to be able to change a value in program code, thus _automatically_ have the value reflected on screen?

Say we have a counter which increments how often the toolbar is hidden.  (We may be spying on our employees!)  It would be nice to be able to display that number, just to let the user know.  Well, by using the two-way messaging scheme, we have a facility where the textLine can interrogate the application, to figure out what is meant to be displayed.

In our toolbar example, each time the user hides thes toolbar, we programatically increment the toolbarHide counter:

  toolbarHide++;

But how does the textLine know what to display?  Remember that at the end of a sequece of events, a SEL_UPDATE is generated causing widgets to interrogate the applicaiton to figure out as to what is meant to be displayed.  The textLine is no different.  On construction we tell the textLine that the target is an FXDataTarget:

  FXint toolbarHide = 0;
  dataTarget = new FXDataTarget ( toolbarHide );
  textLine = new FXTextField ( this, 2, dataTarget, FXDataTarget::ID_VALUE );

From now on, textLine will display the 'value' stored in the dataTarget.  How does it do this?

- the system generates a SEL_UPDATE which the textLine catches.
- the textLine then generates a SEL_COMMAND, directed to the dataTarget:

  target->handle(this,MKUINT(message,SEL_UPDATE),NULL);

- where target is dataTarget and message is FXDataTarget::ID_VALUE (ie pass me a VALUE update).
- dataTarget then responds

  sender->handle(this,MKUINT(FXWindow::ID_SETINTVALUE,SEL_COMMAND),(void*)&data);

- We have just undertaken a two-way message, as well as a daisy-chain here, the textLine widget daisy chained a SEL_UPDATE command, onto another object, which responded with its stored value.
- we can now quite happily change the value of toolbarHide without ever needing to specifically execute applicaiton code for the callback.

As you might come to expect, the example can go in reverse, if the user decides to change the value in the textLine by editing the value with the keyboard:

- the user types in a value
- the textLine generates a SEL_COMMAND to the dataTarget to change its value.
- the app (once finished its events) generates a SEL_COMMAND which the textLine catches
- the textLine then ask the dataTarget what the new value is, by way of a SEL_UPDATE
- the dataTarget responds with a SEL_COMMAND causing the editLine to draw the new value.


Example 4
---------
We have explained some details of widgets which uses the SEL_UPDATE functionality to 'query the application' to figure out what it is meant to do.  In many cases no glue programming is required since widgets talk directly to each other. In other cases only minimal glue logic is needed.  To enhace specific functionality, the application programmer uses object inheritance to create the specific functionality they need.  We are now going to take a quick look at a few simple widgets, and try to explain the concpet of 'no glue code'.

In this example we will be explaining:
- FXTooltip
- FXSatauslin & FXStatusbar
- FXButton
- FXCheckButton & FXRadioButton

The specific examples that follow are endemic of the functionality provided throughout FOX.  Since they are simple to follow, they are discussed here.

For a more complex widget example, take a look at the discussion on the FXText widget.  Most widgets only implement a small subset of FOX message types and ids that can be generated.  FXText and similar widgets are 'complex' widgets which, rather than 'just' draw themselves, thay are containers which embed many widgets as well as adding new functionality.  But you do not have to make such a complex widget to start embedding other widgets.  The FXLabel widget is a container for an FXIcon as well as the text that is actually drawn.

FXTooltip
---------
Modern GUI applications have a facility called "tool tips".  They are little pieces of help text which is shown when the user moves the mouse ovar a widget.  Given that the FXDataTarget is capable of connecting a raw value, to a widget, using a two way messaging technique, to create a tooltip facility, all that we need to do is create a 'tooltop window' which displays itself with the correct text, based on where the mouse is.

The tooltip widget uses the facility, "ask whatever widget is under the mouse, for its default 'ID_QUERY_TIP'".  For widgets that support the concept of tooltips (eg an FXButton), the wdgets resonds with setting the value of the string.  For widgets that dont support tooltips, the message is simply ignored.  The tooltip widget then displays a popup window containing the responded text.

Describing this as a series of steps:
- create the FXTooltip widget in your MainWindow constructor
- When the application is finished processing any user input, an app wide SEL_UPDATE is generated
- FXTooltip catches the SEL_UPDATE, then procedes to 'schedule' a timer which will cause the tooltip to be displayed a few seconds later
- if the mouse is still over the same widget as when the SEL_UPDATE fired, a SEL_COMMAND of id FXWindow::ID_QUERY_TIP is generated at the widget
- The widget has the option of whether or not to catch the message.  If so, it sets the ptr argument of the message, to a text string.
- the app then returns to FXtooltip which detects whether the widget handled the message.  If so, a window is displayed containing the tip text.  If not, nothing further happens
- the tip text then stays onscreen until either, a pre-defined interval based on the length of the message, or the user moves the mouse outside the widget

The widget under the mouse pointer is totally unaware of what kind of widget sends the query message, it just knows to setting the 'ptr' parameter to the tooltip text.

FXStatusline & FXStatusbar
--------------------------
An FXStatusline is a widget that displays help information in a similar way to a tooltip, though the content of a statusline and a tooltip can be different (and usually is).  The FXStatusline works in a very similar way to the FXTooltip.  When an app wide SEL_UPDATE is generated, the statusline tries to query the target object for help information (ie SEL_COMMAND with FXWindow::ID_QUERY_HELP).  The target can then respond as appropriate to the message.  The statusline then either displays the rsultant text if there is any, or displays the default message.

An FXStatusbar provides similar functionality to an FXStatusline, but is actually a simple container which can contain other widgets when embedded into the statusline, along with an FXDragCorner to allow the user to resize the window.

FXButton
--------
As we have seen with an FXTooltip, and previous examples, the SEL_UPDATE mechanism plays an important part in maintaing the correct 'look' of the widgets in an application.  Where sensible FOX has used sensible values for each problem domain.

In the case of a simple button widget, there are two different items of data that need to be represented.  They are, the concept of a disabled button, and a concept of an activated button.  They both form the 'state' of the button.  Normally a disabled button will draw the text label in a dull greyed-out colour, and the icon will loose most of its colours and looked greyed-out also.  While the activation is indicated by whether the button is 'depressed' or not (it may be quite unhappy, but I'm refering to the 3D appearance).

For a button to correctly show itself:
- the application generates an app wide SEL_UPDATE which the button catches
- the button then queries the 'target' object (as defined in the constructor) by generating a SEL_UPDATE using the 'selector' (again, as defined in the constructor).
- the target (some FOX derived object, such as the application of a widget) then either responds or ignores the message.
- if the target ignores the message nothing happens to the button.  The target may respond by disabling/enabling the button (SEL_COMMAND with FXWindow::ID_DISABLE/FXWindow::ID_ENABLE) and/or activating/de-activating the button (SEL_COMMAND with FXWindow::ID_CHECK/FXWindow::ID_UNCHECK)
- the button draws itself according to the response of the target

An FXButton is capable of responding to an ID_QUERY_TIP that is generated from an FXTooltip and is capable of responding to an ID_QUERY_HELP from an FXStatusline.

FXCheckButton & FXRadioButton
-----------------------------
The FXCheckButton and FXRadioButton only differ slighty in functionality (they do look different), in that an FXRadioButton is capable to automatically un-checking itself when placed in an FXGroupBox.  In both cases, they are very similar to an FXButton.  They activate when clicked on to generate a SEL_COMMAND, they respond to ID_QUERY_TIP and ID_QUERY_HELP and they query the target object for state information.


Example 5
---------
We could continue describing how widgets work, but if you understand the concept described so far, then it is a relatively simple extension to understand the rest of the FOX messaging system.  If you dont quite 'get it' regarding what messages are being generated, you wany want to revise the first four examples rather them move onto the fifth example, since this example introduces message types that have yet been described.

The FXApp object (every FOX application needs exactly one) is the primary dispatcher for all messages generated via external input such as the keyborad, mouse, sockets, threads events, timers, idle time and so on.  It is also the part of the application which causes the application wide 'system SEL_UPDATE' events to be generated.  Since FOX must handle external input via many differing sources, you would expect it to be capabe of generating messsages types of more than just SEL_COMMAND and SEL_UPDATE.

Widgets present a problem domain which changes over times as users and desigers enhace the 'uisre interaface experiance'.  To acheive this, the GUI system must provide a mechaanism for detecting various states required by the varied widget types, eg when a mouse moves over a button, the button should 1) automaticaly raise its height to aid in visual feedback that the user is over the correct button, 2) the statusline should display some useful information 3) the tooltip should describe the action about to take place.

To acheive this need, FXApp generates message types for:
- SEL_ENTER - a button captures this to detect when to auto-raise itself
- SEL_LEAVE - a button captures this to auto-lower itself
- SEL_PAINT - another window which was just covering this window, was removed causing this window to re-draw itself
- SEL_KEYPRESS - a button an use this event to capture a 'hot-key' event
- SEL_CLOSE - is generated by the window manager to close an applicaiton

The list goes on for many message types, including support for drag-n-drop, window resize, mouse press/release and so on.  I specifically havn't mentioned mouse double-click (and triple-click) since they are simulated for most widgets by capturing a mouse press and measuring the time difference between each press.

FXApp also generates message types for SEL_TIMEOUT (for executing events after a period of time), SEL_CHORE (for executing events during idle periods), SEL_IO_READ/SEL_IO_WRITE (for sockets) and the list goes on.  For most applications, you may or may not use any or all of these features.  You do not have to concern yourself with handling every message type or id - you handle the messages that you are interested in.

Since widgets are often the target for some data, it will often be nesessary to design an application specific widget which can understand the problem domain that is trying to be mapped.  The FXText widget is a good example of a widget which is capable of understanding a large umber of message typs and id's.  Alternatively, FOX may provide a sufficiently large widget set (for the problrm domain), for which it is then just a matter of filling in applicaiton specific details, by catching message types and id's as appropriate.

We have mentioned previously that an applicaiton wide 'system SEL_UPDATE' is generated once all applicaiton processing is complete (ie the applicaiton returns to the event loop).  FXApp the is source of this SEL_UPDATE.  The final taks before return to user input, is to get each widget to interogate the application, to figure out what state it is meant to be displaying.  FXApp does this by walking the widget tree and generating a message of SEL_UPDATE with an id of zero.  Once the tree has been walked, the applicaiton is ready for user input.

At the end of processing a event such as a mouse click, all required appliation code will have been executed.  For example, pressing a button hides a toolbar.  FOX is equipped with a GUI layout mechanism which waits for all events to complete before redrawing the application.  The biggest benefit of this is that all of the drawing commands that have just taken place during the application code, can be co-allesced into a few drawing calls.  This technique greatly speeds up any drawing steps that have taken place.



Summary
-------
We have reached the end of this section.  We described an example which we expanded on, styp-by-step.  For most widgets, handling SEL_COMMAND and SEL_UPDATE is quite often sufficient enough to implement most of the functionality required of a program.  We have demonstrated two-way messaging between a widget and a target (from which a target replies to the sender).  We have demonstrated that widgets pass information to each other via the 'ptr' parameter.  We have demonstrated that no glue logic, or minimal glue logic is all that is necesary to connect two independant widgets together.  We have explained that the SEL_UPDATE events are generated at the end of every event sequence, thus allowing widgets to interrogate the application.  Finally we explained that various message types and id's are used to create an enhanced user interface experiance.

Some key points to remember when developing your applicaiton or a widget:
- We are totally unaware of what kind of widget sends us the SEL_UPDATE callback --> we just provide the sender, whatever it is, the desired value by means of a message.
- Messages can be one-way or two-way in nature.
- Other objects can uses the callbacks that have previously been registered, without the need to modify any of the glue code
- Once we got the idea of widgets not only sending messages but also receiving them, we applied this idea for a lot of other scenarios, so now for example you can hide/show GUI controls by means of a message, you can enable/disable controls, and get/set integer, real, string, and color values.

Why is this message passing cool?
- It allows you to write only one handler which can be used for several GUI controls.
- It decouples GUI and handler, and allows you to e.g. change a textfield into a spinner without any other changes.
- It makes a thing like FXDataTarget possible, which basically eliminates the need to write any handler at all!
- Controls can be easily greyed out by sending ID_DISABLE or ID_ENABLE messages from a SEL_UPDATE handler (every control in FOX understands these two messages).

