comp.lang.idl-pvwave archive - RDF feed
type: channel
description: Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
items: Re: Global variables and command line

Re: Global variables and command line
type: item
description: David Fanning wrote: > > Daniel SAGE (daniel.sage@epfl.ch) writes: > >> I would like use the variables created in the input command line inside >> the procedures/functions. But in my application where I automatically >> generate IDL code, I can't use the common mechanism or passing by >> parameters. > >> How is it possible to make V2 visible inside the test procedure when I >> can't pass the parameters with the run procedure ? > > Well, at the risk of being too obvious here, I would suggest > putting V2 *in* the common block. :-) > >> IDL> common var, v1 > > to IDL> common var, v1, v2 > > Cheers, > > David > > ----------------------------------------------------------- > David Fanning, Ph.D. > Fanning Software Consulting > E-Mail: davidf@dfanning.com > Phone: 970-221-0438 > Coyote's Guide to IDL Programming: http://www.dfanning.com/ At the risk of being too arcane here, I think Daniel's point is quite a valid one, and his problem less easily solved than it might at first glance seem. Sometimes, one wants to access variables from the $MAIN$ level in a routine, and sometimes one wants to put variables created inside a routine into $MAIN$. You might wonder what circumstance could exist that would require this functionality. I would simply then direct you to RSI's own Insight, in which after getting in you have the option of "Select Data to Import"..."IDL Variables"... with a list of $MAIN$ level variables displayed. Now clearly the folks at RSI have convenient access to the names and data locations of the $MAIN$ level variables, and I think they should give us mere ordinary users that access also. As phrased so judiciously in the Reference Guide under the Help procedure: The OUTPUT keyword is primarily for use in capturing HELP output in order to display it someplace else, such as in a text widget. This keyword is not intended to be used in obtaining programmatic information about the IDL session, and is formatted to be human readable. Research Systems reserves the rig…
creator: J.D. Smith
date: 1998-04-17T07:00:00-00:00

Re: Global variables and command line
type: item
description: Daniel SAGE wrote: > > Hello, > > I would like use the variables created in the input command line inside > the procedures/functions. But in my application where I automatically > generate IDL code, I can't use the common mechanism or passing by > parameters. > > pro run > resolve_routine, "test" > call_procedure, "test" > end > > pro test > common var > print, v1 > print, v2 > end > > IDL> common var, v1 > IDL> v1=111 > IDL> v2=222 > % Compiled module: RUN. > % Compiled module: TEST. > IDL> run > % Procedure was compiled while active: RUN. Returning. > % Compiled module: TEST. > 111 > % PRINT: Variable is undefined: V2. > % Execution halted at: TEST 10 HD:Desktop Folder:test.pro > > % $MAIN$ > > How is it possible to make V2 visible inside the test procedure when I > can't pass the parameters with the run procedure ? > > Thanks > Your problem is that you define your common block only with v1 - and once it is defined, you can't change it!! The above example will work if you type common var,v1,v2 on the command line. However, a better approach would probably be to call EXECUTE (or CALL_PROCEDURE, CALL_FUNCTION) to "execute" your procedure or function that you generate automatically. There should always be some way of parameter passing. Even if you don't know how many variables you will need in advance neither their name, you could still construct a structure and pass that into the function/procedure. I have a CHKSTRU function in my library (html below) which you can use to see if a certain structure tag is defined. Hope this helps, Martin -- ------------------------------------------------------------ ------- Dr. Martin Schultz Department for Earth&Planetary Sciences, Harvard University 186 Pierce Hall, 29 Oxford St., Cambridge, MA-02138, USA phone: (617)-496-8318 fax : (617)-495-4551 e-mail: mgs@io.harvard.edu IDL-homepage: http://www-as.harvard.edu/people/staff/mgs/idl/ ------------------------------------------------------------ -------
creator: Martin Schultz
date: 1998-04-17T07:00:00-00:00

Re: Global variables and command line
type: item
description: Daniel SAGE (daniel.sage@epfl.ch) writes: > I would like use the variables created in the input command line inside > the procedures/functions. But in my application where I automatically > generate IDL code, I can't use the common mechanism or passing by > parameters. > How is it possible to make V2 visible inside the test procedure when I > can't pass the parameters with the run procedure ? Well, at the risk of being too obvious here, I would suggest putting V2 *in* the common block. :-) > IDL> common var, v1 to IDL> common var, v1, v2 Cheers, David ----------------------------------------------------------- David Fanning, Ph.D. Fanning Software Consulting E-Mail: davidf@dfanning.com Phone: 970-221-0438 Coyote's Guide to IDL Programming: http://www.dfanning.com/
creator: davidf
date: 1998-04-17T07:00:00-00:00

Re: Global variables and command line
type: item
description: J.D.Smith wrote: [..snip..] > At the risk of being too arcane here, I think Daniel's point is quite a > valid one, and his problem less easily solved than it might at first > glance seem. Sometimes, one wants to access variables from the $MAIN$ > level in a routine, and sometimes one wants to put variables created > inside a routine into $MAIN$. You might wonder what circumstance could > exist that would require this functionality. I would simply then direct > you to RSI's own Insight, in which after getting in you have the option > of "Select Data to Import"..."IDL Variables"... with a list of $MAIN$ > level variables displayed. Now clearly the folks at RSI have convenient > access to the names and data locations of the $MAIN$ level variables, > and I think they should give us mere ordinary users that access also. [..snip..] > I am henceforth considering submitting an enhancement request for a > function that will provide the names and data locations (e.g. through > pointers) of $MAIN$ level variables inside routines, and the ability to > create $MAIN$ level variables from within routines, in a safe form. [..snip..] > Perhaps RSI is trying to protect us from ourselves here, realizing that > with the problems people have with variable locality already, breaking > it slightly might serve to confuse even more. But they really shouldn't > underestimate our ability to harness and control whatever new power > comes our way. And besides, if they get to do it, then so should we. I agree. In an attempt to nominate myself for the 'IDL Hacker of the year' award :-) I dug into something that I'd seen while programming RPC calls to IDL ... and ended up wasting a days work on this thing that doesn't seem to work, even though I think it *should* work; Below is a set of C routines that need to be compiled and linked into shareable libraries (and remember to include the "libidl" shareable library in the linking... on my alpha that's done by adding e.g., "-L$IDL_DIR/bin/bin.alpha -l…
creator: steinhh
date: 1998-04-21T07:00:00-00:00