Don't repeat the same code for initializing events in several different
functions but put it in a helper InitGestureEvent() function and just
call it from the event-specific handlers.
Document that the users of this class always must call IsOk() first, as
they already do, and remove the checks for ms_gestureSymbolsLoaded and
calls to LoadGestureSymbols() from all the other methods, which are
unnecessary in this case.
This shouldn't be needed any more, after the previous commit which
replaces the raw pointer to the focused child in wxTopLevelWindowMSW
with a safe weak reference.
WM_CONTEXTMENU message is generated directly by the system when the user presses and releases the VK_APPS key so there is no need to do this by emulating right mouse button click.
Closes#17969.
Some current input processing flags, like DLGC_HASSETSEL, should be retained because they are in use (in wxWindowMSW::SetFocusFromKbd() for instance).
Closes#17945.
Adjust the size and position we're about to set before comparing them
with the current ones, otherwise the result of the comparison could be
wrong when width and/or height are -1.
See #17075.
The symbols in question are present at least since XP, and most of them since
Windows 2000, so remove preprocessor checks for them, they shouldn't be needed
when any remotely current compiler/SDK.
This is not necessary any longer, we don't support Windows CE any more and
these constants are available since Windows 2000 in the desktop Windows SDKs.
This method allows to use the Windows class to use for the window being
created instead of always using "wxWindow" or "wxWindowNR".
This can be useful to make it possible to handle some windows specially from
outside the application, e.g. use specific class names for accessibility
purposes as will be done by the next commit.
Determine which class name to use in MSWCreate() caller instead of doing it
partly there and partly in MSWCreate() itself, which used to add the "NR"
suffix if necessary -- now it doesn't do this any more and just really created
the window using the given class.
No real changes, just prepare for future enhancements.
If the position changed but the size didn't, we just call Win32 API for
updating the window geometry but it didn't generate WM_SIZE in this case, so
even when wxSIZE_FORCE_EVENT was used, no wxSizeEvent was sent.
Toplevel windows use their parent's coordinate system as the reference
frame, not desktop's, so need to be adjusted accordingly if its
mirrored. Without these changes, default-positioned wxDialogs would end
to the right side of the parent window's right border (instead of being
slightly inside the window) and changing their size would move them as
well.
To correctly compute the brush origin offset for painting background of a
child in a window using RTL layout, we need to offset it by the child origin
i.e. its _right_ top corner in this case and not the left top corner as we did
before.
Conveniently, although not very explicitly, MapWindowPoints() already takes
care of this for us if we just pass it both the left and right points, but we
wrongly passed it only a single one, so it couldn't work its magic in this
case.
Change this to fix the drawing artefacts which appeared over wxNotebook
children with transparent background (e.g. wxStaticText) due to the use of
wrong origin before.
Don't define BeginRepositioningChildren() and EndRepositioningChildren() at
all in this case instead of defining them as "do nothing" functions because
BeginRepositioningChildren() still needs to return a bool, so the old code
didn't compile and we would need to add another "#else" to fix this -- instead
make it simpler by just not compiling at all in this case.
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.
