[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Objects, File Names, and the Save command.
- Subject: Re: Objects, File Names, and the Save command.
- From: davidf(at)dfanning.com (David Fanning)
- Date: Thu, 23 Jul 1998 08:14:44 -0600
- Newsgroups: comp.lang.idl-pvwave
- Organization: Fanning Software Consulting
- References: <35B64A9A.8E0F3DF4@astrosun.tn.cornell.edu>
- Xref: news.doit.wisc.edu comp.lang.idl-pvwave:11622
J.D. Smith (firstname.lastname@example.org) writes:
> I am exploring a very promising use of the save/restore commands in
> conjuction with objects. Given some complex object which contains a
> host of different types of data (with pointers, etc.), as part of a
> class method, one adds:
> save, self, FILENAME=fname
> to register on disk an accurate snapshot of the object. To restore,
> later, use:
> and the object is in obj, but also brought back as the local variable
> This is all very convenient but leads to the strange situation of a
> loaded object in memory which exists there *before* any of the class
> methods, and/or the __define procedure for that object class are
> compiled. Therefore, the usual paradigm of putting all class methods in
> the __define procedure file before this procedure (suggested by RSI
> itself in the manual) fails. How can the method be found if the
> __define doesn't have to be compiled and isn't in it's own file? I
> would like to come up with a solution which doesn't involve a separate
> class__method.pro file for each method. Any ideas?
How about something like this:
thisClass = Obj_Class(self)
Resolve_Routine, thisClass + '_define'
I haven't tested this, but don't see any reason it wouldn't work.
Resolve_Routine is the way IDL procedures and functions can
be compiled from *within* other procedures and functions.
David Fanning, Ph.D.
Fanning Software Consulting
Coyote's Guide to IDL Programming: http://www.dfanning.com/