| Re: IDL command line access from inside a widget? [message #82722] |
Fri, 11 January 2013 19:02  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Matthew Argall writes:
> What I would do is create an object for your data and write a function to return the object reference. Then, generates your gui and give your object reference as an input.
>
> When you run your function from the command line, the object reference will be returned to the main level and you will be able to access the properties of your object as well as interact with your GUI.
>
> Sort of complicated to explain, but I have done it and it is not that bad...
This is not a bad idea, since you at least have some kind of control
over what the user can do with the data through the object interface.
Giving the user carte blanche, even if it were possible (it's not), is a
recipe for complete and utter disaster. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
|
|
|
|
| Re: IDL command line access from inside a widget? [message #82825 is a reply to message #82724] |
Tue, 15 January 2013 14:28  |
Russell Ryan
Messages: 122
Registered: May 2012
|
Senior Member |
|
|
I agree with Matthew here. I've written a few GUIs as objects so that I can do this. For example, I have a GUI which models some images of distant galaxies. One operation that the GUI can do is adjust the contrast of the image using the mouse. But, I've written it such that you can issue a command at the IDL prompt which will set the contrast "manually". Ok, this isn't a particularly good usage of that, but there are other examples within in my code.
If this is sorta like what you want, it's not too hard to implement. But I have it as a procedure (instead of a function like Matthew suggested) and store the object reference as a system variable. So, the "main" code is a ssimple procedure which first checks if the system variable is set, if not then it initializes the GUI and sets the variable. If it is set *AND* the GUI exists (based on what xregistered returns) then it will grab the reference there and issue whatever command you issue --- the commands are issued by keyword settings. When the GUI is killed, I unset the system variable.
Good luck,
Russell
On Friday, January 11, 2013 9:24:11 PM UTC-5, Matthew Argall wrote:
>> If I want to allow the user access to the command line so they can use the rest of IDL to explore the data, what is the best possible way?
>
>>
>
>> I've set NO_BLOCK on the XMANAGER but that puts me back at the MAIN without access to the variables I've loaded inside my procedure.
>
>>
>
>> Is there a way to get back to the command line and have access to the variables I've already loaded?
>
>
>
> What I would do is create an object for your data and write a function to return the object reference. Then, generates your gui and give your object reference as an input.
>
>
>
> When you run your function from the command line, the object reference will be returned to the main level and you will be able to access the properties of your object as well as interact with your GUI.
>
>
>
> Sort of complicated to explain, but I have done it and it is not that bad...
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
