Date: Tue, 24 Feb 1998 13:00:11 -0600
From: escargo@anubis.network.com (David S. Cargo)
Message-Id: <199802241900.NAA05179@brutus.network.com>
To: calvin-ui98@dagobah.stwing.upenn.edu
Subject: Re: final code release
Really this is more for Corey than anybody else.
Corey, one flexible way to interface your save/save as code would
be to have the commands associated with the menu call one proc with
the following arguments: either "save" or "saveas", the name of the
global variable holding the path of the file that we read, if there is
one (if there isn't we should diable the save option), and the name
of the global variable that holds the list of global variables whose
values we want to save.
This last thing is a useful trick that allows flexibility between
your code and the rest of the system. In the initialization procs,
each subsystem that wants its global variables saved just does a
lappend to the global variable.
When you get called, you do something like this (assuming that the
parameters are named mode, outputfile, varlist
global $outputfile
global $varlist ;# this makes whatever the actual parameter is global
if { $mode == "saveas} {
set path [tk_openSave...];# you get the idea.
} else {
set path [set $outputfile]
}
set handle [open $path];# you get the idea
foreach gvar [set $varlist] {
global $gvar
set gval [dump var $gvar]
puts $handle "global $gvar"
puts $handle $gval
}
That pretty much does what we want. I'd put in a bit more stuff to
stamp the output file with an initial special string that we can use
to test to see if it's a recognized file before we source it.
If we do it this way, whenever I change the name of a global variable,
or add a global I want output, your interface doesn't change.
dsc