| Re: xmanager, /managed [message #44002] |
Thu, 12 May 2005 09:05 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Benjamin Hornberger writes:
> Now I can confirm this behaviour on IDL 6.1.1 on Windows. But you have
> to mention that you store the original !d.window at the beginning of
> your widget definition procedure and restore it after the
> "widget_control, /managed" call. Maybe you should link to xcolors.pro as
> example code.
>
> It seems to work in my program as well now, even though I don't really
> understand it. If I store my original !d.window and reset it at the end
> of my widget definition procedure, and do the same in each event handler
> which plots something, I would logically expect that it works as
> described even without the "widget_control, /managed". But it doesn't.
Humm. Not another problem I don't know what I'm talking about!
Not two days in a row, surely! Oh, dear Lord. :-(
You are right, I was keeping track of !D.Window in XColors,
something I don't ordinarily do. And clearly MANAGED does
*something* here, but what!?
I'm thinking now that its use is more limited that I thought.
(I think I was fooled by using XCOLORS as my test program. I
should have used something simpler.) I think it probably prevents
your widget window from becoming the "active" window when a window
gets closed and !D.Window has to go looking for another "active"
window. As such, it is useful, just not as useful as I thought
it was.
> Well, if you follow the "every man for himself" motto, what are we
> talking about then anyway?
I don't know. I really don't know. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: xmanager, /managed [message #44003 is a reply to message #44002] |
Thu, 12 May 2005 07:57  |
Benjamin Hornberger
Messages: 258
Registered: March 2004
|
Senior Member |
|
|
David Fanning wrote:
> Benjamin Hornberger writes:
>
>
>> I am trying this out, but I can't get it to work. I tried that line of
>> code right before and right after the XMANAGER call, and right after the
>> TLB was created. None of them worked.
>
>
> Humm. I wonder if this is a Windows thing?
>
> The code I use to test this with is XCOLORS:
>
> http://www.dfanning.com/programs/xcolors.pro
>
> The "managed" line is line 1104. Comment it out.
> Then make sure there are no open windows in your IDL
> session. Run XCOLORS. While it is on the display, type
> this:
>
> Plot, findgen(11)
>
> The plot should show up in the XColors colorbar window.
>
> Exit XColors and uncomment the managed line. Compile and run
> it again, as before. This time the PLOT command should open
> its own plot window.
>
Now I can confirm this behaviour on IDL 6.1.1 on Windows. But you have
to mention that you store the original !d.window at the beginning of
your widget definition procedure and restore it after the
"widget_control, /managed" call. Maybe you should link to xcolors.pro as
example code.
It seems to work in my program as well now, even though I don't really
understand it. If I store my original !d.window and reset it at the end
of my widget definition procedure, and do the same in each event handler
which plots something, I would logically expect that it works as
described even without the "widget_control, /managed". But it doesn't.
>
>> Also, does it mean when I finally want to plot something in my draw
>> widget, I first have to save the content of !d.window, WSET to the draw
>> widget, plot my stuff and then WSET back to the original value?
>
>
> Well, I figure anyone who wants to draw into a window *always*
> knows where they are drawing, so I don't ordinarily WSET back
> to the original. Every man for himself, is my motto. But in a
> widget program you must ALWAYS do a WSET to the window you
> expect to draw into, yes.
>
Well, if you follow the "every man for himself" motto, what are we
talking about then anyway? You wouldn't need the whole thing at all. I
agree that every widget program should take care of itself, but if you
work on the command line while a non-blocking widget program is open,
it's kind of annoying if the widget program messes up the system
variables, color table etc. all the time (I am following your advice to
restore the display each time the widget program gets the keyboard
focus). That's why I found your article very useful, and I'm thinking of
a strategy to do the same with color vectors.
Cheers,
Benjamin
|
|
|
|
| Re: xmanager, /managed [message #44008 is a reply to message #44003] |
Thu, 12 May 2005 06:42 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Benjamin Hornberger writes:
> I am trying this out, but I can't get it to work. I tried that line of
> code right before and right after the XMANAGER call, and right after the
> TLB was created. None of them worked.
Humm. I wonder if this is a Windows thing?
The code I use to test this with is XCOLORS:
http://www.dfanning.com/programs/xcolors.pro
The "managed" line is line 1104. Comment it out.
Then make sure there are no open windows in your IDL
session. Run XCOLORS. While it is on the display, type
this:
Plot, findgen(11)
The plot should show up in the XColors colorbar window.
Exit XColors and uncomment the managed line. Compile and run
it again, as before. This time the PLOT command should open
its own plot window.
> Also, does it mean when I finally want to plot something in my draw
> widget, I first have to save the content of !d.window, WSET to the draw
> widget, plot my stuff and then WSET back to the original value?
Well, I figure anyone who wants to draw into a window *always*
knows where they are drawing, so I don't ordinarily WSET back
to the original. Every man for himself, is my motto. But in a
widget program you must ALWAYS do a WSET to the window you
expect to draw into, yes.
Cheers,
David
P.S. Let me know if this is a Windows thing and I'll modify the
article.
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: xmanager, /managed [message #44009 is a reply to message #44008] |
Thu, 12 May 2005 06:26 |
Benjamin Hornberger
Messages: 258
Registered: March 2004
|
Senior Member |
|
|
David Fanning wrote:
> Benjamin Hornberger writes:
>
>
>> I found a new tip on David's website, which sounded great to me:
>>
>> http://www.dfanning.com/widget_tips/managed.html
>>
>> However, if I do
>>
>> xmanager, ..., /managed
>>
>> I get an error "Keyword MANAGED not allowed in call to: XMANAGER".
>>
>
> Whoops! I much have been thinking and eating breakfast at the same
> time. :-(
>
> That should be WIDGET_CONTROL, not XMANAGER:
>
> Widget_Control, tlb, /Managed
>
I am trying this out, but I can't get it to work. I tried that line of
code right before and right after the XMANAGER call, and right after the
TLB was created. None of them worked.
Also, does it mean when I finally want to plot something in my draw
widget, I first have to save the content of !d.window, WSET to the draw
widget, plot my stuff and then WSET back to the original value?
Thanks for any help,
Benjamin
|
|
|
|
| Re: xmanager, /managed [message #44016 is a reply to message #44009] |
Wed, 11 May 2005 16:35 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Benjamin Hornberger writes:
> I found a new tip on David's website, which sounded great to me:
>
> http://www.dfanning.com/widget_tips/managed.html
>
> However, if I do
>
> xmanager, ..., /managed
>
> I get an error "Keyword MANAGED not allowed in call to: XMANAGER".
>
> This is IDL 6.1.1 on Windows.
>
> I checked the source code of xmanager.pro, and couldn't find any trace
> of that keyword having ever existed. Any clues? Any other way to prevent
> a draw widget from becoming the current graphics window?
Whoops! I much have been thinking and eating breakfast at the same
time. :-(
That should be WIDGET_CONTROL, not XMANAGER:
Widget_Control, tlb, /Managed
I've fixed the article.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
