This code recaptured the mouse in the window which had already had it, thus
triggering the (recently added, see r74677) asserts in CaptureMouse(). It also
didn't preserve the invariant of m_winCapture always having the capture. And
it was apparently completely unnecessary too.
So simply remove it to fix the asserts while drag-resizing wxGrid rows/columns.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74752 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The code there was pretty wild, making clearly wrong assumptions (column size
doesn't, and AFAICS never did, include 20 pixel margin) and also was clearly
uncertain about what it was doing by trying to limit the number of iterations
to some arbitrary cutoff when it is pretty clear that the loop increasing the
width and decreasing the height on each iteration will reach the condition of
"width >= height*1.68" sooner or later.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74751 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
It was assumed that all callers were going to unref the cairo_t, but that is not
true, so callers that are going to unref it should ref it themselves.
See #15455
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74746 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We didn't ensure that the parent of a (native) control with WS_EX_CONTROLPARENT
had this style as well, unlike for our own windows. Fix this now to make
certain that we never call ::IsDialogMessage() on a window whose parent
doesn't have WS_EX_CONTROLPARENT as it simply hangs in this case, entering an
infinite loop searching for the default button.
Also try to reduce the possibility of such bugs in the future by checking for
WS_EX_CONTROLPARENT and not wxTAB_TRAVERSAL before calling ::IsDialogMessage()
even if this doesn't totally prevent them (it wasn't sufficient to fix even
this particular bug).
Closes#15458.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74732 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The mnemonics conversion was not done correctly when the menu title contained
them but the menu hadn't been appended to the menu bar yet.
Closes#15461.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74731 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxWindowGTK::GTKGetScrollEventType() tries to map GtkAdjustment's delta
to either step or page increment by comparing it with the respective
GtkAdjustment steps. Both of them can be 0, but this code is not
expected to be called in such case.
Yet, in practice, it occasionally is, see e.g.
http://devel.aegisub.org/ticket/979GTKGetScrollEventType (wxWebView is
prone to it as well).
Check for >= 0 instead, to be more robust when faced with unexpected
input from GTK+.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74730 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
For some reason, wxDialUpManager code defined __STRICT_ANSI__ itself, don't do
it as __STRICT_ANSI__ can be predefined by the compiler resulting in the
redefinition warnings and, in any case, our code should build both with and
without it.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74728 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Finding a button in a child dialog when looking for it in the current window
is totally unexpected and can result in subtle bugs, see #15442.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74721 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The item being inserted is not inserted yet when we call
SetOwnerDrawnMenuItem() so we must call it separately for it after inserting
it.
Closes#15437.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74717 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Previously we erroneously used the first icon in the image list for them
instead. This was inconsistent with wxGTK and didn't make much sense, even if
it is the default behaviour of the native control, so don't do this any more
and explicitly specify I_IMAGENONE for the icon if it wasn't given.
Closes#15421.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74716 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Override CanScroll() in wxScrolled to return the real state of the scrollbar
instead of just relying on the wx[HV]SCROLL styles.
Closes#15440.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74714 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We need to do this when using any port under OS X, not just wxOSX, e.g. the
-psn_xxx arguments passed by the Finder when launching the application, must
also be ignored when using wxGTK.
Closes#15432.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74703 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The path passed to this function is always a directory, so use
wxFileName::AssignDir() instead of the default constructor of wxFileName which
considers the name to be a name of a file unless it ends with a path separator.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74696 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This removes the arbitrariness of using the first child which didn't make any
sense when the popup had several controls inside it, e.g. in wxRichToolTip
case this resulted in the mouse capture being given to wxStaticBitmap showing
the tooltip icon even though it didn't need it at all.
This probably doesn't really change the observable behaviour but seems more
logical.
See #15288.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74680 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This works even with irregularly shaped windows such as wxRichToolTip unlike
the old naive test using wxRect::Contains() which didn't and resulted in us
believing that the mouse was outside the window when it was still in it and
(somehow, the details are not totally clear) recapturing the mouse again and
again in the same window which resulted in assert failures with the new checks
in wxWindowBase::CaptureMouse() or the capture stack corruption before this.
Closes#15288.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74679 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Make GetCapture() return NULL during wxEVT_MOUSE_CAPTURE_{LOST,CHANGED} events
processing in wxMSW to help their handlers to avoid calling ReleaseCapture():
this shouldn't be done as the mouse capture is being lost anyhow and results
in reentrancy problems between NotifyCaptureLost() and ReleaseCapture() if
it's called.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74678 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Verify not only that we don't destroy the window having the capture now but
also that this window is not in the mouse capture stack at all, not
necessarily on top. This is important as keeping a dangling pointer in the
capture stack would result in difficult to diagnose bugs later.
Also check that we don't recapture the mouse in the same window as this should
never be necessary.
Finally, give more details in the assert checking that the window does have
capture in ReleaseMouse().
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74677 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This doesn't work anyhow with our popup window implementation (it's a child of
the desktop and we can't set focus to it) and provokes error messages due to
::SetFocus() failures, so simply don't do this at all.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74676 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use wxRecursionGuard with the flag indicating whether the mouse capture is
changing to ensure that we always reset it correctly and make the code
slightly shorter.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74674 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
All mouse capture-related data doesn't have to be declared in wxWindow itself
and can just be global in wincmn.cpp, so move it there, this will facilitate
further changes as they won't require recompiling everything any more.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74673 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Otherwise comparison always failed as no existing fonts had
wxFONTFAMILY_DEFAULT as their family in all ports except wxOSX, which does
keep wxFONTFAMILY_DEFAULT.
Closes#15410.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74660 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
r72935 introduced code that created a temporary wxComboBox control to
take measurements. This is very expensive in MSW and adds noticeable
delay when creating more than a few controls.
Replace with equivalent wxMSW code that computes the height in the same
way other wxMSW controls do.
The wxGTK version cannot be eliminated in the same way, so at least add
some basic caching there. It's much less of a problem, because GTK+
controls creation is much cheaper than MSW one.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74658 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This results in sending an unexpected wxShowEvent to an already half-destroyed
(because the derived class dtor had been already executed) by now object which
could provoke crashes. And it also seems to be completely unnecessary as the
window is going to be destroyed anyhow -- and the other ports don't hide it
before this happens (unless it's a TLW in which case it is already hidden in
wxTopLevelWindowBase::Destroy()).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74655 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
