This will make it possible to reproduce the default "Enter" key functionality
from elsewhere.
Almost no changes yet, the only minor change is that we now wouldn't try to
"click" any windows using DLGC_DEFPUSHBUTTON dialog code but which are not
really buttons -- but then this shouldn't ever happen anyhow.
Don't call wxMenu::UpdateUI() explicitly in wxMSW, wxGTK and wxOSX code before
showing the popup menu as it is also called when any menu is opened from
port-independent wxFrameBase wxEVT_MENU_OPEN handler, resulting in two events
being generated.
But also don't send the events from wxFrameBase handler only to the frame
itself, by explicitly passing "source" argument to wxMenu::UpdateUI(), as this
prevented the event from being sent to the window popping up the menu. By just
omitting this parameter we ensure that this event is sent to the right window.
Closes#17352 (but notice that there are still duplicate events under OS X,
see #17354).
This reverts 54753c3d75 and (partially)
dbd5b2ce42 (leaving the unit test added by it)
and implements yet another fix for the original problem of duplicate
wxContextMenuEvents generated in wxMSW which doesn't break the generation of
wxContextMenuEvents entirely in wxTreeCtrl.
wxTreeCtrl is special as its DefWindowProc() sends WM_CONTEXTMENU directly to
its parent, and not to the control itself, when handling WM_RBUTTONUP, so the
code checking that WM_CONTEXTMENU was not coming from one of the window own
children added in dbd5b2 filtered out all messages from it completely. As it's
probably not the only control behaving in this way, abandon the idea of the
message origin check and instead set things up so that we still pass the
message to DefWindowProc() (because not doing it breaks built-in context menus
in wxTextCtrl, for example), but don't do anything when the message is
propagated upwards from it.
This should ensure that we only process the message once in MSWHandleMessage()
of the first window which gets it, whether it's the original window or its
parent, which ensures the event propagation on wxWidgets side of things, but
prevents it being done by Windows itself.
See #13683.
This was broken since 39ad820bee which added
wxSEH_TRY to wxWndProc() which uses a local object with dtor when
wxDEBUG_LEVEL>=2 and so broke its compilation with MSVC which doesn't allow
the use of dtors in functions also using SEH.
Closes#17095.
::SetWindowLong() can return 0 even if no error occurred but the previous
value of the ID just was 0, so we need to examine the last error to know
whether there really was an error -- and also to reset it to 0 before calling
the function as it wouldn't reset it if it succeeds, it only sets it if it
fails.
Fix the build in wxUSE_STATBOX=0 and wxUSE_DRAG_AND_DROP=0 case:
AdjustStaticBoxZOrder() must still be defined as it's also used in
DragAcceptFiles().
Closes https://github.com/wxWidgets/wxWidgets/pull/111
Windows CE doesn't seem to be supported by Microsoft any longer. Last CE
release was in early 2013 and the PocketPC and Smartphone targets supported by
wxWidgets are long gone.
The build files where already removed in an earlier cleanup this commit
removes all files, every #ifdef and all documentation regarding the Windows CE
support.
Closes https://github.com/wxWidgets/wxWidgets/pull/81
Unexpectedly, minimizing the window by clicking on its taskbar icon resulted
in a wxActivateEvent. This broke the focus handling in wxTLW and resulted in
debug messages about ::SetFocus() failure whenever the window was minimized in
this way.
It also seems that other existing code doesn't take into account the
possibility of getting an "active" activation event when the window is
minimized and this doesn't happen in the other ports, so don't send this event
in wxMSW neither.
Closes#17128.
Don't let unhandled Win32 (i.e. structured) exceptions escape from wxWndProc()
as they can just disappear into thin air when running under WOW64 as 32 bit
exceptions can't propagate through 64 bit kernel. So catch them immediately
and pass them to the global handler while we have the chance to do it, as
we're never going to get it in the outer __try/__catch block in wxEntry() in
src/msw/main.cpp.
In particular, this allows to catch crashes in wxEVT_PAINT handlers, such as
the one in debughlp sample, again.
Closes#16656.
This was broken due to a wrong cast from WPARAM (i.e. 32 bit unsigned int in
Win32) value containing the ID to WORD (i.e. 16 bit unsigned short) which
truncated the ID value.
Notice that MSDN documents the requirement for the IDs to be positive, but
negative IDs seem to work, at least with Windows 7, after this fix.
Closes#16880.
Send these events to the menu itself first, then to the menu bar containing
it or the window invoking it if it's a popup menu and, finally, to the top
level window in all of wxGTK, wxMSW and wxOSX.
In particular, this ensures that help strings are now shown in the parent MDI
frame status bar by default, even when the menus are attached to the client
MDI frame or shown as popup menus.
At the implementation level, this logic is now encapsulated in a new static
wxMenu::ProcessMenuEvent() method which can be easily modified and reused in
other ports.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78230 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This parameter is redundant, we can find out whether a menu is a popup one or
not from the menu itself, assuming that we always have a valid wxMenu pointer
for popup menus events, which really should be the case (we may not have one
for the events from system menus).
This allows to handle popup menu events case in the base class version of
MSWFindMenuFromHMENU() which will allow to reuse it from places other than
DoSendMenuOpenCloseEvent() without code duplication now.
There should be no changes to the behaviour, this is just a simplification.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78227 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The EDIT control used by the native combobox is different from normal EDIT
controls and has to be handled specially.
We also need to explicitly forward WS_EX_LAYOUTRTL to the dropdown window as
it doesn't inherit it from the combobox itself automatically.
See #11583.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77754 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This should result in the default handler still being called and painting the
window, but the latter didn't happen because we called ::EndPaint(), and so
validated the window and reset its update region, before passing WM_PAINT to
DefWindowProc() in this case.
Closes#16381.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77655 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This ended up being broken due to an interplay between different unrelated
changes (at least r15120 and r41134) which were both correct, but didn't work
well together and resulted in not only preventing IsDialogMessage() from
handling ESC, but also our own accelerator tables.
Fix this by doing the check for IsDialogMessage() brokenness in
MSWProcessMessage() itself, just before calling it, instead of doing it in
MSWShouldPreProcessMessage() which is (and must be) called before
MSWTranslateMessage() which checks for accelerators using ESC.
Closes#3813.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77071 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Just use the native ::MapWindowPoints() to do the coordinate transformation
instead of doing it ourselves: we did it wrongly by inheriting the layout
direction from wxTheApp instead of from the parent window, so fix this in the
best possible way by not doing it at all and just relying on Windows to do it
for us.
In particular, this corrects the display of wxStatusBar in RTL frames.
Closes#15031.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76992 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The keyboard handling code could decide to activate a button which wasn't
currently visible at all, e.g. because it was on a non-current, and hence
hidden, page of a wxBookCtrl. This didn't make any sense, so check for the
button visibility before activating it.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76990 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
WM_COMMAND is delivered after WM_UNINITMENUPOPUP and clearing
wxCurrentPopupMenu in the latter's handler broke delivery of the command
event to the wxTextCtrl control.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76773 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
In wxMSW, use IRichEditOleCallback::GetContextMenu() to provide our
default context menu for rich text controls, instead of using
EVT_CONTEXT_MENU.
The latter completely overrides native control's handling and in
particular breaks Windows 8's builtin spellchecking support.
Fall back to the previous non-OLE code for older richtext versions.
Also make the new MSWCreateContextMenu() method virtual so that the
context menu can be customized.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76723 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Contrary to MSDN implications, at least some of these messages are not
actually sent to the TLW for popup menus, but to the owning window or
even its parent window (!).
Move the handling of these events from wxTLW to wxWindow. Move menu
depth tracking to wxFrame, because it only makes sense for frame's
menus and move DoGiveHelp() from wxTLW to wxFrame.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76721 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This must be done both at wxWidgets and MSW level, otherwise changing the ID
results in window not recognizing itself as the recipient of the messages sent
to it by Windows.
Closes#3697.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76672 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't test for wxUSE_NORLANDER_HEADERS, this is always true since many, many
years.
Remove tests for gcc version < 3.3, notably 2.95: the minimal supported gcc
version is 3.4.
Closes#15727.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76549 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Most importantly, this allows us to remove all MSLU-related stuff.
Some functions which were previously loaded dynamically can now be just used
directly, too.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76535 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Modal dialogs shown during wxBusyCursor effect shouldn't show the busy cursor
as they do accept input, but did in wxMSW (as could be seen in e.g. the
widgets sample after enabling the "Global busy cursor" in the menu and showing
the text entry dialog via "Text|Set Help Hint").
Fix this by explicitly checking for the special case of having a modal dialog
as parent at wxWindow level as doing it in wxDialog simply didn't work as its
WM_SETCURSOR handler wasn't called at all for determining the cursor to use
for its children because they handled WM_SETCURSOR themselves in the global
busy state, without letting DefWindowProc(), which propagates this message
upwards the window hierarchy, to have it at all.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76449 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The screen to client conversion for this event coordinates took the toolbar
height into account twice, resulting in a wrong value if the event was handled
in a frame that did have a toolbar.
Closes#15812.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75563 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This check was replaced with a check for WS_EX_CONTROLPARENT in r74732 to
avoid using ::IsDialogMessage() when WS_EX_CONTROLPARENT is not set, but it
also resulted in using it when WS_EX_CONTROLPARENT is set but wxTAB_TRAVERSAL
is not.
Check for both of them now so that we only use IsDialogMessage() when we need
it (wxTAB_TRAVERSAL) and when it is safe to do it (WS_EX_CONTROLPARENT).
Closes#15565.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75061 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This method is implemented for wxMSW-only currently and allows to check
whether the window is being activated by a mouse click or in some other way
there.
Closes#15516.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74915 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
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
This keyword is not expanded by Git which means it's not replaced with the
correct revision value in the releases made using git-based scripts and it's
confusing to have lines with unexpanded "$Id$" in the released files. As
expanding them with Git is not that simple (it could be done with git archive
and export-subst attribute) and there are not many benefits in having them in
the first place, just remove all these lines.
If nothing else, this will make an eventual transition to Git simpler.
Closes#14487.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74602 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Fix the bug with multiple wxContextMenuEvent being generated for a single
WM_CONTEXTMENU without breaking context menus for wxTextCtrl (and all the
other native controls). Do this by ensuring that WM_CONTEXTMENU is still
passed to DefWindowProc() if we don't process it instead of just being eaten
completely in any case.
Also add a unit test checking for this bug to ensure it stays fixed.
See #13683.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74329 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is similar to the existing GetLinesPerAction() but is for, surprise,
columns.
Also change the documentation to say that the value returned by both of these
methods is 3 under "most platforms" as some wxOSX currently uses 1 and not 3.
Closes#15239.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74156 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is just a refactoring of wxMSW code to make it possible to use deferred
window positioning from other places in subsequent commits.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74066 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
