There are actually two types of CxMessages.  The first, cxm_ievent,
corresponds to an input event and travels through the Commodities Exchange
network.  The other type, cxm_command, carries a command to a commodity.
A CXM_COMMAND normally comes from the controller program and is used to
pass user commands on to a commodity.  A commodity receives these commands
through an Exec message port that the commodity sets up before it calls
cxbroker().  the newbroker's nb_port field points to this message port.  a
commodity can tell the difference between the two types of CxMessages by
calling the cxmsgtype() function.

    ULONG  CxMsgType( CxMsg *cxm );
    UBYTE *CxMsgData( CxMsg *cxm );
    LONG   CxMsgID  ( CxMsg *cxm );

A CxMessage not only has a type, it can also have a data pointer as well
as an ID associated with it.  The data associated with a cxm_ievent
CxMessage is an inputevent structure.  by using the cxmsgdata() function,
a commodity can obtain a pointer to the corresponding InputEvent of a
CXM_IEVENT message.  Commodities Exchange gives an ID of zero to any
CXM_IEVENT CxMessage that it introduces to the Commodities network but
certain cxobjects can assign an id to them.

For a cxm_command cxmessages, the data pointer is generally not used but
the ID specifies a command passed to the commodity from the user operating
the controller program.  The cxmsgid() macro extracts the id from a
CxMessage.

 a simple commodity example 
 controller commands 
 shutting down the commodity