So far, we have achieved that all output is funneled through our custom streambuf. We will see now how we can tag on the message profiles. The idea is that we prepend the actual output we want to appear at some destination with a tag. This works much like a marginal note on a typed manuscript which directs the typesetter to format the manuscript in a given way, such as "Start a new page here" or "write this in boldface". In the same way, we prepend our message with a short string meant for our custom streambuf. Our custom streambuf object then sifts through the string it was given by cout, looks if there is any profile information, interprets it, and strips the ``marginal note'' off, leaving only the original string for output.

The user creates objects of type msg_control, which correspond to given profiles. In this example we create a error message used by the time-of-flight system, severity "error", type ``code debug'':

  msg_control *tof_error = new msg_control(MSG_TYPE_CODEDEBUG,
                                             MSG_SOURCE_TOF, 
                                             MSG_SEV_ERROR,
				             "Tof Monitoring");
  cout <<  *tof_error   << " this is an error message from TOF"  << endl;

The 3 parameters happen to be enumerated as 5, 7, and 2, respectively.

The last message identifies the "component" that generated the message. In the DAQ world, the component name has a well-defined meaning -- there is a CORBA name server that keeps track of name-based components (CORBA objects) that act together to get teh data taken.

In a user or subsystem monitoriung environment, you can pick a name to distinguish different monitoring processes from the the same subsystem, for example.

Our streambuf object will receive a string

 <| 5| 7|2|Tof Monitoring> this is an error message from TOF 

It will find the tokens, interpret the 3 numbers, strip the whole prepended tag ("<| 5| 7| 2|Tof Monitoring>") off, and deal with the original string based on what the profile is.

If our message did not have a profile, the streambuf will assign a default one.

You may wonder now how we prevent the tagged-on information from clobbering our output if we do not have a custom streambuf that could strip it off.

The ``msg_control'' objects we generate are completely silent if there is no custom streambuf in place. When we create such a streambuf, it talks to the msg_control objects and activates them, and when we delete it, it deactivates them again. So only if we have a custom streambuf in place (which will interpret and strip off the additional profile tag), this tag is actually produced.