Re: Dialog boxes

["Eric M. Monsler" <emonsler beamreachnetworks com>]

Good suspicion.

The chunk of code that gets executed to act on which button is pressed
should not be run by checking the return value of the function that
created the button.

Once the button is created, you're done.  I find it helpful, in
structuring program flow with callbacks, to think that way: Buttons are
up, program is done.  No further action on the program's part is
needed.  Oh wait, the operator has *pressed* a button!  Now we have
actions to perform, oh hey, and we have functions that are called when
the buttons are pressed, so the chunk of code mentioned above should be
in the button callbacks!

Just thinking in those terms may help a lot for structuring your code in
callback fashion.  (It may not, how do I know how you think?)

You will see references to MVC on this list, which stands for IIRC
Model-View-Controller.  So, there is some underlying state of your
application, the Model.  The interaction with the operator is the View,
so your display shows whatever amount or representation of the
underlying model is appropriate.  If I understand correctly, the
Controller aspect refers to the code, acting on inputs from the
operator, and modifying both the underlying Model and the View.

So for example, I have code in which it is possible to save the contents
of a self-updating display to file.  When the operator chooses "Save
Data", I pop up a file selection dialog, and I have modified the View,
but not the Model.  When the file has been selected, I open it, write
the current contents of the display, and mark in my state that all
display updates should also get written to file; this is the Model
change.  I also change the View, closing the file selection dialog.  If
the operator had selected Cancel instead of a file, I just modify the
View again.  In this simple example, I don't need to modify the Model on
putting up a dialog, because the logfile_selected() function is only
called when that popup is up, so that's all the state that I need.

At it's most extreme, the MVC could consist of two global state
structure pointers, this_state and prev_state, and every callback would
twiddle state variables, and then call process_state() to update view
and controller, and switch pointers.

I may have screwy MVC details, I've never studied it as a modern design
philosophy, just seen it discussed.

Eric