[ wxwindows-Patches-1825170 ] MSW wxFileDialog: center on parent fix

[Tomas Rapkauskas]

> Sorry, this workaround is IMO bad and I can't apply it even if it does
> solve the problem. First, having both (unused) gs_rectDialog and
> gs_centerDialog is IMO bad. Second, we should arrange to use
> wxTLW::Centre() which already accounts for multiple monitors &c instead of
> (imperfectly) duplicating it here. 
Yes agree on this, that code duplication should be avoided.
During first implementation I used Centre function, but I got incorrect
position for the file dialog, I could not understand why...

Today I found DoGetScreenPosition works in different ways
for TLW and non TLW (MSW build) :)

// Unlike other wxTopLevelWindowBase, the mdi child's
// "GetPosition" is not the same as its GetScreenPosition
void wxMDIChildFrame::DoGetScreenPosition(int *x, int *y) const

I used code in such way:
wxWindow parent;
// now I am using check ::GetParent(hParent); is it TLW
parent.SetHWND((WXHWND)hParent);		parent.AdoptAttributesFromHWND();
wxFileDialog fileDialog(..., &parent);

I do not understand: why different implementations exist of
DoGetScreenPosition for TLW and NTLW? (MSW build)

wxWindowBase::DoGetScreenPosition
      if ( x )
         *x = 0;
     if ( y )
         *y = 0;

     ClientToScreen(x, y);

(DoClientToScreen->wxWindowMSW::DoClientToScreen->
->::ClientToScreen(GetHwnd(), &pt);

According to me this is the same as using directly GetWindowRect()..
Probably I am missing something.
As a library user I am forced to
check: do I have parent as Top Level Window or Not..
(anyway this is minor, if user uses wxWindows based parent window
there is no problem)


Tomas