Re: Dialog boxes

["Chris Garrett" <garrett91 hotmail com>]

Hi,

I'm not sure I understand fully - sorry.  At the moment, my program would 
have the following structure (nb. this is not C, just pseudo code):

window_function {
        draw widgets in window
        link callback functions to widgets
        link dialog callback to the closing of the window
}

dialog_cb {
        draw buttons and text
        link callback to ok button
        link callback to cancel button
}

ok_cb {
	<<here is where my problem occurs.  I cannot return an appropriate signal 
to dialog_cb so that it can return a signal to the window_function so that 
the window_function will know whether to close or not.>>
}


I know I must be approaching this the wrong way.  If you can explain the 
basic structure I should be using, or point me in the direction of a good 
code example, I would be most thankful!

For instance, do I need to start passing pointers to widgets as arguments to 
functions?  Or is there a simpler, cleaner way?  I am quite happy with using 
callbacks, but there are obviously some situations when my understanding of 
the program structure needed is breaking down a little :o)

Best regards,

Chris.

> 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
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.