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
Prevent WM_CONTEXTMENU from being propagated upwards the window parent chain
by DefWindowProc(), we already do it ourselves and not marking the message as
processed could result in multiple calls to the same wxEVT_CONTEXT_MENU
handler if it skipped the event.
See #13683.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73949 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use the same short names as are used by the event table macros for the event
type constants themselves. This makes them much more comfortable to use, e.g.
Bind(wxEVT_BUTTON) compared to Bind(wxEVT_COMMAND_BUTTON_CLICKED).
The old long names are still kept for backwards compatibility and shouldn't be
removed as it doesn't really cost anything to continue providing them, but all
new event types should only use the short versions.
Closes#10661.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73850 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use the fixed value of 0 for the keys without Unicode equivalent instead of
whatever junk was there in the uninitialized variable.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73719 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
U+007F is a Unicode character so we should set Unicode key code to this value
for VK_DELETE presses. This also makes wxMSW consistent with wxGTK.
Closes#3458.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73718 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We must use physical coordinates for the brush origin to account for the
coordinates offset in scrolled windows, so add MSWAdjustBrushOrg() and call it
from MSWGetBgBrushForChild().
Closes#14917.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73495 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This fixes a long standing problem with 2 wxPaintDC created one after another
(and not with nested lifetimes, which was handled by the caching mechanism
previously used) not working correctly. And as this was exactly what happened
when handling wxEVT_PAINT for wxScrolled, it also fixes drawing artefacts when
using scrolled windows.
Closes#14757.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@72938 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Add a new private wxTextMeasure class implementing methods for measuring text
and move the often duplicated (but not always identically) code for doing the
same from wxDC and wxWindow into it.
Currently this class is only really implemented in wxMSW and wxGTK.
Also extend the test for text measuring functions and rename it to
MeasuringTextTestCase from MeasuringContextTestCase as it's not wxGC-specific
any more.
Closes#14705.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@72699 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Return the deepest child of the window and not the first one as this function
needs to return the window that is at the top of Z-order.
Closes#14591.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@72470 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This results in a noticeable delay when using wxGTK via a remote X11
connection for every key event as a round trip to server is needed to get the
mouse pointer position every time a key is pressed or released.
Only provide the position on demand. And explain that it's actually not very
useful as it's simply the same as the current mouse position.
Closes#14361.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@72207 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
