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

Home » Public Forums » archive » Re: Getting too many resize events
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: Getting too many resize events [message #6770] Wed, 14 August 1996 00:00
Peter Mason is currently offline  Peter Mason
Messages: 145
Registered: June 1996
Senior Member
> . Under WinNT, resizing with WIDGET_CONTROL,wid,SCR_XSIZ=new_x,SCR_YSIZ=new_y
> causes the panel to creep up to the new size, generating resize events all
> the way until get gets to the proper size. Naturally, if I follow the
> resizing statement with a WIDGET_CONTROL,tlb,/CLEAR_EVENTS, the resizing
> process gets stopped short after the first bit. I've found no way around
> this.

A more astute IDL user has given me the simple solution to this one - it was
due to my having "Full Drag" enabled in Control Panel -> Desktop. Once
I disabled this, dynamic resizing worked fine.


Peter Mason
Re: Getting too many resize events [message #6797 is a reply to message #6770] Mon, 12 August 1996 00:00 Go to previous message
Peter Mason is currently offline  Peter Mason
Messages: 145
Registered: June 1996
Senior Member
On Fri, 9 Aug 1996 maurice.ringer@.MISSING-HOST-NAME. wrote:
> I can capture widget re-size events using the TLB_SIZE_EVENTS
> keyword with WIDGET_BASE. However, after you resize the
> widget, IDL seems to generate these resize events again
> whenever the widget is moved or exposed as well as resized.
> Why is this and how can I stop it?
>
> I am running IDL 4.0.1 on VMS from an xterm.

I don't use IDL under VMS, but I've experienced similar problems under DEC
ALPHA/OSF and WinNT. It seems that this functionality (resizing) is a
little inconsistent across platforms, to put it discretely.

I usually enable resizing for panels which contain draw widgets, and whose
size is determined largely (or entirely) by these draw widgets. (Naturally,
the point of enabling resizing here is to allow the user to change the draw-
window size.)
In general, I've found that the safest way to implement resizing is to destroy
the panel and rebuild it for the new draw-widget size. This is the method
I'd recommend if you want some consistency across platforms (i.e., even if
you manage to get dynamic resizing to work correctly on your platform).
But note that you might have to follow with a WIDGET_CONTROL,tlb,/CLEAR_EVENTS
after rebuilding the tlb, in order to prevent spurious resizing events (on
some platforms).

FYI, here's what happens if I attempt dynamic resizing under OSF or NT:
. Under OSF, I've noticed that if I use WIDGET_CONTROL,wid,SCR_XSIZ=new_x,
SCR_YSIZ=new_y, and follow it with a call like WIDGET_CONTROL,tlb,ICONIFY=0,
IDL sometimes goes into a near-endless resizing loop which not even
WIDGET_CONTROL,tlb,/CLEAR_EVENTS can prevent. Also, I sometimes crash all
the way out of my Unix session if I use both SCR_XSIZ=new_x,SCR_YSIZ=new_y
in the same WIDGET_CONTROL. (But I'm using an older version of OSF.)
Otherwise OSF works ok.
. Under WinNT, resizing with WIDGET_CONTROL,wid,SCR_XSIZ=new_x,SCR_YSIZ=new_y
causes the panel to creep up to the new size, generating resize events all
the way until get gets to the proper size. Naturally, if I follow the
resizing statement with a WIDGET_CONTROL,tlb,/CLEAR_EVENTS, the resizing
process gets stopped short after the first bit. I've found no way around
this.
. Resizing a plot window exactly - i.e. taking all margins, padding and
spacing into account - doesn't appear to improve things. (Besides,
WIDGET_INFO(wid,/GEOMETRY) is flaky under MS Windows - it appears to be
unaware of changes in size/position after a tlb has been realized.)


Peter Mason
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: crossspectra
Next Topic: Re: draw lines with XOR operation to background

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

Current Time: Wed Oct 08 13:53:22 PDT 2025

Total time taken to generate the page: 0.00473 seconds