Re: Widget convulsions. [message #4550] |
Fri, 09 June 1995 00:00 |
patterso
Messages: 36 Registered: February 1995
|
Member |
|
|
William Thompson (thompson@orpheus.nascom.nasa.gov) wrote:
: I've also run into this behavior and complained to RSI about it. It appears to
: have been introduced with IDL v3.6. My workaround was simply to not call
: WIDGET_CONTROL so often, i.e. update the widget less frequently. It also
: appeared that updating label widgets was faster than updating text widgets, but
: maybe that's not always the case.
: The problem appears to persist in IDL 4.0.
: Bill Thompson
I have this problem using button menu widgets - and it's not so easy to avoid
updating these as it's under User control. It does make the applications look
very unprofessional though. I hope RSI will do something about it. It's very
nice having all these extra stats libraries and whatever, but they should get
the basic program working properly first!
Tim
|
|
|
Re: Widget convulsions. [message #4552 is a reply to message #4550] |
Fri, 09 June 1995 00:00  |
thompson
Messages: 584 Registered: August 1991
|
Senior Member |
|
|
ph2tjh@sunc.sheffield.ac.uk (Tim Hammond) writes:
> Hello,
> I'm currently working on a project which involves the creation of
> a lot of compound widgets which act as the graphical interface to
> a large suite of FORTRAN routines. I'm finding the widgets in IDL
> very easy to handle and have produced what I think are good
> results, but I do have one problem which I wonder if anyone else
> has encountered (and perhaps knows a solution to?).
> I find that when the value of a widget is updated using the
> widget_control...set_value=... type construction the whole
> compound widget seems to go through a convulsion as the
> widget disappears and then reappears with its new value. This is
> particularly noticeable when the compound widget is destroyed
> and in some cases the effect can last for quite a while before
> the widget disappears. The actual running of the program is
> not affected in any way, but it makes the finished interface
> look a lot less professional.
> Is there perhaps a way of avoiding this that I haven't yet come
> across?
> Technical note: I am running IDL 3.6.1(c) on a DEC alpha (the problem
> did not seem to be there for IDL 3.5.0 - perhaps because it ran
> faster?).
> Many thanks,
> Tim Hammond.
> ------------
> hammond@solg2.bnsc.rl.ac.uk
I've also run into this behavior and complained to RSI about it. It appears to
have been introduced with IDL v3.6. My workaround was simply to not call
WIDGET_CONTROL so often, i.e. update the widget less frequently. It also
appeared that updating label widgets was faster than updating text widgets, but
maybe that's not always the case.
The problem appears to persist in IDL 4.0.
Bill Thompson
|
|
|
Re: Widget convulsions. [message #4563 is a reply to message #4550] |
Thu, 08 June 1995 00:00  |
kotsines
Messages: 4 Registered: June 1995
|
Junior Member |
|
|
In article <3r6d1p$kn0@hippo.shef.ac.uk>,
Tim Hammond <ph2tjh@sunc.sheffield.ac.uk> wrote:
>
> Hello,
>
> I find that when the value of a widget is updated using the
> widget_control...set_value=... type construction the whole
> compound widget seems to go through a convulsion as the
> widget disappears and then reappears with its new value. This is
> particularly noticeable when the compound widget is destroyed
> and in some cases the effect can last for quite a while before
> the widget disappears. The actual running of the program is
> not affected in any way, but it makes the finished interface
> look a lot less professional.
> Is there perhaps a way of avoiding this that I haven't yet come
> across?
>
I do not have a solution to your problem, but have noticed something
quite similar that only started happening after we upgraded ver 4.0.
If I've got an already realized base and wish to add or delete
butons from it, it is suddenly painfully slow! If I ADD a button,
it will first place the button at the first position it can,
regardless of whether there is already a button there or not. Usually
this means it putting it on top of another one. Then
as if to say ('oops, can't put that here') it moves the button
from the first position to where it belongs - at the end of the
chain of buttons that are already there. In the process, it re-draws
every button in the base. This produces a scrolling-
type effect that is quite annoying when I want to add say 10 buttons
at once, and it takes 5 seconds for it to do so. I would classify this
as 'widget convulsions' too!
Anyone have ideas?
-tk
|
|
|