| Re: Saved Object Question [message #67621] |
Thu, 20 August 2009 15:26  |
penteado
Messages: 866
Registered: February 2018
|
Senior Member
Administrator |
|
|
On Aug 20, 7:03 pm, David Fanning <n...@dfanning.com> wrote:
> Yeah, I thought of that, too. I decided against
> it because if you have a large path, you would have
> to search the whole damn thing multiple times while
> you were looking for superclasses. I didn't actually
> test it, but it "felt" slow to me.
It feels slow to me, too. Also, not much point in keep testing to
avoid doing things when catch can do both the test and the intended
operation, and thus might look nicer (if made GOTO-less).
Since call_procedure will do the same search that file_which would,
using file_which first would mean search twice in the cases the file
is found. But no disk searches would be done using the help output,
just a quick string array search.
|
|
|
|
|
|
|
|
| Re: Saved Object Question [message #67624 is a reply to message #67623] |
Thu, 20 August 2009 13:52  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
pp writes:
> Maybe I misunderstood the problem, but it seems to me that the names
> of the built-in classes should always be returned by a call to help.
> So instead of searching for __DEFINE in the output of routine_info(),
> Resolve_Obj could instead build a list of class names from the output
> of help:
>
> help,/objects,/full,output=3Dhobjs
> ;pick only the output lines with class names:
> hobjs=3Dhobjs[where(strpos(hobjs,'** Object class') ne -1,nclasses)]
> classes=3Dstrarr(nclasses) ;array for the known class names
> ;extract the class name from the rest of the help information:
> for i=3D0,nclasses-1 do classes[i]=3D(strsplit(hobjs[i],' ,',/extract))[3]
>
> Which when I run in a clean session in IDL 7.1 gives me 63 class
> names.
Parse the HELP command!? Uugghh.
I don't know. I decided to solve it with a silent
error handler and a GOTO statement. Probably a
double uugghh. :-(
Anyway, it works for my purposes at the moment.
I have slightly re-written JD's routine, and added
my own poor judgement, to some new code you can find
here:
http://www.dfanning.com/programs/resolve_object.pro
Cheers,
David
--
David Fanning, Ph.D.
Coyote's Guide to IDL Programming (www.dfanning.com)
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: Saved Object Question [message #67643 is a reply to message #67624] |
Wed, 19 August 2009 20:27 |
penteado
Messages: 866
Registered: February 2018
|
Senior Member
Administrator |
|
|
On Aug 19, 8:00 pm, David Fanning <n...@dfanning.com> wrote:
> I had reason to use this little routine this afternoon,
> and ran into a complication. When one of the object's
> superclasses is a built-in IDL routine (in this case
> IDL_Container), the routine fails, complaining--rightly--
> that it can't find the undefined procedure/function named
> idl_container__define.
>
> The line it is complaining on is, of course, the CALL_PROCEDURE
> line.
Maybe I misunderstood the problem, but it seems to me that the names
of the built-in classes should always be returned by a call to help.
So instead of searching for __DEFINE in the output of routine_info(),
Resolve_Obj could instead build a list of class names from the output
of help:
help,/objects,/full,output=hobjs
;pick only the output lines with class names:
hobjs=hobjs[where(strpos(hobjs,'** Object class') ne -1,nclasses)]
classes=strarr(nclasses) ;array for the known class names
;extract the class name from the rest of the help information:
for i=0,nclasses-1 do classes[i]=(strsplit(hobjs[i],' ,',/extract))[3]
Which when I run in a clean session in IDL 7.1 gives me 63 class
names.
|
|
|
|
| Re: Saved Object Question [message #67768 is a reply to message #67621] |
Thu, 20 August 2009 15:57 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
pp writes:
> It feels slow to me, too. Also, not much point in keep testing to
> avoid doing things when catch can do both the test and the intended
> operation, and thus might look nicer (if made GOTO-less).
>
> Since call_procedure will do the same search that file_which would,
> using file_which first would mean search twice in the cases the file
> is found. But no disk searches would be done using the help output,
> just a quick string array search.
Well, I might have to code it up and see which is
faster on a day when I'd rather write IDL code than
play tennis. In the meantime, it works, appears
reasonably fast, and is something ugly I can point
to when my grandchildren (some day!) ask me if I
ever wrote ugly IDL code. ;-)
Cheers,
David
--
David Fanning, Ph.D.
Coyote's Guide to IDL Programming (www.dfanning.com)
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
