We reuse the same global dispatcher object (allocated in
wxFDIODispatcher::Get()) for the sockets created in different threads, so it's
perfectly possible for its methods to be called concurrently and this happens
even in our own socket streams unit tests.
Protect against concurrent modification of the select sets and m_maxFD. This
fixes sporadic Travis build failures such as the one at
https://travis-ci.org/wxWidgets/wxWidgets/jobs/110757281 for example and
probably even worse bugs too.
If setting sash position to a value that cannot be satisfied due to
minimum size constraints, wxSplitterWindow would continue endlessly
trying and failing to set it, causing constant CPU use on OS X. This was
because delayed sash setting was invoked from idle handler and if it
failed, the code would repeat the same action again and again.
Instead, perform this delayed setting from OnSize handler. If setting
sash position failed in the first place, it must have been due to too
small size of the window. Therefore it's pointless to try again until
the size changes.
An old check - used for reasons that no longer apply - was preventing
correct rendering of wxToolBar background in wxMSW. Fix this by removing
the obsolete check.
See #9666 for the original reason for the check.
This file was mistakenly removed from the list of wxOSX headers in
602ea92143.
And don't install wx/osx/core/stdpaths.h which doesn't exist any longer (see
abe10b8c00).
Closes#17381.
Ensure that the correct parent is used when no parent is explicitly specified
by calling GetParentForModalDialog().
This generalizes baff0c942b (see #17384) to the
rest of the modal dialogs (wxMessageDialog already did this).
Closes#17146.
Don't optimize the required length as this is a tiny gain resulting in big
problems with the strings containing surrogates for which the actual result is
shorter than the length returned, resulting in extra NUL bytes at the end of
the converted buffer.
This is similar to 3410aa372f (see #16298) but
for UTF-32 and not UTF-16.
Closes#17070.
No real changes, just some cleanup to ensure that the item being edited stored
in wxDataViewRendererBase never refers to an item which is not, actually,
being edited any longer.
Call FinishEditing() when the cell is done being edited instead of sending
wxEVT_DATAVIEW_ITEM_EDITING_DONE event manually from wxGTK code.
This fixes the bug with not being able to edit an item the second time if the
editor was dismissed by GTK+ itself and not by our own code (which already did
call FinishEditing()) as the old editor still remained alive because
DestroyEditControl(), usually called from FinishEditing(), wasn't executed.
It also removes code duplication and avoids the need to keep a global
s_user_data pointer as the item currently being edited is already stored in
wxDataViewRenderer anyhow.
When using a custom renderer, wxEVT_DATAVIEW_ITEM_EDITING_STARTED was sent
twice: once from the generic base class StartEditing() and another time from
the GTK-specific "editing_started" signal handler. And we must send it from
the latter, because otherwise no event would be generated at all for the
standard renderers (i.e. text cells) for which we don't call StartEditing()
ourselves, so don't call it from the former and instead generate the event by
explicitly calling NotifyEditingStarted() after calling StartEditing() in the
generic version (as for wxOSX version, it doesn't use StartEditing() at all
and so doesn't need to be changed).
Reuse the same code from the generic and native GTK and OS X implementations
of wxDataViewCtrl instead of triplicating it.
This fixes a small discrepancy between the wxOSX version, which didn't see the
model pointer correctly in the generated event, and all the others, but mainly
paves way for future improvements.
We need to delete the editor control even if GetValueFromEditorCtrl() failed
as otherwise we're never going to be able to edit another item again, at least
with the GTK native implementation, which does nothing when starting to edit
an item if an editor control already exists.
Use the existing wxRect::Get{Position,Size}() methods instead of explicitly
creating the objects from the wxRect components, this is simpler and more
readable.
No real changes.
Skipping the event is supposed to have the same effect as not handling the
event at all, but in wxMSW wxTE_PROCESS_ENTER style must be specified for a
wxEVT_TEXT_ENTER handler to be executed at all and if this style is used, then
the default handling in MSWProcessMessage() which normally happens before
calling the handler doesn't take place at all.
Work around this by explicitly performing the default "Enter" key action if
the event generated by it wasn't handled to make wxMSW behaviour more
intuitive.
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.
Override newer and more flexible virtual method: this doesn't change anything
yet but will allow to provide default handling for some messages in a single
overridden method in the future commits, when it would have required to also
override MSWDefWindowProc() with the old method.
While Enter and Tab on their own should be used to finish cell editing, the
cell editor itself may want to process key combinations involving these keys
with modifiers, e.g. Shift-Enter, so don't intercept those in at least the
generic version of wxDataViewCtrl to allow catching them in the editor.
This is never going to work, so complain about trying to do it to help with
catching this bug.
This is possible thanks to the new OnDynamicBind() method invoked whenever a
dynamic event handler is bound to a control, so this doesn't detect all
possible occurrences of the bug (such as specifying the handler in a static
event table or in a validator), but it's still better than nothing.
In the future OnDynamicBind() should be extended for other invalid calls, e.g.
binding a handler for wxEVT_TEXT_ENTER to a non-text control shouldn't work
neither, ideally.
Use the same GetParentForModalDialog() method as for the normal dialogs to
find the parent to use for this native dialog and ensure that it is shown
modally even if no parent is explicitly specified when constructing it.
Closes#17384.
