comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Home » Public Forums » archive » Re: IDLgrLegend broken
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend  		Return to the default flat view Create a new topic Submit Reply
Re: IDLgrLegend broken [message #22848 is a reply to message #22845] Wed, 06 December 2000 13:33 Go to previous messageGo to previous message
Mark Hadfield is currently offline  Mark Hadfield
Messages: 783
Registered: May 1995
Senior Member
Pavel wrote:
> I found out that if an instance of IDLgrLegend object is saved to a .sav
> file and then restored, the IDLgrLegend class definition is not restored
> correctly (unless IDLgrLegend is already instanced in the current IDL
> session). Moreover, attempts to use IDLgrLegend in the same IDL session
> fail if an instance of IDLgrLegend was first restored in that session.

It's a fundamental problem of IDL objects, deriving from the way methods are
resolved. It occurs because IDLgrLegend has a superclass (IDLgrModel). When
IDL first tries to call a method (e.g. SomeMethod) of a restored IDLgrLegend
object it doesn't know that this is available as a method of the IDLgrLegend
class (IDLgrLegend::SomeMethod) so it searches for and finds the
superclass's method (IDLgrModel::SomeMethod). Thereafter, until IDL is
restarted or reset, it flatly refuses to be told that there is an
IDLgrLegend::SomeMethod which is supposed to override the superclass's
method, no matter how many times you compile the new method.

The simplest workaround is to call IDLgrLegend__Define *before* restoring
your IDLgrLegend object (that is, of course, if you know you are about to
restore one). This causes IDL to compile the file idlgrlegend__define.pro
and, on the way, to compile all the methods for IDLgrLegend that are
included in this file.

This problem is related to another one that was discussed in a thread called
"Important object lesson" in June 1998: IDL's refusal to recognise a new
method for an object that has already been instantiated without it.

Here is my understanding of how it works:

If IDL encounters

MyClass->MyMethod

the three situations are:

1. IDL finds a MyClass::MyMethod in memory and uses it. (In the normal
course of events the method will have been included in the
myclass__define.pro, before the myclass__define procedure, so it will
have been compiled the first time an instance of the class was created.)

2. Not finding MyClass::MyMethod, IDL searches up the inheritance tree
in a way described somewhere in the IDL documentation, finds
ASuperClass::MyMethod in memory and uses it for the remainder of the
session.

3. Failing 1 & 2, IDL searches the !path for myclass__mymethod.pro (and
maybe then for similar files for all superclasses). This can take a long
time.

Two relevant points are:

1. IDL searches--all the way up the inheritance tree--in memory before
searching on the disk. (For performance reasons, obviously.)

2. Once a method binding has been established--i.e. a rule like "if
method MyMethod is called on a object of class MyClass, call the
superclass's method, ASuperClass::MyMethod--then this is never
revised. (I think this is also done for performance reasons.)

I hope that explains it. I find that I can understand it just long enough to
write
it down!

---
Mark Hadfield
m.hadfield@niwa.cri.nz http://katipo.niwa.cri.nz/~hadfield/
National Institute for Water and Atmospheric Research
PO Box 14-901, Wellington, New Zealand

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Re: postscript file sizes
Next Topic: GAUSS2DFIT - TILT ?

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Dec 03 20:24:56 PST 2025

Total time taken to generate the page: 1.36488 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.7.
Copyright ©2001-2013 FUDforum Bulletin Board Software