| Re: Concurrent widget program. [message #11905] |
Tue, 02 June 1998 00:00 |
David Foster
Messages: 341
Registered: January 1996
|
Senior Member |
|
|
Andy Loughe wrote:
>
> David Fanning wrote:
>
>> But that is not the case at all. Consider this example.
>> Suppose the event handler code went into a processing loop
>> and that the loop took 5 minutes to execute. Then the user
>> could be pushing as many buttons on as many widget programs
>> as he or she liked, but nothing would be happening. In
>> fact, nothing at all would happen until that loop finished
>> and then, probably, all hell would beak loose as IDL rushed
>> to handle all the events that had queued over the past five
>> minutes.
>
> I am not a widget genius, but isn't that one reason you
> add the hourglass keyword when controlling widgets that
> take "awhile" to process the event?
>
Yes! AFTER you've used NO_BLOCK to get the second widget up
on the screen! As far as I can tell, that is what the gentleman
was asking. I never meant to imply that IDL could process *events*
concurrently...sorry for the confusion. Are we having a bad day?...
Dave
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
David S. Foster Univ. of California, San Diego
Programmer/Analyst Brain Image Analysis Laboratory
foster@bial1.ucsd.edu Department of Psychiatry
(619) 622-5892 8950 Via La Jolla Drive, Suite 2240
La Jolla, CA 92037
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
|
|
|
|
| Re: Concurrent widget program. [message #11912 is a reply to message #11905] |
Tue, 02 June 1998 00:00  |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Andy Loughe (afl@cdc.noaa.gov) writes in response to one
of my articles about trying not to put loops in widget
event handlers:
> I am not a widget genius, but isn't that one reason you
> add the hourglass keyword when controlling widgets that
> take "awhile" to process the event?
Absolutely. I try very, very hard to NOT write event handlers
that take a long time to process, but occasionally it is
unavoidable. In that case, you can be sure I turn the
hourglass cursor on before I enter the loop.
But I am also (knowing what I know about users) careful to
use the CLEAR_EVENTS keyword to WIDGET_CONTROL when I come
*out* of that loop! :-)
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/
|
|
|
|
| Re: Concurrent widget program. [message #11913 is a reply to message #11905] |
Tue, 02 June 1998 00:00 |
Andy Loughe
Messages: 174
Registered: November 1995
|
Senior Member |
|
|
David Fanning wrote:
> But that is not the case at all. Consider this example.
> Suppose the event handler code went into a processing loop
> and that the loop took 5 minutes to execute. Then the user
> could be pushing as many buttons on as many widget programs
> as he or she liked, but nothing would be happening. In
> fact, nothing at all would happen until that loop finished
> and then, probably, all hell would beak loose as IDL rushed
> to handle all the events that had queued over the past five
> minutes.
>
> IDL does only one "thing" at a time. It is not a multi-threaded
> or multi-tasking program. This is exactly why you try to
> avoid writing loops in event handler code. In fact, when you
> need a loop, you try to take advantage of the widget program
> itself *acting* like a loop. A widget animation is a perfect
> example of this. If a widget animation was really in a loop,
> there would be no way to interrupt the animation with, for
> example, a Quit button. You can look at the example XMOVIE on
> my web page for an example of how to use the program itself
> to simulate a loop. You will see that each "event" actually
> displays just a single frame of the animation sequence.
> Between one event and the next a Quit button event, for
> example, could be queued up and processed.
I am not a widget genius, but isn't that one reason you
add the hourglass keyword when controlling widgets that
take "awhile" to process the event?
--
Andrew F. Loughe |
afl@cdc.noaa.gov
University of Colorado, CIRES Box 449 |
http://cdc.noaa.gov/~afl
Boulder, CO 80309-0449 | phn:(303)492-0707
fax:(303)497-7013
------------------------------------------------------------ ---------------
"I do not feel obliged to believe that the same God who has endowed us
with
sense, reason, and intellect has intended us to forego their use."
-Galileo
|
|
|
|
| Re: Concurrent widget program. [message #11915 is a reply to message #11905] |
Mon, 01 June 1998 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
David Foster (foster@bial1.ucsd.edu) replies to Imanol Echave
by writing:
> Imanol Echave wrote:
>>
>> I've a little question: Is it possible to run two IDL programs concurrently? My
>> problem is that I run a time expensive IDL program into a widget program, and
>> I'd like to continue managing widgets while the other program is processing. Any
>> advice?
>
> If you have IDL 5.0+ then you can use the /NO_BLOCK keyword in
> your call to XMANAGER; this prevents IDL from "blocking" (where
> processing stops at the XMANAGER call) until the widget is destroyed.
>
> Your command line will reappear after starting this program, and
> new programs may be started and their events will be handled properly.
> This was one of the best features of IDL 5.0, IMHO.
>
> Look up NO_BLOCK keyword under XMANAGER in the Online Help.
I think there is some confusion here over asynchronous event
processing, which widget programs certainly allow, and
multi-tasking, which IDL doesn't do.
You can certainly have as many widget programs as you like
all running concurrently. IDL doesn't care which widget
program generates an event. As events are generated IDL puts
them into a queue to handle one after the other. If the code
for each event (i.e., the event handler code) is fast, then it
would appear that widget programs are running "concurrently".
But that is not the case at all. Consider this example.
Suppose the event handler code went into a processing loop
and that the loop took 5 minutes to execute. Then the user
could be pushing as many buttons on as many widget programs
as he or she liked, but nothing would be happening. In
fact, nothing at all would happen until that loop finished
and then, probably, all hell would beak loose as IDL rushed
to handle all the events that had queued over the past five
minutes.
IDL does only one "thing" at a time. It is not a multi-threaded
or multi-tasking program. This is exactly why you try to
avoid writing loops in event handler code. In fact, when you
need a loop, you try to take advantage of the widget program
itself *acting* like a loop. A widget animation is a perfect
example of this. If a widget animation was really in a loop,
there would be no way to interrupt the animation with, for
example, a Quit button. You can look at the example XMOVIE on
my web page for an example of how to use the program itself
to simulate a loop. You will see that each "event" actually
displays just a single frame of the animation sequence.
Between one event and the next a Quit button event, for
example, could be queued up and processed.
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/
|
|
|
|
| Re: Concurrent widget program. [message #11916 is a reply to message #11915] |
Mon, 01 June 1998 00:00 |
David Foster
Messages: 341
Registered: January 1996
|
Senior Member |
|
|
Imanol Echave wrote:
>
> Hi people:
>
> I've a little question: Is it possible to run two IDL programs concurrently? My
> problem is that I run a time expensive IDL program into a widget program, and
> I'd like to continue managing widgets while the other program is processing. Any
> advice?
If you have IDL 5.0+ then you can use the /NO_BLOCK keyword in
your call to XMANAGER; this prevents IDL from "blocking" (where
processing stops at the XMANAGER call) until the widget is destroyed.
Your command line will reappear after starting this program, and
new programs may be started and their events will be handled properly.
This was one of the best features of IDL 5.0, IMHO.
Look up NO_BLOCK keyword under XMANAGER in the Online Help.
Dave
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
David S. Foster Univ. of California, San Diego
Programmer/Analyst Brain Image Analysis Laboratory
foster@bial1.ucsd.edu Department of Psychiatry
(619) 622-5892 8950 Via La Jolla Drive, Suite 2240
La Jolla, CA 92037
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
