ebmDevMag.com home
ebm Developer's Magazine
links

developer's mag
main page

article
part 1
part 2
part 3
part 4
part 5
part 6


4 - Calling Conventions

To use the dialog, a class object is created and called via GUI_EventLoop(). Note that there is no corresponding delete call, since GUI_EventLoop() handles object deletion. This means no cleanup, but also no access to the object after returning, making this a stateless dialog. In other words, there is no memory of previous results, since each call of the dialog is to a new object.

There are many techniques to create a dialog with a state memory, but one of the easiest is to pass pointers to parameters in the constructor. For instance, a text edit dialog could receive a pointer to the edit string. If this string contains the previous text, it will appear that the text dialog remembered the last entry - actually, the calling program did. Of course, this method has one complication: the constructor needs to store the pointers so other member functions can use them.

Pointers to objects also solve the problem of what to do when passing results back. If you look at the alert box code, the boolean flag 'result' is set by each button press, and then Close() sends the MSG_WINDOW_CLOSE message along with the result value. This value is thereafter returned from GUI_EventLoop(). This way of parameter passing limits the return to only a single value, certainly not enough for something like a text string. With a pointer, the object could write directly to the data, and nothing needs to be passed back separately. In addition, since the data is stored in the parent, subsequent calls to the dialog would appear to have a memory, even if it is faked.

Previous Section
Next Section

Copyright © 2001-2006 ebmDevMag.com - Legal Notice