IsDirty() still returned true even after undoing all the commands which was
wrong, as there was nothing to save in this case.
Closes#15722.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75310 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Disable setting focus in response to TVN_SELCHANGING when deleting an item in
a single selection control too -- this was already done in multi selection
case but not in this one, for some reason.
Also refactor the code to avoid duplicating TreeView_DeleteItem() calls.
Closes#15721.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75308 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
If the application launches while the parent process doesn't have an active
window, [NSApp run] won't terminate immediately, as was assumed here. Instead,
it blocks until some input arrives, e.g. clicking the Dock icon.
Work around this by adding a dummy event to the queue.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75302 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxMenu::Remove() was still broken in wxMSW after r75250, even with the fix in
r75290, as wxMSW code relied on the item still being present in
wxMenu::m_items.
Delay removing it from there until after DoRemove() call to fix this.
See #3424.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75297 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The menu items were not removed from the menu any longer when they were
deleted or destroyed after the changes in this revision.
Fix this by calling the public Remove(), which does the right thing, instead
of the private DoRemove(), which only does part of the job of removing the
item, in DoDelete() and DoDestroy().
See #3424.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75290 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Subsequent calls didn't initialize the hidden window correctly because
wxSocket::Shutdown() unregistered the window class used for it, but
wxSocket::Initialize() still kept a pointer to the previously registered class
name.
Don't remember it any longer, unlike in the other cases where we use
wxCreateHiddenWindow(), this function is only ever going to be called once
until the class is unregistered anyhow, so it doesn't have to be static.
Closes#15701.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75287 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This code probably misunderstood NSEvent documentation, where this mask is
mentioned, but setKeyEquivalentModifierMask: documentation doesn't list it as
allowed. More importantly, it causes "fn" to appear in the menu item and the
accelerator doesn't work.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75276 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Undo the change introduced, probably accidentally, by r11369 (12 years ago)
and skip the default handling of all events except wxEVT_SIZE and wxEVT_PAINT,
which are special for the reasons explained in the comments in the code, if
the user code has already handled the event.
This allows to customize scrolling by selectively handling some scrolling
events only and generally makes sense.
Closes#15684.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75252 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The assert complained about a bug in wxMenu code itself, but actually could be
triggered by simply trying to remove a non-existent item from the menu.
Fix this by checking for the item existence, and also removing it from the
internal menu data structure, in wxMenuBase::Remove() and only dealing with
the item itself in DoRemove().
Closes#3424.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75250 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use wxUIntPtr, not long, and SetItemPtrData() instead of SetItemData(), to
ensure that we preserve the values of client data pointers in 64 bit build,
otherwise they were truncated to 32 bits.
Closes#15687.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75248 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
When setting a new "Window" menu (as opposed to just modifying the existing
one which did work correctly), we shouldn't show it immediately in the menu
bar if there are no MDI children, this results in wrong UI and assert
failures.
Closes#15663.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75242 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Account for the "Window" menu (and any other foreign windows lurking in our
menu bar) correctly in wxMenuBar::Insert() instead of the old code which
apparently tried to do something similar but didn't make much sense and didn't
work when trying to insert the menu at the position actually occupied by the
"Window" menu in the menu bar.
Closes#15662, #1732.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75241 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The code didn't follow the golden rule of localization and broke
user-visible string into separately translated substrings. Replace with
the same _("About %s") string already used in wxAboutDialog.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75230 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Have just one copy of the code, instead of two. Eliminate differences
between the two versions. As a result, applications now properly have
preferences and about items even if window-less.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75229 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Still allow to use TAB for navigation even when a wxComboBox has
wxTE_PROCESS_ENTER style.
Use the same hack for wxTextCtrl, i.e. implement the navigation ourselves as
we can't let IsDialogMessage() handle it but still get VK_ENTER key presses.
Closes#12808.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75210 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
For some reason SetOwnForegroundColour() was used, but we really need to set
the colour of the child text control and not our own colour here (which is not
used for anything).
This makes the text visible even when using non default tooltip colours, which
could previously result in black-on-black text.
See #15671.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75207 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This was broken because Select() never returned wxSOCKET_CONNECTION_FLAG which
is supposed to be set when a connection is accepted.
Closes#15669.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75205 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The code didn't properly account for the possibility of wxEVT_KILL_FOCUS
handler deleting the focused window (as happens e.g. in wxListCtrl inline edit
controls). E.g. rapidly clicking wxEditableListBox buttons could trigger a
crash here when sending wxEVT_SET_FOCUS to an already-deleted window.
Use wxWeakRef<> to check if the window is still alive.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75199 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We didn't repaint the owner drawn combobox items any more because they were
not found by MSWFindItem().
Fix this by restricting the check to the real windows with the same ID as the
combobox, not the dropdown items which are not windows at all.
See #15674.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75196 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The recent changes to mouse wheel scrolling broke it for the generic
wxListCtrl and probably any other situation in which scrollbars don't scroll
the window itself but some subwindow of it. In this case, the scroll wheel
event handler doesn't have any scrollbar to adjust, so it simply does nothing
and shouldn't return true, as it did since r74911.
Just return false in case we are not doing anything to let the mouse wheel
work as before.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75191 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxDataViewCtrl should behave as Explorer does on Windows: when an inline
editor control is open, clicking outside of it should close the editor
(preserving changes) in most cases - as a rule of thumb, when the
subsequent action could interfere with the editor somehow.
This was implemented by watching for focus change and so ignored clicks
made on non-focusable controls outside of wxDVC's main window area. In
particular, clicks on the list's header were ignored, even though they
could result in modifications of the editor's position or size.
Don't finish editing when the user right-clicks on the header,
consistently with Explorer. Opening the menu likewise still doesn't
finish editing, it is needed for access to editing operations.
Fixes#15152.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75184 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Implement the behavior that Explorer uses: if the column is too narrow
to fit the current text of a cell into it, don't create a too-small text
control for it, because it is annoying and confusing (typically, the
beginning of the text would be hidden, which is disastrous if it happens
to contain numbers). Instead, grow the text control to be larger than
the column for more comfortable editing.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75183 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
