In wxUniv wxComboBox does derive from wxComboCtrl, but its wxRTTI
doesn't use wxComboCtrl as the base class for consistency with the other
ports, meaning that wxDynamicCast() to wxComboCtrl fails.
Avoid this problem by storing wxComboCtrl in wxComboPopupWindow, as then
we can just use it later without any casts -- at the price of storing an
extra pointer in a transient object, i.e. without any real cost.
See https://github.com/wxWidgets/wxWidgets/pull/2418
This seems to work fine with current version of wxPopupTransientWindow
and wxPU_CONTAINS_CONTROLS style and allows to drastically simplify the
whole mess of preprocessor checks in wxComboCtrl code, reducing the
logic to just 2 cases: either wxUSE_POPUPWIN == 1 under any of the major
platforms and then we use wxPopupTransientWindow or wxUSE_POPUPWIN == 0
or we use some other platform and then a TLW-based fallback is used
instead.
In spite of the amount of changes, this should only modify behaviour
under MSW where wxPopupTransientWindow is used now instead of whatever
was used before.
Simplify the code by removing TEXTCTRL_TEXT_CENTERED, it was only set to
1 for "other" (i.e. not one of the main ones) platforms and if it's
really a problem for them, which is not even certain, the solution is to
fix them rather than to uglify common code.
This is not as much of a simplification as the previous two commits
because there is no simple replacement of EVT_MOUSE_EVENTS() using
Bind() and a loop over all mouse event types has to be written
explicitly, but it still avoids the need to allocate and delete a
separate object, so is still worth it.
There is no need to use a separate wxEvtHandler here when we can just
use Bind() to directly handle the child text control events in
wxComboCtrlBase itself, this code was a left over from pre-wx3 days.
No real changes, just make the code simpler and smaller (and also
marginally more efficient at run-time).
This function was always called after calling CreateTextCtrl() and
couldn't be called at any other moment, so it didn't make much sense to
have it as a separate function, just install the custom input handler
when (re)creating the text control.
This simplifies the derived classes code.
This should have been done together with the changes of 41410610ef
(Don't force wxPU_CONTAINS_CONTROLS on wxPopupTransientWindow,
2020-07-10) as without this style controls inside wxComboPopup couldn't
accept focus any more, which broke the previously working code.
Commit 70e9dbd756 has fixed#18394 but unfortunately it also caused several other issues observed e.g. in #18540. Apparently wxComboCtrl doesn't fit well to the wxCompositeWindow framework - especially when wxCB_READONLY flag is set and there is no main editor control what is problematic for wxCompositeWindow implementation. At the moment it is more pragmatic to go back to the original wxComboCtrl concept as a plain compound control to fix the regression and try to fix#18394 in an alternative way.
Closes#18540.
See #18394.
wxComboCtrl consists of several controls (text entry, button, popup) and therefore should be implemented as a wxCompositeWindow to prevent problems with generating spurious events when e.g. focus is transferred between the sub-controls.
Closes#18394.
Even though both MSVC and gcc seem to silently ignore everything coming
after "#endif", it's still wrong to have anything but a comment after
it.
See commit 881aabf63e
When wxComboCtrl popup window is dismissed we need to hide it but calling ShowWindow() Win API directly from WM_ACTIVATE event handler causes some side effects like calling the handler again (under Win 7) or setting the focus improperly (under Win 10). To avoid these problems we should postpone hiding.
Closes#18376.
Under wxMSW this method is re-entered due to triggering EVT_ACTIVATE when EVT_LEFT_UP is being already handled.
We need to prevent this to avoid generating spurious EVT_TEXT events and raising errors on calling SetFocus().
Closes#18260.
This prevented TAB navigation from doing anything at all when the focus
was on wxComboCtrl in wxGTK and, probably, all the other non-MSW ports
(in wxMSW TAB navigation happens before normal key processing, so this
check was irrelevant there).
Position of the combo box editor associated with properties having custom
bitmaps like e.g. ColourProperty, needs to be adjusted in order to display
edited text at the same position as the text which is displayed as
a property value prior to the editing.
Position of the combo box editor associated with properties having custom
bitmaps like e.g. ColourProperty, needs to be adjusted in order to display
edited text at the same position as the text which is displayed as
a property value prior to the editing.
Connecting to wxEVT_TEXT_ENTER is not necessary if wxTE_PROCESS_ENTER style is
not used was always useless and is actively harmful since the changes of
5591a20093 as it results in an assert failure
now.
Just don't do it unless we really want, and will get, these events.
Positioning wxComboCtrl and wxTextCtrl or wxComboBox in the same column should
align their left borders, but it didn't because of an extra offset for the
focus ring used for wxComboCtrl only.
We need to either apply this offset to all controls or none of them, so remove
it from this one.
Closes#15017.
Windows CE doesn't seem to be supported by Microsoft any longer. Last CE
release was in early 2013 and the PocketPC and Smartphone targets supported by
wxWidgets are long gone.
The build files where already removed in an earlier cleanup this commit
removes all files, every #ifdef and all documentation regarding the Windows CE
support.
Closes https://github.com/wxWidgets/wxWidgets/pull/81
This fixes wxComboCtrl compilation with wxUSE_LONGLONG==0 as wxMilliClock_t is
always mapped to the proper base type and hence can be used even if wxLongLong
type is not defined.
See #16939.
Make overriding virtual methods more explicit and enable additional checks
provided by C++11 compilers when "override" is used.
Closes#16100.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76173 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
r72935 introduced code that created a temporary wxComboBox control to
take measurements. This is very expensive in MSW and adds noticeable
delay when creating more than a few controls.
Replace with equivalent wxMSW code that computes the height in the same
way other wxMSW controls do.
The wxGTK version cannot be eliminated in the same way, so at least add
some basic caching there. It's much less of a problem, because GTK+
controls creation is much cheaper than MSW one.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74658 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This keyword is not expanded by Git which means it's not replaced with the
correct revision value in the releases made using git-based scripts and it's
confusing to have lines with unexpanded "$Id$" in the released files. As
expanding them with Git is not that simple (it could be done with git archive
and export-subst attribute) and there are not many benefits in having them in
the first place, just remove all these lines.
If nothing else, this will make an eventual transition to Git simpler.
Closes#14487.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74602 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
