According to the docs, Raise() only works on managed windows like frames or dialogs. Is there anything equivalent available for panels? IOW, if I have two overlapping panels in a frame, can I programmatically make one appear on top of the other?
___/
/
__/
/
____/
Ed Leafe
Linux Love:
unzip;strip;touch;finger;mount;fsck;more;yes;umount;sleep
How about .Show(True) and .Show(False) [or .Hide()]?
--- Ed Leafe <ed@leafe.com> wrote:
According to the docs, Raise() only works on managed windows
like frames or dialogs. Is there anything equivalent available
for panels?
=====
Donnal Walter
Arkansas Children's Hospital
I need *both* to be visible. They overlap but do not completely obscure each other.
___/
/
__/
/
____/
Ed Leafe
http://leafe.com/
http://opentech.leafe.com
On May 5, 2004, at 9:14 AM, Donnal Walter wrote:
According to the docs, Raise() only works on managed windows
like frames or dialogs. Is there anything equivalent available
for panels?How about .Show(True) and .Show(False) [or .Hide()]?
According to the docs, Raise() only works on managed windows
like frames or dialogs. Is there anything equivalent available
for panels?
Raise() does exactly what you want! Try it if you don't belive me. I did and it worked 
On Wed, 5 May 2004 09:32:42 -0400, Ed Leafe <ed@leafe.com> wrote:
On May 5, 2004, at 9:14 AM, Donnal Walter wrote:
How about .Show(True) and .Show(False) [or .Hide()]?
I need *both* to be visible. They overlap but do not completely obscure each other.
--
Peter Damoc
Hacker Wannabe
Peter Damoc writes:
>>> According to the docs, Raise() only works on managed
>>> windows like frames or dialogs. Is there anything
>>> equivalent available for panels?
Raise() does exactly what you want! Try it if you don't
belive me. I did and it worked
Can you post your code please? I can't get it to work in
2.5.1.5/GTK2 at all.
--
Paul
Ooopsie... I'm on WinXP 
it works overhere so I guess it might be a platform issue.
the code used to test it was something like
b1 = wx.Button(self, -1, "button1")
b2 = wx.Button(self, -1, "button2")
b2.SetPosition((20,-1))
b1.Raise()
and I got b1 on top of b2
On Wed, 5 May 2004 06:54:29 -0700, Paul McNett <p@ulmcnett.com> wrote:
Peter Damoc writes:
>>> According to the docs, Raise() only works on managed
>>> windows like frames or dialogs. Is there anything
>>> equivalent available for panels?Raise() does exactly what you want! Try it if you don't
belive me. I did and it workedCan you post your code please? I can't get it to work in
2.5.1.5/GTK2 at all.
--
Peter Damoc
Hacker Wannabe
Peter Damoc writes:
> Can you post your code please? I can't get it to work in
> 2.5.1.5/GTK2 at all.
Ooopsie... I'm on WinXP
might be a platform issue.
Yeah, the docs say it'll work for all managed windows, and on
Windows IIRC all windows are managed, whereas on GTK only
top-level (frames) windows are managed.
I *think* that a good way to know in advance if a given window
will react to Raise() or Lower() is whether or not a non-zero
value is returned from window.GetWindowHandle(). On Windows,
all windows have handles, where on Linux only top-level windows
do. I have no idea what happens on Mac.
That scores a point for Windows in the Windows/Linux debate,
IMHO. If I can't control the Zorder of my windows, I'm not in
complete control of the gui, and I'm a less effective
programmer because of it.
the code used to test it was something like
b1 = wx.Button(self, -1, "button1")
b2 = wx.Button(self, -1, "button2")
b2.SetPosition((20,-1))
b1.Raise()and I got b1 on top of b2
Confirmed. I just ran my test, which was similar to yours, on
Windows NT4/wxPython2.5.1.5 and Raise() worked, while on
GTK2/wxPython2.5.1.5 it didn't.
The Tab Order and Zorder limitations are going to bite me over
and over again... (but wx still rocks - I just have to learn
what workarounds to suggest to my users).
Now, one workaround for the Zorder problem seems to be to
recreate the siblings in the required order - I mentioned I was
going to try that on this list a week or so ago - but even that
is flaky and I've abandoned the exercise because:
+ Tab Order doesn't reflect the new Zorder, as Kevin Altis
warned previously.
+ Visible Zorder and which window on a stack of windows gets the
focus appear to be separate beasts, and are sometimes
consistent and sometimes not (a window that appears on top of
another may or may not be the one that gets the focus when
clicked upon - the focus *may* end up going instead to a
completely obscured window).
+ Some windows don't instantiate on top of the already existing
windows, but behind them, and some stay on top of
newly-instantiated controls. For example, check out my attached
code which instantiates a wxGauge, a wxButton, and a wxTextCtrl
on a wxPanel - the Gauge ends up on top of the button even
though it was instantiated first, and then the TextCtrl ends up
(correctly) on top of them all.
Conclusion: There are three problems that need to be addressed
in a multiplatform way: Zorder, SetFocus order, and Tab Order.
I know I don't have the knowledge, background, or coding ability
to make the required changes - indeed, I don't even know where
the required changes would go (wxWidgets, GTK, etc.) -, and
presumably if there were a straightforward solution it would
have already been done a long time ago. I am just a user, after
all, trying to find out how to use the tools available to
accomplish the task at hand.
layer.py (580 Bytes)
--
Paul
Ed Leafe wrote:
I need *both* to be visible. They overlap but do not completely obscure each other.
I'd advise against doing this. I think you could get some weird results on different platforms (or even different versions) than what you are testing on.
In general, I don't think wxWindows were designed to be overlapping.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
Peter Damoc wrote:
On Wed, 5 May 2004 06:54:29 -0700, Paul McNett <p@ulmcnett.com> wrote:
Peter Damoc writes:
>>> According to the docs, Raise() only works on managed
>>> windows like frames or dialogs. Is there anything
>>> equivalent available for panels?Raise() does exactly what you want! Try it if you don't
belive me. I did and it workedCan you post your code please? I can't get it to work in
2.5.1.5/GTK2 at all.Ooopsie... I'm on WinXP
Yep. Raise is just a thin wrapper around platform APIs and so it depends on what the platform does with the call. For example, in wxGTK it calls gdk_window_raise(m_widget->window) however not all widgets have a window. Some are just drawn directly on their parent window, so Raise does nothing in those cases.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Overlap works on Windows for almost all controls, doesn't work at all on the Mac despite appearing to work visually for some controls, and on GTK it depends on the phase of the moon <wink>
The only solution for changing the Z-order I can think of that should work on all platforms is completely destroying and recreating ALL the controls on the Panel. If Freeze/Thaw is used then this might be an acceptable workaround.
ka
On May 5, 2004, at 9:46 AM, Chris Barker wrote:
Ed Leafe wrote:
I need *both* to be visible. They overlap but do not completely obscure each other.
I'd advise against doing this. I think you could get some weird results on different platforms (or even different versions) than what you are testing on.
In general, I don't think wxWindows were designed to be overlapping.
-Chris
Unfortunately, that doesn't work on GTK. Controls appear in an order determined by their type, not their creation order.
___/
/
__/
/
____/
Ed Leafe
Linux Love:
unzip;strip;touch;finger;mount;fsck;more;yes;umount;sleep
On May 5, 2004, at 1:28 PM, Kevin Altis wrote:
The only solution for changing the Z-order I can think of that should work on all platforms is completely destroying and recreating ALL the controls on the Panel. If Freeze/Thaw is used then this might be an acceptable workaround.
Wow, that is so wrong on so many levels. I guess at this point I shouldn't be surprised by that kind of thing, but it is extremely annoying.
ka
On May 5, 2004, at 12:00 PM, Ed Leafe wrote:
On May 5, 2004, at 1:28 PM, Kevin Altis wrote:
The only solution for changing the Z-order I can think of that should work on all platforms is completely destroying and recreating ALL the controls on the Panel. If Freeze/Thaw is used then this might be an acceptable workaround.
Unfortunately, that doesn't work on GTK. Controls appear in an order determined by their type, not their creation order.
Kevin Altis wrote:
On May 5, 2004, at 12:00 PM, Ed Leafe wrote:
On May 5, 2004, at 1:28 PM, Kevin Altis wrote:
The only solution for changing the Z-order I can think of that should work on all platforms is completely destroying and recreating ALL the controls on the Panel. If Freeze/Thaw is used then this might be an acceptable workaround.
Unfortunately, that doesn't work on GTK. Controls appear in an order determined by their type, not their creation order.
Wow, that is so wrong on so many levels. I guess at this point I shouldn't be surprised by that kind of thing, but it is extremely annoying.
Since some widgets don't have a window and are just drawn directly on the parent there is not much you can to make it overlap another widget that does have a window.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Yep, I think that's one of the fundamental flaws and those widgets need their own windows that they draw on, they shouldn't draw on the parent and the parent shouldn't be the the target of the events either. I already have another post I want to make about finally fixing StaticBitmap on GTK, but I'll send that tomorrow. The kind of wrapper you've done with wx.lib.stattext.GenStaticText needs to make its way back to wxWidgets so some of the GTK controls will no longer be abominations. 
ka
On May 5, 2004, at 10:29 PM, Robin Dunn wrote:
Kevin Altis wrote:
On May 5, 2004, at 12:00 PM, Ed Leafe wrote:
On May 5, 2004, at 1:28 PM, Kevin Altis wrote:
The only solution for changing the Z-order I can think of that should work on all platforms is completely destroying and recreating ALL the controls on the Panel. If Freeze/Thaw is used then this might be an acceptable workaround.
Unfortunately, that doesn't work on GTK. Controls appear in an order determined by their type, not their creation order.
Wow, that is so wrong on so many levels. I guess at this point I shouldn't be surprised by that kind of thing, but it is extremely annoying.
Since some widgets don't have a window and are just drawn directly on the parent there is not much you can to make it overlap another widget that does have a window.