comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Help with interactive cursor and the draw widget (long)
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Help with interactive cursor and the draw widget (long) [message #42003] Wed, 15 December 2004 12:00 Go to next message
bgarwood is currently offline  bgarwood
Messages: 2
Registered: December 2004
Junior Member
I have a simple problem I can't seem to figure out how to solve.
Essentially, I want to have the functional equivalent of CURSOR in a
draw widget embedded in a larger widget. Seems simple enough. The
trouble is that everything I've tried so far seems to queue up the
events - including expose events, so that when the widget is fully
exposed it isn't being redrawn in the previously exposed regions -
while my function is waiting and nothing happens.

The documentation I've read says not to use CURSOR with draw widgets.
Okay (and when I do try and use it, it works, except for the nasty
problem of not redrawing the un-exposed parts when they are exposed
before the cursor click is seen). So I've tried do something else -
mostly involving having the widgets existing event handler set a common
block or global value and, in my cursor-replacement function, watch for
that value to change. Only problem, the loop to watch for that value
to change in my function seems to prevent the actual events from
reaching the event handler and so the state never changes.

Sure, I could do it all inside the GUI. My problem is that we have
users who want to be able to also interact with that GUI from commands,
i.e.

start_my_gui
; stuff happens, GUI fires up
cursor, x, y
; do something with x and y after the user clicks on it.

How do I make that work? It works just fine with a simple PLOT window.
Why won't it work with an embedded draw widget?

Thanks.
Bob Garwood
Re: Help with interactive cursor and the draw widget (long) [message #42084 is a reply to message #42003] Wed, 15 December 2004 15:51 Go to previous message
bgarwood is currently offline  bgarwood
Messages: 2
Registered: December 2004
Junior Member
Thanks, but we tried all of that. Our users are an interesting group
in that they want to be able to get in to the code and change it to
suit their needs whenever they want. So, we try and avoid objects
unless forced to - it was our fallback position in this case. It seems
to be an interaction between the event handler for the draw widget
events and the cursor interaction. The other widgets redraw themselves
nicely after an expose in all cases. Its just the draw widget seems to
never get the message.

We may have found the solution. Using widget_event on the specific
draw widget. I haven't actually fully tested that one yet, so this may
be premature (and if someone else has any other suggestions, let me
know).

-Bob
Re: Help with interactive cursor and the draw widget (long) [message #42086 is a reply to message #42003] Wed, 15 December 2004 14:13 Go to previous message
Benjamin Hornberger is currently offline  Benjamin Hornberger
Messages: 258
Registered: March 2004
Senior Member
bgarwood wrote:
> I have a simple problem I can't seem to figure out how to solve.
> Essentially, I want to have the functional equivalent of CURSOR in a
> draw widget embedded in a larger widget. Seems simple enough. The
> trouble is that everything I've tried so far seems to queue up the
> events - including expose events, so that when the widget is fully
> exposed it isn't being redrawn in the previously exposed regions -
> while my function is waiting and nothing happens.
>
> The documentation I've read says not to use CURSOR with draw widgets.
> Okay (and when I do try and use it, it works, except for the nasty
> problem of not redrawing the un-exposed parts when they are exposed
> before the cursor click is seen). So I've tried do something else -
> mostly involving having the widgets existing event handler set a common
> block or global value and, in my cursor-replacement function, watch for
> that value to change. Only problem, the loop to watch for that value
> to change in my function seems to prevent the actual events from
> reaching the event handler and so the state never changes.
>
> Sure, I could do it all inside the GUI. My problem is that we have
> users who want to be able to also interact with that GUI from commands,
> i.e.
>
> start_my_gui
> ; stuff happens, GUI fires up
> cursor, x, y
> ; do something with x and y after the user clicks on it.
>
> How do I make that work? It works just fine with a simple PLOT window.
> Why won't it work with an embedded draw widget?
>
> Thanks.
> Bob Garwood
>

If I understand it right, your problem of unexposed parts of the draw
window is a matter of backing store. Try "retain=2" as a keyword to
widget_draw.

To use mouse clicking in draw widgets, set the "/button_events" keyword
to widget_draw. The draw widget will then create an event whenever you
click into the window. See "Widget Events Returned by Draw Widgets" in
the online help to widget_draw on how to distinguish between different
mouse buttons and button down and up events.

If you want to interact with your GUI from the IDL command line, I would
recommend writing the GUI as an object and then calling object methods
on the GUI from the command line. An alternative might be exporting the
variables from the GUI to the IDL main level with the SCOPE_VARFETCH()
function.

Good luck,
Benjamin
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Re: Compilation error with code from ENVI Help
Next Topic: Re: FILE_DELETE and FILE_CHMOD

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

Current Time: Fri Oct 10 01:16:27 PDT 2025

Total time taken to generate the page: 0.64221 seconds