insensitive WIDGET_DROPLIST causes major freeze [message #34865] |
Tue, 22 April 2003 17:09  |
MKatz843
Messages: 98 Registered: March 2002
|
Member |
|
|
I just alerted RSInc about this, but I thought I'd share it with the
list.
I found a multi-platform widget_droplist bug. I know droplist has been
depricated in favor of the combobox, but I'm still using droplist in
some places. So far this bug has caused problems on Red Hat Linux
(7.1?) and Mac OS X 10.2.5 running X11 beta 3.
Here's the bug.
Create a widget_droplist with a command like this.
st = ['A','B','C','D']
filterID = widget_droplist(row1, VALUE=st, UVALUE='dont_bug_me')
This is important: the widget_base that contains row1 is created with
SENSITIVE=0 to begin with.
Now, in response to a separate event, the base is made SENSITIVE with
a widget_control command to the base.
I click on the droplist, and it pops up with all of the options
grayed-out. The mouse cursor turns to a up-and-to-the-right-facing
arrow, and the entire X session locks up except for mouse motion.
On Linux the whole session is completely frozen, all windows are
unresponsive. I had to log-in remotely to kill IDL.
On Mac OS X 10.2.5, the same thing happens, all of X was frozen with
the droplist openand the right-facing arrow showing. But since X11
runs as an application, I just opened a terminal window and killed the
job from the command line; the rest of the OS kept humming along (mp3s
didn't skip a beat :P )
Anyone else see this kind of behavior?
|
|
|
Re: insensitive WIDGET_DROPLIST causes major freeze [message #34878 is a reply to message #34865] |
Mon, 28 April 2003 15:36  |
R.Bauer
Messages: 1424 Registered: November 1998
|
Senior Member |
|
|
Dear M. (what does M. stand for)
I have tried it but it works.
Here is my example. where is it different to yours.
PRO test_event,ev
cmd=WIDGET_INFO(ev.id,/uname)
CASE cmd[0] OF
'SWITCH': $
WIDGET_CONTROL,WIDGET_INFO(ev.top,find_by_uname='ROW1'),/sen sitive
'QUIT':WIDGET_CONTROL,ev.top,/destroy
ELSE:
ENDCASE
END
PRO test
tlb=WIDGET_BASE(col=3)
row1=WIDGET_BASE(tlb,sensitive=0,uname='ROW1')
st = ['A','B','C','D']
filterID = WIDGET_DROPLIST(row1, VALUE=st, UVALUE='dont_bug_me')
button=WIDGET_BUTTON(tlb,value='SWITCH',uname='SWITCH')
quit=WIDGET_BUTTON(tlb,value='QUIT',uname='QUIT')
WIDGET_CONTROL,/realize,tlb
XMANAGER,'test',tlb
END
I have tested on suSE 8.2 (KDE3.1 and the newest X-Server)
help,!version,/str
** Structure !VERSION, 8 tags, length=76, data length=76:
ARCH STRING 'x86'
OS STRING 'linux'
OS_FAMILY STRING 'unix'
OS_NAME STRING 'linux'
RELEASE STRING '5.6'
BUILD_DATE STRING 'Oct 26 2002'
MEMORY_BITS INT 32
FILE_OFFSET_BITS
INT 64
regards
Reimar
M. Katz wrote:
> I just alerted RSInc about this, but I thought I'd share it with the
> list.
>
> I found a multi-platform widget_droplist bug. I know droplist has been
> depricated in favor of the combobox, but I'm still using droplist in
> some places. So far this bug has caused problems on Red Hat Linux
> (7.1?) and Mac OS X 10.2.5 running X11 beta 3.
>
> Here's the bug.
>
> Create a widget_droplist with a command like this.
>
> st = ['A','B','C','D']
> filterID = widget_droplist(row1, VALUE=st, UVALUE='dont_bug_me')
>
> This is important: the widget_base that contains row1 is created with
> SENSITIVE=0 to begin with.
>
> Now, in response to a separate event, the base is made SENSITIVE with
> a widget_control command to the base.
>
> I click on the droplist, and it pops up with all of the options
> grayed-out. The mouse cursor turns to a up-and-to-the-right-facing
> arrow, and the entire X session locks up except for mouse motion.
>
> On Linux the whole session is completely frozen, all windows are
> unresponsive. I had to log-in remotely to kill IDL.
>
> On Mac OS X 10.2.5, the same thing happens, all of X was frozen with
> the droplist openand the right-facing arrow showing. But since X11
> runs as an application, I just opened a terminal window and killed the
> job from the command line; the rest of the OS kept humming along (mp3s
> didn't skip a beat :P )
>
> Anyone else see this kind of behavior?
--
Forschungszentrum Juelich
email: R.Bauer@fz-juelich.de
http://www.fz-juelich.de/icg/icg-i/
============================================================ ======
a IDL library at ForschungsZentrum Juelich
http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro. html
|
|
|
|
Re: insensitive WIDGET_DROPLIST causes major freeze [message #34889 is a reply to message #34865] |
Mon, 28 April 2003 09:32  |
MKatz843
Messages: 98 Registered: March 2002
|
Member |
|
|
> Did you receive a response from RSInc. or find a way to avoid the problem ?
>
> Tobias
RSInc couldn't replicate the problem. They made a stripped-down widget
app to perform their test. They missed my instructions a bit and made
the droplist insensitive rather than the base that contains it.
So, I modified their test program to make it more like the one in my
real application. With this minimal widget, I couldn not make it
behave badly. There must be more than just the one factor--more than
just creating the droplist in a base that's insensitive. I'll look
into it more as time allows. If you find the cause, please post.
Thanks,
M. Katz
|
|
|
Re: insensitive WIDGET_DROPLIST causes major freeze [message #34891 is a reply to message #34865] |
Mon, 28 April 2003 08:43  |
David Fanning
Messages: 11724 Registered: August 2001
|
Senior Member |
|
|
JD Smith (jdsmith@as.arizona.edu) writes:
> Then click on the drop-down for the combo-box. The bug only seems related
> to combo-box widgets in modal bases, and probably only for Unix/Motif
> versions of IDL. Has anyone else noticed the disturbing (to me anyway)
> trend that Windows versions seem to be a bit better debugged, especially
> for widget elements, than Unix?
Oh, hooray! I am S-O-O-O tired of being near the
bottom of every important programming/performance
category! :-)
Cheers,
A Windows User
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
Re: insensitive WIDGET_DROPLIST causes major freeze [message #34892 is a reply to message #34865] |
Mon, 28 April 2003 08:27  |
JD Smith
Messages: 850 Registered: December 1999
|
Senior Member |
|
|
On Mon, 28 Apr 2003 02:44:22 -0700, Tobias Umblia wrote:
> MKatz843@onebox.com (M. Katz) wrote in message
> news:<4a097d6a.0304221609.45539db5@posting.google.com>...
>> I just alerted RSInc about this, but I thought I'd share it with the
>> list.
>>
>> I found a multi-platform widget_droplist bug. I know droplist has been
>> depricated in favor of the combobox, but I'm still using droplist in
>> some places. So far this bug has caused problems on Red Hat Linux
>> (7.1?) and Mac OS X 10.2.5 running X11 beta 3.
>>
>> Here's the bug.
>>
>> Create a widget_droplist with a command like this.
>>
>> st = ['A','B','C','D']
>> filterID = widget_droplist(row1, VALUE=st, UVALUE='dont_bug_me')
>>
>> This is important: the widget_base that contains row1 is created with
>> SENSITIVE=0 to begin with.
>>
>> Now, in response to a separate event, the base is made SENSITIVE with a
>> widget_control command to the base.
>>
>> I click on the droplist, and it pops up with all of the options
>> grayed-out. The mouse cursor turns to a up-and-to-the-right-facing
>> arrow, and the entire X session locks up except for mouse motion.
>>
>> On Linux the whole session is completely frozen, all windows are
>> unresponsive. I had to log-in remotely to kill IDL.
>>
>> On Mac OS X 10.2.5, the same thing happens, all of X was frozen with
>> the droplist openand the right-facing arrow showing. But since X11 runs
>> as an application, I just opened a terminal window and killed the job
>> from the command line; the rest of the OS kept humming along (mp3s
>> didn't skip a beat :P )
>>
>> Anyone else see this kind of behavior?
>
>
> Yes, just 2 days after your posting I found exactly the same happening
> in my widget application.I'm using XFree86 4.1 on Debian GNU Linux 3.0
> and HP-UX 11.
> Did you receive a response from RSInc. or find a way to avoid the
> problem ?
>
A similar bug related to WIDGET_COMBOBOX:
b1=widget_base(/COLUMN,xsize=100,ysize=100)
b=widget_base(/COLUMN,/MODAL,GROUP_LEADER=b1)
c=widget_combobox(b,value=strtrim(randomu(sd,50)*1000))
widget_control,b1,/realize
widget_control,b,/realize
Then click on the drop-down for the combo-box. The bug only seems related
to combo-box widgets in modal bases, and probably only for Unix/Motif
versions of IDL. Has anyone else noticed the disturbing (to me anyway)
trend that Windows versions seem to be a bit better debugged, especially
for widget elements, than Unix?
JD
|
|
|
Re: insensitive WIDGET_DROPLIST causes major freeze [message #34897 is a reply to message #34865] |
Mon, 28 April 2003 02:44  |
bias
Messages: 7 Registered: February 2003
|
Junior Member |
|
|
MKatz843@onebox.com (M. Katz) wrote in message news:<4a097d6a.0304221609.45539db5@posting.google.com>...
> I just alerted RSInc about this, but I thought I'd share it with the
> list.
>
> I found a multi-platform widget_droplist bug. I know droplist has been
> depricated in favor of the combobox, but I'm still using droplist in
> some places. So far this bug has caused problems on Red Hat Linux
> (7.1?) and Mac OS X 10.2.5 running X11 beta 3.
>
> Here's the bug.
>
> Create a widget_droplist with a command like this.
>
> st = ['A','B','C','D']
> filterID = widget_droplist(row1, VALUE=st, UVALUE='dont_bug_me')
>
> This is important: the widget_base that contains row1 is created with
> SENSITIVE=0 to begin with.
>
> Now, in response to a separate event, the base is made SENSITIVE with
> a widget_control command to the base.
>
> I click on the droplist, and it pops up with all of the options
> grayed-out. The mouse cursor turns to a up-and-to-the-right-facing
> arrow, and the entire X session locks up except for mouse motion.
>
> On Linux the whole session is completely frozen, all windows are
> unresponsive. I had to log-in remotely to kill IDL.
>
> On Mac OS X 10.2.5, the same thing happens, all of X was frozen with
> the droplist openand the right-facing arrow showing. But since X11
> runs as an application, I just opened a terminal window and killed the
> job from the command line; the rest of the OS kept humming along (mp3s
> didn't skip a beat :P )
>
> Anyone else see this kind of behavior?
Yes, just 2 days after your posting I found exactly the same happening
in my widget application.I'm using XFree86 4.1 on Debian GNU Linux 3.0
and HP-UX 11.
Did you receive a response from RSInc. or find a way to avoid the problem ?
Tobias
|
|
|