Opened 6 years ago

Closed 6 years ago

#16635 closed defect (fixed)

"Save As" lowers document window

Reported by: andrewc Owned by: vadz
Priority: normal Milestone:
Component: wxMSW Version: 3.0.2
Keywords: MDI z-order Cc:
Blocked By: Blocking:
Patch: no

Description

"Save As" functionality in an MDI application lowers the child frame window of the document in question, leaving it behind other documents.

Bug discovered while developing an MDI wxWidgets 3.0.1 application in Visual Studio 2013 on Windows 7.

This is easy to reproduce in the docview sample application: open two text documents, say a.txt and b.txt, then "Save As..." b.txt to a different path. The child frame of the latter document, which should still be active, is now below the frame for a.txt.

This lowering appears to occur before OnSaveDocument is called, but I have not been able to pinpoint the bug any more precisely.

Change History (4)

comment:1 Changed 6 years ago by awi

  • Keywords z-order added; "save as" window lower removed
  • Version changed from 3.0.1 to 3.0.2

I can confirm reported issue but there are also other scenarios when this effect can be observed.
To change the z-order of child windows (documents) it is not necessary to actually save top-level document under new name. One can simply invoke a file selector (either via 'Save as' or 'Open' option) and resign from saving or opening.
If we have two open files (say a.txt, b.txt) and a.txt was opened as a first one then the z-order looks initially like this:
bottom -> a.txt -> b.txt -> top
After invoking a file selector it looks like:
bottom -> b.txt -> a.txt -> top
The same effect can be observed if we open 3-rd document (say c.txt):
bottom -> b.txt -> a.txt -> c.txt -> top

It seems that after some kind of operations documents are reordered by the opening time.
I don't know if this is a bug but for sure this behavior is counterintuitive (the z-order should be rather retained).

comment:2 Changed 6 years ago by awi

Under wxGTK docview sample exhibits rather TDI then MDI but the order of tabs with documents remains intact while opening the documents, saving them, etc.

It looks that under wxMSW the z-order of child windows is affected somehow by wxFileSelector which is called in wxDocument::SaveAs and in wxDocManager::SelectDocumentPath (from wxDocManager::CreateDocument).
Bypassing for testing purposes wxFileSelector in these functions results in unchanged z-order of child windows.

comment:3 Changed 6 years ago by vadz

  • Owner set to vadz
  • Status changed from new to accepted

This is a bug somewhere in our focus saving/restoring code, debugging it...

comment:4 Changed 6 years ago by VZ

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

In 78341:

Don't change MDI children order after showing a file dialog in wxMSW.

Don't use the generic focus saving/restoring code for wxMDIParentFrame in
wxMSW as it already saves and restores the active MDI child on its own and we
should let it do it, as our code could change the active child when restoring
focus if it hadn't been saved correctly previously.

The fact that it is isn't saved is another bug, but even if it is fixed, we
should let MSW MDI implementation handle activation as we can't do it any
better -- but can do worse, as the bug described in #16635 shows.

Closes #16635.

Note: See TracTickets for help on using tickets.