| Re: Saving an application state [message #39939 is a reply to message #39841] |
Thu, 24 June 2004 18:36  |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
On Mon, 21 Jun 2004 07:49:39 -0700, Rob Dimeo wrote:
> Hi,
>
> We have had a number of requests from our software users to be able to
> save the "state" of the GUI application prior to closing it so that users
> can restore it at a later time. The GUI applications are typically
> written as object widgets that can contain many other objects. The
> relationship with the the GUI and other objects can be has-a and is-a. I
> know that there are certain tricks related to saving objects and restoring
> them (as discussed on this NG) but I don't have that much experience doing
> this myself. I am probably asking too much but....is there a
> straightforward way to modify existing object widgets that allows the user
> to save and restore the widget state?
>
David is right, I do have a preferred method I've written about, and it's
fairly easy. It essentially requires you to hide all the unnecessary
widget info behind a single pointer. I usually use self.wInfo. Accessing
said data is then a bit more tedious ((*self.wInfo).wButton instead of
self.wButton), but it gives you two things:
1. Your object can live and run without a GUI. Good for batch scripts
and command line processing.
2. You can save your object without the unnecessary (and harmful)
transient widget data by simply "detaching" them before saving.
A simplified version of my save method is:
pro myClass::Save,file
detwInfo=self.wInfo ; detach
self.wInfo=ptr_new() ; a null pointer save, self,FILENAME=filename
self.wInfo=detwInfo ; reattach
end
which works nicely, unless you have trouble saving (no permissions, etc.),
in which case some error checking is a good idea:
pro myClass::Save,file
detwInfo=self.wInfo ; detach
self.wInfo=ptr_new() ; a null pointer catch, serr
if serr eq 0 then save,self,FILENAME=file catch,/CANCEL
self.wInfo=detwInfo ; reattach if serr then message,'Error
saving to file: '+file
end
Anyway, this is all you really need. Restoring is pretty simple, but you
have to be a bit careful to make sure your restored object doesn't
overwrite the class definition of a changed class (which in principle
means compile that class before restoring). My RESTORE_OBJECT routine
takes care of that (or you can do it yourself).
Other fun tricks you can do with SAVE/RESTORE on objects include
overwriting the existing "self" pointer in-place... a *very* easy way to
implement "recover from file", which I call "transmogrification".
David is right that SAVE very diligently follows the data structures
thoroughly through all pointers and composited objects, and saves
everything, but if you're careful to detach what you don't want or need,
you'll be in fine shape. There's lots to read on the NG on this topic.
JD
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
