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.
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
