This was useless as wxCompositeWindow, from which the generic
wxSearchCtrl derives, already sets focus to its first child and, since
the last commit, even harmful as it now resulted in calls to SetFocus()
from inside wxEVT_SET_FOCUS handler which is forbidden at least under
MSW.
See #15569.
wxCompositeWindow already connected to child wxEVT_KILL_FOCUS events and
generated the same event for the composite window itself, but didn't do
it for wxEVT_SET_FOCUS, resulting in not getting these events for the
main window as expected. E.g. this resulted in never getting any
wxEVT_SET_FOCUS events for wxSearchCtrl when using its generic version
(i.e. not under Mac).
Fix this by connecting to wxEVT_SET_FOCUS events for the children too.
Note that this relies on having a correct "previously focused window" in
these events, if this doesn't work reliably for some ports, we might
need to maintain a "bool m_hasFocus" field in wxCompositeWindow itself
instead.
Also note that we might avoid having all this code in wxCompositeWindow
if we translated the underlying native focus event to wxFocusEvents for
both the real window and its GetMainWindowOfCompositeControl() if it's
different. This could potentially be simpler and would definitely be
more efficient, but would require more changes.
Closes#15569.
wxMediaCtrl doesn't compute its best size correctly until a video is
available and this resulted in using the best size of (0, 0) for it and
nothing being shown at all on the screen, even after starting to play a
video.
This is almost certainly a problem on its own, as there is some existing
code for updating the best size and redoing the layout of the parent
sizer when a new video is loaded, but for now just make the control
visible in the sample again by always expanding it to fill up all the
available size, as this is the smallest possible fix and this is how it
used to behave before, until 9aaa38c7c8,
which allowed to meaningfully use wxALIGN_CENTER_HORIZONTAL and wxEXPAND
together: until then, this didn't work at all, but the sample still used
wxALIGN_CENTER_HORIZONTAL by mistake, so just remove it now to restore
the original behaviour.
Closes#17917.
ProcessPendingEvents() was never called when using MFC event loop,
meaning that queued events were never processed, so that using
CallAfter() didn't work.
Fix this and also ensure that these events are processed soon enough by
also implementing WakeUpIdle() for such applications, as wxWakeUpIdle()
didn't do anything neither for them.
Check whether wxTextCtrl has focus using Win32 ::GetFocus() instead of
by comparing FindFocus() with "this" pointer, as the latter fails when
wxTextCtrl is part of a composite control, such as wxSearchCtrl.
This is enough to make pressing TAB in wxSearchCtrl correctly go to the
next control instead of just beeping.
Note that we could also use DoFindFocus() here, but this would be
needlessly less efficient as we don't really need to find wxWindow
corresponding to the focused HWND, as that function does. But we can't
use HasFocus() here as it wouldn't work correctly here when the focus is
on another sub-window of a composite control also containing this
wxTextCtrl.
wxSearchCtrl never generated this event, at least under MSW, even though
the code to forward it from wxSearchTextCtrl was present in it, because
it was never generated in the first place without wxTE_PROCESS_ENTER.
Fix this by simply always using this style in wxSearchTextCtrl.
Fix a trivial "TODO" remaining from 2.8 days and declare the functions
that are part of the public control API as pure virtuals in the base
class.
No real changes.
In a twist on the usual theme, the previous commits broke the Unix build
when _using_ PCH because wx/textcompleter.h was only included from
inside "#ifndef WX_PRECOMP" check, but it needs to be always included as
wx/wx.h doesn't include it.
Call DoUseCustomAutoComplete() function instead of using an artificial
event.
Also move the menu item in the radio group with the other
autocomplete-related commands as it's exclusive with them.
Don't do it only when the text entry is (or becomes again) empty, this
breaks dynamic completers such as the one used in the widgets sample,
which determines its completions depending on the already entered text
(of course, the sample example is not particularly useful, as the
completions are always the same, but it's supposed to show that they
could dynamically depend on the already entered part of the string).
Doing two different things in the same class, using m_isDynamicCompleter
to determine which kind of completion is used, was not very clear, so
create two simple classes each of which does one and one thing only and
create the one we need in wxTextEntry methods.
Note that wxTextAutoCompleteDynamic can assume to always have a valid
wxTextCompleter as otherwise no wxTextAutoCompleteData is needed at all,
which results in more simplifications.
There should be no changes in behaviour.
There should be no need to handle this class specially and it's supposed
to be just an implementation detail, so don't add any dependencies on it
(if it's really important to optimize for this case, the check should be
done for wxTextCompleterSimple and use wxRTTI as wxWidgets still
supports being built without standard C++ RTTI).
This function was now used only once and it's not really useful to have
a trivial wrapper around the corresponding GTK+ function, just use it
directly.
The new function both sets the new model and calls
gtk_entry_completion_complete() instead of always doing first the one
and then the other: if both calls needs to always be done together, it
makes sense to have a function doing both of them.
Use factory function instead of ctor and IsOk() check, as this
simplifies the code using this class: if factory function fails, it can
just return NULL, which is what the caller used to do explicitly after
freeing the new object before.
Also don't assert if there is no associated GtkEntry, AutoComplete() is
supposed to just return false if using it with the given control is not
implemented under the current platform.
Provide an accelerator for the menu command which contains all of the
test functionality to make it simpler to test it.
Also use CreateButtonSizer() instead of creating wxStdDialogButtonSizer
manually to make the code shorter and to also ensure that the "OK"
button is correctly set up as the default one, allowing to press "Enter"
in this dialog to accept the entry on any control, which didn't work
before.
This allows to avoid initializing the variables to 0 in all the
overloaded ctors: wxSize default ctor already does it.
It's also more convenient to use GetScaledSize() rather than assigning
m_width and m_height separately, even if the rest of the code is broadly
unchanged.
We can reuse another ctor taking wxWindow* instead. Although this does
require an ugly cast, it's more explicit than just passing 0 which
could, in principle, match both the ctor taking wxWindow* and another
one taking double, and so is still preferable.
This is similar to the previous commit and is done for the same reasons:
screen DC needs to use the same DPI as the screen itself, instead of the
default Cairo 72 DPI.
For wxDC associated with a window, such as wx{Window,Client,Paint}DC,
this method should return the window PPI, not the hard coded 72 DPI of
Cairo graphics context.
This still doesn't work correctly when using multiple monitors with
different DPI settings, but is still a (modest) improvement.
Recent sorting-related changes resulted in calling FindNode(), which
can only be used with the non-"virtual list" models, unconditionally,
after the items values was changed by user, resulting in a crash.
Add the missing IsVirtualList() check and also add a comment explicitly
stating that all code involving wxDataViewTreeNode can only be used
after checking that IsVirtualList() returns false.
Closes#18057.
The comparator used with std::sort() must return true only if the first
item is strictly less than the second one, this is a requirement of the
sorting algorithm and not respecting it results in wrong final order.
See https://github.com/wxWidgets/wxWidgets/pull/642
This reverts commit 1dd102d741 as it
introduced a crash in the same method when using generic wxDataViewCtrl
implementation, e.g. under MSW, and is not necessary to avoid the crash
with wxGTK3 any longer after the few previous commits.
