| Floating base widget [message #17895] |
Wed, 17 November 1999 00:00  |
Daniel Peduzzi
Messages: 29
Registered: June 1999
|
Junior Member |
|
|
I would like to create a window which can never be obscured by its
group leader, but I can't seem to force the window to remain "on top."
According to the IDL documentation, by setting the "floating" keyword
when creating a top-level base, the "floating base widget will always
appear above the base specified as the group leader."
In the sample code below, the second base is designated as "floating",
but I can easily obscure it with the group leader. I'm running IDL 5.2
on a Sun SPARC.
;=========================================================== ===================
pro done, event
widget_control, event.id, get_uvalue=tlb
widget_control, tlb, /destroy
return
end
; Create simple main window
tlb = widget_base(title='Main Window', xsize=100, ysize=100)
widget_control, tlb, /realize
xmanager, 'mainwindow', tlb, /no_block
; Create another window with main window as group leader
popup = widget_base(title='Popup', tlb_frame_attr=31, /floating, group_leader=tlb)
cancelID = widget_button(popup, val='Cancel', event_pro='done', uval=tlb)
widget_control, popup, /realize
xmanager, 'popup', popup, /no_block
end
;=========================================================== ===================
Is there something else I have to do to get the desired behavior?
Dan Peduzzi
peduzzi@mediaone.net
|
|
|
|
|
|
| Re: Floating base widget [message #17939 is a reply to message #17895] |
Fri, 19 November 1999 00:00  |
Daniel Peduzzi
Messages: 29
Registered: June 1999
|
Junior Member |
|
|
David Fanning wrote in message ...
> Daniel Peduzzi (peduzzi@mediaone.net) writes:
>
>> I guess what I'm trying to simulate is what happens when
>> a user right-mouse-clicks on a bare desktop in a Microsoft
>> environment (or close enough.)
>
> Yes, I've tried from time to time to come up with this
> kind of design, too. But I've pretty much given up
> on it. It just seems more trouble than it is worth.
I *think* I've got it working the way I would like it to work
(again...close enough!)
Within Microsoft environments, if the user right-mouse-clicks on an
icon, the bare desktop, a window title bar, etc., a context-sensitive
menu list appears. The user can either select one of the items
in the list, or left-mouse-click anywhere else to dismiss the menu.
I've done something similar by creating my pop-up menu with
tlb_frame_attr=31 and enabling /kbrd_focus_events for the top-level
base. In the pop-up's event loop, I look for a WIDGET_KBRD_FOCUS
event and check the "enter" field of the event structure for 0.
If that happens, I simply destroy the top-level base. Otherwise,
I wait for the user to select an item from the menu and process
the selection accordingly.
Not as pretty as a Microsoft application, but it seems to meet
my needs for what I'm doing.
Thanks,
Dan Peduzzi
peduzzi@mediaone.net
|
|
|
|
|
|
| Re: Floating base widget [message #17954 is a reply to message #17895] |
Fri, 19 November 1999 00:00 |
Marc Schellens
Messages: 14
Registered: November 1999
|
Junior Member |
|
|
Daniel Peduzzi wrote:
>
> David Fanning wrote in message ...
>> Daniel Peduzzi (peduzzi@mediaone.net) writes:
>>
>>> I would like to create a window which can never be obscured by its
>>> group leader, but I can't seem to force the window to remain "on top."
>>>
>>> According to the IDL documentation, by setting the "floating" keyword
>>> when creating a top-level base, the "floating base widget will always
>>> appear above the base specified as the group leader."
>>
>> The documentation must have been talking about Windows
>> machines, because this floater really does float on my
>> Windows NT machine. No way I can get the first widget on
>> top of the second.
>>
>
> Argh...I'm definitely not seeing the same behavior, even
> though the docs do include Motif in the above description. :-(
>
> My intent was to present the user with a list of options
> in a popup window, triggered by a 3rd mouse button click
> in a draw widget. Depending upon the (x,y) location of the
> mouse click, the items in the list (selectable by the 1st
> mouse button) could be different.
>
> Everything works well except that the pop-up can get lost
> behind other windows, and it becomes a pain to look for because
> of its size. A floating base would have solved that problem.
>
> I guess what I'm trying to simulate is what happens when
> a user right-mouse-clicks on a bare desktop in a Microsoft
> environment (or close enough.)
>
> Can anybody point me in the right direction here?
>
> Dan
>
> Dan Peduzzi
> peduzzi@mediaone.net
Perhaps you can use something like this:
IF widget_info(ID,/VALID_ID) then widget_control,ID,/show
after every event (as last line in your eventhandler).
were ID is the ID of your 'floating' window.
This will re-raise you 'floating' window then.
Even though /FLOATING works fine on my Solaris machine.
So I guess this might be a problem of the window manager.
I am using KDE for Solaris.
hope this helps,
:-) marc
|
|
|
|
| Re: Floating base widget [message #17957 is a reply to message #17895] |
Fri, 19 November 1999 00:00 |
Daniel Peduzzi
Messages: 29
Registered: June 1999
|
Junior Member |
|
|
David Fanning wrote in message ...
> Daniel Peduzzi (peduzzi@mediaone.net) writes:
>
>> I would like to create a window which can never be obscured by its
>> group leader, but I can't seem to force the window to remain "on top."
>>
>> According to the IDL documentation, by setting the "floating" keyword
>> when creating a top-level base, the "floating base widget will always
>> appear above the base specified as the group leader."
>
> The documentation must have been talking about Windows
> machines, because this floater really does float on my
> Windows NT machine. No way I can get the first widget on
> top of the second.
>
Argh...I'm definitely not seeing the same behavior, even
though the docs do include Motif in the above description. :-(
My intent was to present the user with a list of options
in a popup window, triggered by a 3rd mouse button click
in a draw widget. Depending upon the (x,y) location of the
mouse click, the items in the list (selectable by the 1st
mouse button) could be different.
Everything works well except that the pop-up can get lost
behind other windows, and it becomes a pain to look for because
of its size. A floating base would have solved that problem.
I guess what I'm trying to simulate is what happens when
a user right-mouse-clicks on a bare desktop in a Microsoft
environment (or close enough.)
Can anybody point me in the right direction here?
Dan
Dan Peduzzi
peduzzi@mediaone.net
|
|
|
|
|
|
| Re: Floating base widget [message #18064 is a reply to message #17895] |
Tue, 23 November 1999 00:00 |
J.D. Smith
Messages: 214
Registered: August 1996
|
Senior Member |
|
|
Daniel Peduzzi wrote:
>
> J.D. Smith wrote in message <3835D0E5.9347A6FB@astro.cornell.edu>...
>>
>> Motif provides no Z-ordering, and hence FLOATING doesn't do as adverstised, as
>> indicated in the documentation.
>>
>
> Hmmm. Although my documentation does indicate that Motif applications
> share a single layer and have an arbitrary Z-order, it also states
> that "there is no special layering of IDL widgets, except that
> floating and modal bases always float above their group leaders."
>
> It's this last line, under a Motif heading, which caused me some
> surprise when it didn't actually work.
My documentation (vs 5.2.1) says simply:
"All elements on the screen -- widgets, the IDLDE, other Motif applications --
share a single layer and have an arbitrary Z-order. There is no special layering
of IDL widgets."
Notably absent is the phrase "except" from your version, which must have been
removed recently.
JD
--
J.D. Smith |*| WORK: (607) 255-5842
Cornell University Dept. of Astronomy |*| (607) 255-6263
304 Space Sciences Bldg. |*| FAX: (607) 255-5875
Ithaca, NY 14853 |*|
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
