Opened 7 years ago

Closed 6 years ago

#4717 closed defect (fixed)

Z-order Raise() Lower() erroneous behavior

Reported by: zxfox Owned by:
Priority: normal Milestone:
Component: documentation Version: 2.8.8
Keywords: z-order Raise() Lower() Cc: zxfox, vaclavslavik
Blocked By: Blocking:
Patch: no

Description

Please see this video, two windows are drawn and process mouse messages in different order

Attachments (1)

1.avi download (190.2 KB) - added by zxfox 7 years ago.

Download all attachments as: .zip

Change History (12)

Changed 7 years ago by zxfox

comment:1 Changed 7 years ago by zxfox

Lower(), and Raise() doesn't help

comment:2 Changed 7 years ago by vaclavslavik

It's not at all clear even what the problem is from this, let alone what you *do* in your code. Please actually describe what the exact(!) problem is, in what wx version, and what you do -- preferably in the form of small patch against one of the wx samples that allows us to reproduce it.

comment:3 Changed 7 years ago by sf-robot

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

comment:4 Changed 6 years ago by Catalin

  • Keywords z-order Raise() Lower() added
  • Milestone set to 2.8.9
  • Priority changed from normal to high
  • Status changed from closed to reopened
  • Summary changed from Z Buffer error to Z-order Raise() Lower() erroneous behavior
  • Version set to 2.8.8

Hi,
I encountered the same issue as the one in the video; the video is actually good, but it is not explained.
I suppose this the case in the video too: If you have 2 overlapping panels, an have for them
OnLeftDown( wxMouseEvent& event )
{

this->Lower();

}
you get the behavior in the video - The "lowered" window (panel) will no longer receive the event, but it will still be drawn on top; nothing changes if you also call SetFocus() or Refresh() on the "lowered" window.

It is not a programming error because if you will build the "resizable controls sample" with wxWidgets 2.8.8, and you will overlap the panels and do something to refresh the main window (resize the main window), you will see the odd behavior (it is not exactly as the one in the video but it is related to it, as it uses Raise()). In the original build (with 2.4.2) this does not happen!

http://de.geocities.com/markusgreither/resizec.htm

On short,
Raise() will make the window that it is called upon to start receiving the mouse events, but from the graphic point of view it is not "on top" - it will be corrupted by the window(s) that should be beneath it
Lower() will make the window stop receiving the events but the window will be drawn on top of all other windows that should overlap it.

I did not check, but I suspect it only happens on wxMSW...

comment:5 Changed 6 years ago by vadz

  • Resolution set to invalid
  • Status changed from reopened to closed

wxWidgets doesn't support overlapped child windows, I really don't think it's worth the hassle and it just doesn't seem to be worth it. Simply don't use them.

comment:6 Changed 6 years ago by Catalin

ok, well, allow me to be puzzled, this is a functionality that worked some versions ago and now is broken (it is BROKEN); and then again, what is the purpose of Raise() and Lower() ??
also, forgive my daring, but i really need that functionality, exactly for overlapping child windows (I know, this is a free/open/no charge framework), and the amazing thing is that it was there, and now the answer is that it is not supported?? c'mon.. it sounds like dumb 'corporate' answer to a relevant issue...

comment:7 Changed 6 years ago by Catalin

  • Resolution invalid deleted
  • Status changed from closed to reopened

comment:8 Changed 6 years ago by vadz

  • Resolution set to invalid
  • Status changed from reopened to closed

If it worked, it was an accident (and I'm far from sure it really always worked, in fact I'm rather sure it didn't work with all windows), feel free looking into mailing list archives for posts in which I advise people not to use overlapping child windows many years ago.

Raise() and Lower() are for top level windows only although, because wxTopLevelWindow didn't originally exist, they unfortunately happen to be defined in wxWindow itself.

Finally, I'm sorry that you're unhappy about my answer but it is not supported, I don't know what is involved in supporting it but it will almost surely result in other problems under other platforms and so I have no intention to do it. If you have a patch fixing this problem without introducing too much complexity and, of course, without breaking anything else, then we'd be glad to apply it but that's about it.

comment:9 Changed 6 years ago by Catalin

ok... than this is really bad news...for me. thanks for your quick answers

comment:10 Changed 6 years ago by wojdyr

  • Component changed from wxMSW to doxygen docs
  • Milestone 2.8.9 deleted
  • Priority changed from high to normal
  • Resolution invalid deleted
  • Status changed from closed to reopened

Documentation says:

void wxWindow::Raise()
Raises the window to the top of the window hierarchy (Z-order). In current version of wxWidgets this works both for managed and child windows.

also #799 and #7061 suggest it should work for non-TLW.

If these functions are meant only for TLW, this is a documentation bug.

comment:11 Changed 6 years ago by FM

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [56982]) clarified that Raise() and Lower() only work for wxTopLevelWindows (closes #4717)

Note: See TracTickets for help on using tickets.