Re: Hello there
- From: "Eric M. Monsler" <emonsler beamreachnetworks com>
- To: gtk-list gnome org
- Subject: Re: Hello there
- Date: Mon, 06 Aug 2001 14:07:02 -0700
Michael wrote:
>
(snip)
> Any tips ?
I suggest that there is a a somewhat different way of thinking about
program flow vs. user interaction that will greatly aid you in
structuring your code. I know that I was frustrated by lots of similar
questions to yours, until I made the mental adjustment. I'll try to
explain the difference and save you (and hopefully others) the
frustration.
In a traditionally structured program driven from the commandline, one
might see:
* Program is running
* Program is ready to save data
* Program puts up prompt and waits for input.
* Program parses input and gets filename
* Program opens file
* Program thereafter puts data into file.
In that structure, the problem you describe in which the filename need
to be returned from the dialog is indeed a problem, for getting the
information back to the 'main processing path'.
Instead, abandon doing those things from straightline processing. In my
application, updating displays based on received UDP packets, I have:
in function save_data_button():
* Open save data file selection dialog
in function save_data_file_cancled():
* Close save data dialog
in function save_data_file_selected():
* Open file
* Mark in state structure that file is opened,
* If appropriate, write current data
* Close save data dialog
in function new_data_from_udp():
* Update display with new data
* If file open, also write new data to file
The beauty of this is that once the file selection dialog is up, the
normal data updating continues while the operater waffles about where to
put it, etc. Essentially all of my dialogs, etc., get passed the state
structure of the display, so they all have access to do whatever is
required.
One refinement you would probably want would be to handle the case where
the dialog is up, but got hidden, and the operator clicks "Save Data"
again. The simple way is to set the "Save Data" insensitive when the
file selection is opened, and set it sensitive again when the dialog is
closed. Or, change it to "Stop saving". I actually just call mine
"Log" on the menu, insensitive when a dialog is up, and depending on
whether I'm currently saving the operator gets either a file selection
or a close confirmation dialog box. Really slick would be to just have
a re-selection raise whichever dialog is present, but I don't feel like
redoing it.
If you were crunching data in your app and needed to save it, you could
obviously have the save data button also stop the data processing, and
then the cancel or selected functions could restart the data processing.
HTH,
Eric Monsler
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]