next up previous contents
Next: Raw Data Up: How XED Works Previous: Program Flow - Fortran   Contents

Program Flow - C++

Once run_xsnoman_until_needy is running the event loop, the program execution is now entirely event-driven. (For those unfamiliar with GUI programming, an 'event' in this sense is something like a mouse click or keypress; a WIMPS GUI does nothing but respond to these events and otherwise just sits there twiddling it's thumbs.)

A discussion is nessesary as to how the program executes from this point on. Let us start in the process while a user is looking at an event that is on his screen, say GTID 10.

If the user clicks the [-1] or [+1] buttons, XSnoed handles all the details; it has it's own buffer of recent events, and simply displays them. With this, the user can look at events from GTID 1 to GTID 10. SNOMAN knows nothing about these 'old' physics events (with the exception of calls to DMM to retrieve or set DAMN/DARN bits).

If the user goes back to GTID 10 and clicks on the 'Next/Pass' or 'Next/Fail' buttons, however, more things happen. First, xsnoman_set_result is called so that the XED return code can be used. (This is what lets XED be used as a filter.) Next, an x-windows event is queued to load a new event.

The XSnoed routine HandleEvents (in xsnoedstream.cxx) is responsible for handling this request. It then checks the a flag in it's ImageData (snoman_has_data) to see if there is a new event loaded. At this point there is not; SNOMAN is currently processing GTID 10, and GTID 11 has not yet been loaded with INP (or MCO). When this happens, HandleEvents sets a second flag: exit_to_snoman = TRUE. Then it regenerates the new-event request.

When this is complete, the program has now finished once cycle of the GUI event-loop, so control is returned to run_xsnoman_until_needy. The exit_to_snoman flag is checked, and when seen to be true, control passes back to the routine XED_SNOMAN_EXE.

Eventually, SNOMAN will complete it's processor list for GTID 10, and will load in GTID 11 and call XED. When this happens, the transfer_ds_info() call tells the C code of XED where the IQ, RQ, LQ arrays are, where the MAST banks is, and then sets the flag snoman_has_data to TRUE.

Then, run_xsnoman_until_needy starts. It resets exit_to_snoman to FALSE, and starts executing the event loop again. Immediately, the next event in the GUI event queue (a first-in, first-out queue) is the new-event request.

HandleEvents executes a second time, this time seeing that there is data available. This passes control to get_next_event which in turn calls xsnoman_load_event(). At this point, the XED C++ code starts going on a wild scavanger hunt through the SNOMAN datastructure (via the IQ, RQ, LQ arrays) to retrieve all the viewable data and passes it back to get_next_event, which passes it back to HandleEvents. Finally, HandleEvents calls xsnoed_event(), which puts the new event (GTID 11) up on the screen to be ooed and ahhed at by the adoring crowd.

This complex behavior is nessesary, since XSnoed is ignorant of the current status of SNOMAN, and vice versa.


next up previous contents
Next: Raw Data Up: How XED Works Previous: Program Flow - Fortran   Contents
sno Guest Acct 2009-09-09