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

Home » Public Forums » archive » Re: really dumb widget question
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
Re: really dumb widget question [message #19754] Fri, 14 April 2000 00:00
Mark Fardal is currently offline  Mark Fardal
Messages: 51
Registered: October 1995
Member
davidf@dfanning.com (David Fanning) writes:

>> When IDL is stopped within a procedure, a non-blocking widget will
>> still listen to events. But it won't act on them. Why not? Is there
>> any way to make it act on them?
>
> I presume because STOP means STOP. If it meant MOSTLY STOP,
> I expect RSI would hear about it. :-)
>
> I would try .CONTINUE to get them going again.

Hi,

Well, I did know that much. But as I noted, you have to wait until
returning to the main level. (Or is it just leaving the procedure with
the STOP? Didn't test.) That isn't always what I want.

Say you write two versions of a procedure. One takes user input from
the command line, the other takes it from a non-blocking widget. If
you stop at a certain point and need to use the procedure before going
on, you can use the command-line version. But the GUI version is
useless, unless you rewrite it as a blocking widget.

Non-blocking widgets introduce parallel threads of execution to an
environment that doesn't otherwise use threads. I would naively
expect a STOP to stop the thread it's in, but apparently it stops all
of them--except for the one that _records_ widget events for later
processing. I'm basically wondering if one thread can tell another
thread to go ahead and execute.

Mark
Re: really dumb widget question [message #19763 is a reply to message #19754] Fri, 14 April 2000 00:00 Go to previous message
davidf is currently offline  davidf
Messages: 2866
Registered: September 1996
Senior Member
Mark Fardal (fardal@weka.astro.umass.edu) writes:

> When IDL is stopped within a procedure, a non-blocking widget will
> still listen to events. But it won't act on them. Why not? Is there
> any way to make it act on them?

I presume because STOP means STOP. If it meant MOSTLY STOP,
I expect RSI would hear about it. :-)

I would try .CONTINUE to get them going again.

> I guess my problem is understanding how the widget event loop interacts
> with the command line. Widgetheads, please help.

I'm going to botch this completely, but this is the way
I understand it. (Note, you don't really have to understand
it to write decent programs, thank goodness!) When RSI gave
us widget programs that ran at the same time as the command
line, they had to rewrite the interactive parser to distinguish
between a real command and a "widget command" (for lack of a better
term). Presumably when you STOP the command line interpreter,
you also stop this widget command parser and how it works
(I really have no idea). Wave, wave, ....

Anyhow, .Continue should set you right. :-(

Cheers,

David

--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: object graphics symbols
Next Topic: expose events and window dragging in object graphics

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

Current Time: Wed Oct 08 19:17:13 PDT 2025

Total time taken to generate the page: 0.00667 seconds