Call wxSelectionStore::OnItemsInserted() explicitly instead of just using our
UpdateCount() to update the count of items managed by the selection. This
needs to be done to ensure that the newly added items have the correction
selection, i.e. are always unselected, as previously this wasn't the case: if
wxSelectionStore was in the "selected by default" state as it happened e.g.
after selecting all the items in the control, the new items also ended up
being selected.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78364 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The number of items managed by selection was first decremented by our own
UpdateCount() and then, again, by an explicit call to wxSelectionStore::
OnItemDelete(), which resulted in the selection ending up in an invalid state.
Fix this by not calling UpdateCount(), and hence wxSelectionStore::
SetItemCount(), at all, just OnItemDelete() is enough.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78363 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
At least since the changes of r44456 (see #8378), minimal size specified in
the XRC for unknown controls didn't have any effect as it was set on
wxUnknownControlContainer itself and was overridden by the subsequent call to
SetSizerAndFit() which reset the minimal size to the best size of the control
contained in it, meaning that it was impossible to make this contained control
bigger by specifying min size greater than its best size in the XRC.
Fix this by honouring both the min size of the container and of the control
contained in it (and do the same thing for the max size for good measure).
To avoid not totally obvious interaction of overriding GetMinSize() and
DoGetBestClientSize() with sizer code, also position the child control
manually instead of using a sizer for it, it's an overkill for such a simple
case anyhow.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78359 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This control doesn't react to the keyboard at all if it doesn't have a current
row and as it doesn't have it initially, it means that there is no way to do
anything with the control without clicking it with the mouse first.
Fix this by giving it a current row, if possible, whenever it gains focus.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78358 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
Using a clone of event (with PG id) instead of replacing id in the currently processed event coming from wxPGTextCtrlEditor seems to be less intrusive and safer action.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78328 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
When in wxPropertyGridManager::ReconnectEventHandlers() new window ID is the same as old window ID then there is no need to do anything with handlers. An assertion warning is displayed in this case to notify about this unusual (and maybe unintended) situation.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78321 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
First, don't add any events at all to it unless it's empty. Second, post new
events with low priority instead of high one, we really don't care about them
getting processed, other, real, events should take priority.
Closes#14256.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78319 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't prevent people from using hints in wxMSW and wxGTK2, where they work
with multiline text controls too, even though they do not work with wxGTK3 nor
wxOSX.
Closes#14456.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78316 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Second click can result in a double click event instead of the usual simple
click if it happens quickly enough after the first one, so handle double
clicks in the same way as simple clicks instead of ignoring them.
Closes#16551.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78314 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
m_qtWindow should be used instead of m_qtMessageBox (removed). If not, PostCreation() cannot call wxMessageDialog::GetHandle() as it is virtual (and it is called from the ctor), so it fails to set the base window pointer, raising a SIGSEGV in wxWindow::DoSetSize (for more info, see architecture in docs)
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78312 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Using Apple key here under Mac was unexpected, we should use Cmd which
corresponds to Ctrl used under the other platforms and which is already mapped
to it by wxKeyboardState::ControlDown().
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78303 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Check the type in one place only, before calling MacRender() instead of doing
it in each and every implementation of it.
Also replace wxFAIL_MSG() with wxLogDebug() as the former resulted in a crash
due to assert reentrancy, as usual when asserting inside a wxEVT_PAINT handler
which is constantly called all the time, and so wasn't particularly useful.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78295 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Make wxGTK consistent with the generic version and, generally speaking, more
reasonable by allowing to leave any cell empty by just not filling in the
wxVariant in the model GetValue() for it.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78293 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The type mismatch between the value returned from the model and the one
returned by the control cannot be due to any user action, so it is quite
useless to show it to the user, it is only relevant for the developers.
Use wxLogDebug() and not wxASSERT() because asserting in a wxEVT_PAINT
callback would result in a crash due assert reentrancies.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78292 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This was already the case in the native GTK (possibly unintentionally) and OS
X (because vertical alignment is not supported at all there) versions, but in
the generic version using the default wxALIGN_NOT alignment when calling
wxDataViewCtrl::AppendXXXColumn() methods resulted in top-aligned text which
looked ugly (this could be seen on the second page of the dataview sample for
example).
Fix this by handling wxALIGN_NOT as wxDVR_DEFAULT_ALIGNMENT in these functions
to do the right thing by default.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78290 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Make the code more maintainable by using helper functions instead of
duplicating the same logic a dozen times for each of appending and prepending.
This is just a refactoring, no changes in behaviour.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78289 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The entire event handler should arguably be removed entirely if it's unused,
but for now just avoid the warning.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78286 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxMOD_ALTGR is wxMOD_ALT + wxMOD_CONTROL and so is, actually, supported as
simulating it involves only simulating both Alt and Control being pressed, at
least under MSW.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78283 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Forcefully closing a modified document misbehaved in several ways: first, the
question about whether the document should be saved was asked twice if the
first message box was cancelled. Second, DeleteAllViews() didn't actually
delete the views if the second message box was cancelled as well -- so the
views could be left alive while their associated document was destroyed,
resulting in more or less guaranteed crash (e.g. during the next event
handling as wxDocChildFrameAnyBase::TryProcessEvent() assumes that
m_childDocument is still alive if m_childView is).
Fix both problems by really forcing the document to close by pretending that
it is not modified.
We still ask the user once though, as it could be useful to be able to save
the document even when it will be closed. Ideally, the message box shown in
this case shouldn't have a "Cancel" button at all, but this is left for the
future.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78282 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
