Homogenize the behaviour of all ports when creating bitmaps with 0 width or
height: just fail always as it doesn't seem to make sense to support this.
Closes#16828.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78434 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use GET_{X,Y}_LPARAM() to extract them from the event position, which handle
negative coordinates (and coordinates can perfectly well be negative when
using multiple displays) correctly, unlike {LO,HI}WORD().
Closes#16812.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78420 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
In our efforts to account for the longest possible string we made the control
too wide by default which didn't look very good, so reduce the amount of space
added to it, this still seems to be (just) enough for all the reasonable date
formats (tested under Windows XP SP3 with default DPI).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78417 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
For some reason, the code only forwarded activation events to the current MDI
child, but not the deactivation ones. And even though this was literally
always the case (the check for the event being the activation one is there
since r9), it is clearly wrong as the focus restoring code in wxTopLevelWindow
in wxMSW doesn't work if the focus hadn't been previously saved.
This fix hopefully completes the changes started by r78340 and r78341 and
ensures that the focus is always properly restored to the last focused window
inside an MDI child.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78361 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
DefWindowProc() never preserves the focused window actually, whether we use
WM_NEXTDLGCTL (which is only handled by DefDlgProc() anyhow) or not.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78360 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxST_NO_AUTORESIZE style only affects whether the control is actually resized
when its text changes, but its best size should always change, so that if the
window containing it is explicitly relaid out the size does change.
Moreover, in wxMSW and wxOSX the best size was never invalidated at all when
the label was ellipsized, so it was never updated for them, preventing, for
example, comparing the best size with the current one to check if the text is
effectively ellipsized (and so needs to be shown in a tooltip, for example).
Fix this by calling InvalidateBestSize() unconditionally, this should make
these ports behave in the same was as wxGTK already did.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78357 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't use the generic focus saving/restoring code for wxMDIParentFrame in
wxMSW as it already saves and restores the active MDI child on its own and we
should let it do it, as our code could change the active child when restoring
focus if it hadn't been saved correctly previously.
The fact that it is isn't saved is another bug, but even if it is fixed, we
should let MSW MDI implementation handle activation as we can't do it any
better -- but can do worse, as the bug described in #16635 shows.
Closes#16635.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78341 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use wxWindow::IsDescendant() instead of wxGetTopLevelParent() to determine
whether the focused window is inside the TLW, as the former works correctly
for any window, including wxMDIChildFrames, while the latter would return
wxMDIParentFrame for them (as MDI children are not considered to be TLWs) and
so saving the focus would always fail and the focus was always restored to the
first child of wxMDIChildFrame after switching from it to another child frame
and back, as could be seen by applying the simple patch:
---------------------------------- >8 --------------------------------------
diff --git a/samples/docview/view.cpp b/samples/docview/view.cpp
index 9f20032..8386522 100644
--- a/samples/docview/view.cpp
+++ b/samples/docview/view.cpp
@@ -160,8 +160,9 @@ bool TextEditView::OnCreate(wxDocument *doc, long flags)
wxFrame* frame = wxGetApp().CreateChildFrame(this, false);
wxASSERT(frame == GetFrame());
m_text = new wxTextCtrl(frame, wxID_ANY, "",
- wxDefaultPosition, wxDefaultSize,
+ wxPoint(5, 5), wxDefaultSize,
wxTE_MULTILINE);
+ new wxButton(frame, wxID_ANY, "Button", wxPoint(5, 100));
frame->Show();
return true;
---------------------------------- >8 --------------------------------------
Notice that the bug usually stayed hidden because it didn't happen if
wxMDIChildFrame contained a wxPanel (which also stores the last focus) inside
it or if the focus switched away from the entire application instead of just
going to another child and back, as in this case the last focus was stored in
wxMDIParentFrame, for which the old code did work.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78340 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Even though this is typically the case, some strings in Windows registry are
not NUL-terminated, deal with them correctly by using the explicit length.
Closes#16719.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78327 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Reverts r78136 (see #15727) because the multi-string values in Windows
registry are actually not "name=value" pairs at all but just NUL-separated
strings and the API provided for reading them was inappropriate.
Also see #16719.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78326 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The flicker was only visible under Windows XP or when using a class theme
and was due to mis-positioning the status bar initially in PositionStatusBar().
Fix this by adjusting its position by the toolbar offset before calling its
SetSize().
Closes#16705.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78325 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
As submenu items don't have a valid ID, we need to address them by their
position when calling EnableMenuItem() -- and for simplicity do it for all the
items.
Closes#16747.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78324 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Make sure to reset the "to be deleted" flag we set on the tool when removing
it from the toolbar to avoid layout problems if the tool is added back later.
Closes#16735.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78279 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This ensures that wxRendererGeneric::DrawGauge() is actually usable as
otherwise calling it always resulted in an assertion failure because it used
DrawTextCtrl() which was not implemented in wxRendererGeneric. So this fixes
using DrawGauge() in non-MSW ports which was added by r77023 (see #16406) but
apparently never worked.
Also remove wxRendererMSW::DrawGauge() as it's exactly the same as the version
inherited from wxRendererGeneric.
Closes#16725.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78278 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Correct the "pushed" state determination in our own drawn code, it didn't work
for wxToggleButton which doesn't return BST_PUSHED from BM_GETSTATE. But it
does have BM_GETCHECK returning its state directly, so add a new virtual
MSWIsPushed() method and implement it differently for it.
Closes#13755.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78251 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Windows doesn't use the correct image for checked disabled tools, at least up
to and including Windows 7, so don't put such tools in the "checked" state at
all: this doesn't matter as they are disabled anyhow, but shows the correct
image for them.
Closes#12989.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78248 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This mechanism is provided as an alternative to specifying MB_RTLREADING
style, e.g. if the source code can't be modified but the [string] resource
from which the message box message is loaded can be. We don't need to do this
if we do add MB_RTLREADING however.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78237 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Add helper wxApp::MSWGetDefaultLayout() static method and use it instead of
wxTheApp->GetLayoutDirection() in wxMSW code.
This serves two purposes: first, wxMessageDialog doesn't crash when it's shown
before wxTheApp is created (or after it's destroyed) any more. And second, we
use the correct layout direction if the main application has enabled it by
calling SetProcessDefaultLayout() or using two U+200E characters in the
beginning of its "FileDescription" resource field by default now.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78236 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
A wxTextCtrl inside an RTL window in an otherwise LTR application should still
be considered RTL, it's not clear at all why do we need to ask the application
for the layout here, so change this for consistency.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78235 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This doesn't make any sense, this function is not related to the owner drawing
code at all and should always be available.
This corrects the changes of r70316, see #13851.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78232 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This assert was triggered after the changes of the previous commit as we can
get WM_MENUSELECT with menu bar handle as parameter from Windows and still
search for the menu with this handle -- and there is nothing wrong with this,
so just return NULL but without asserting in this case.
This corrects the changes of r67355, see #13080.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78231 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
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
If possible, i.e. when running under Vista or later, just ask the control for
its best size instead of trying to approximate it ourselves.
Notice that we still use our own height, to ensure that it's the same as for
the text controls, but it's the width that really counts.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78221 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This fixes the size of wxDateTimePickerCtrl in programs that don't set any
specific locale: previously, the standard "%m/%d/%y" format was used for
computing the best size of the control in this case, but this could have been
significantly shorter than the format actually used (compare with the default
"%d %b, %Y"), resulting in the control contents being truncated by default.
GetOSInfo() is currently different from GetInfo() only under MSW, but we might
need to make the same distinction under OS X too, so do make this function
public instead of keeping it MSW-specific.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78220 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This makes the code slightly simpler (no more need for the scope guard) and
avoids memory leaks when not using wxEntry() (but calling wxEntryStart()
instead).
Closes#16664.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78135 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This ensures that we never forget to delete the handles returned by
GetIconInfo() and also centralizes the error message given if it fails in a
single place.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78132 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
These events are supposed to carry a pointer to the menu which was opened or
closed, but wxMenuEvent::GetMenu() always returned NULL for the menus opened
when a child MDI frame was active, as its menu bar, containing the menu, was
not searched for it.
Fix this by overriding MSWFindMenuFromHMENU() at wxMDIParentFrame level, just
as we already do for FindItemInMenuBar().
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78130 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Add the bitmap margins to the bitmap size, not the total button size.
This fixes the buttons becoming unnecessarily tall as soon as they were
assigned even a tiny bitmap.
Closes#16536.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78127 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is a compromise solution between r78040, which handled monochrome bitmaps
correctly, but broke drawing bitmaps without using their mask, and r78054
which simply reverted it: this version preserves the old behaviour when not
using the mask, but draws at least the shape (if not the colour) correctly
for the monochrome bitmaps.
Notice that this also reverts r78039 which is not needed any more without
r78040.
Closes#16512.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78123 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Calling SetHICON() is not enough, the icon size already needs to be set or,
even better, CreateFromHICON(), which does both atomically, should be used.
Closes#16672.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78116 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
WM_MDISETMENU handler doesn't seem to reset the last error under Windows XP
and this could result in spurious debug error messages when setting the
initial menu in which case NULL is returned to indicate that there was no
previous menu, but this doesn't indicate that an error occurred.
Explicitly reset the last error to ERROR_SUCCESS ourselves before using
WM_MDISETMENU to ensure that the last error can only be set after its return
if it was really done by the code handling it, i.e. if an error really
happened.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78056 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This reverts r78040 (see #16512) as it broke the appearance of the disabled
buttons in MSW toolbars as can be seen in the sample.
The change itself might still be correct and could have just uncovered some
other bug elsewhere, but for now still revert it just to make the toolbars
usable again.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78054 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Include wx/msw/private.h when not using PCH to get wxZeroMemory() (this makes
it unnecessary to include wx/msw/wrapwin.h as it's already included by the
other header).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78049 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This problem was already fixed in r77649 for Windows 7 (and hopefully all the
other supported Windows versions), but it turns out that XP returns a
different error when the association is not found in the registry, so the
debug error message was still given under it.
Fix this by checking for both ERROR_NO_ASSOCIATION and ERROR_FILE_NOT_FOUND.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78048 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
