There were at least 2 problems when showing a transient popup while
another one was already shown in wxMSW, as could be seen by showing
several wxRichToolTips in a row from a timer event handler, for example:
First problem was that wxCurrentPopupWindow was incorrectly reset in
this case by the old popup window when it was hidden, even though it
should have been remaining set to the new popup window. Fix this by
checking that we only reset wxCurrentPopupWindow when hiding the popup
if it still points to this popup, but not if it has been changed to
point to another one in the meanwhile.
Second problem was more mysterious and resulted in simply not receiving
the activation events for the new popup when showing it resulted in
hiding the previous one. The working hypothesis is that hiding a window,
which changes activation on its own, from WM_NCACTIVATE handler in our
code confused ShowWindow(), which handles switching activation, which
didn't expect this to happen, so the fix is to avoid doing anything
immediately from this handler and wait until the next idle event to do
it instead.
These fixes ensure that showing several popups in a row works correctly,
i.e. hides the previous popup when a new one is shown and also keeps the
parent window appearing active during all the time and deactivates it if
the focus switches to another top level window at the end.
Information about display cached in wxDisplayFactory::m_impls and in
wxDisplayFactoryMSW::m_displays could get out of sync after removing a
display from the system, resulting in failures when calling various
wxDisplay functions later.
To fix this, reuse InvalidateCache() to invalidate the cache in
wxDisplayFactoryMSW too, making it virtual in order to allow overriding
it there. Also call InvalidateCache() from wxDisplayFactoryMSW itself
instead of doing it from wxWindow, as this works even when the
application isn't showing any windows (and also keeps all
display-related code together).
Closes https://github.com/wxWidgets/wxWidgets/pull/1246
In InsertColumn(long, const wxListItem&) a line was split inside a
referred overloaded method signature which prevented doxygen to
recognize and link the referred method.
In InsertColumn(long, const wxString&, int, int) non-existing
Insert(long, const wxListItem&) overload was referenced instead of
InsertColumn(long, const wxListItem&).
Clsoes https://github.com/wxWidgets/wxWidgets/pull/1279
This commit partially reverts 17055fb8c6
which resulted in asserts when destroying dialogs with buttons, one of
which had focus, see https://github.com/wxWidgets/wxWidgets/pull/1245
This happened because wxGetTopLevelParent() returns NULL when the parent
TLW was already half-destructed, resulting in an assert, while the
original code still returned NULL in this case, but did it silently,
which is the right thing to do here as we can't avoid being called
during the parent TLW destruction.
Closes https://github.com/wxWidgets/wxWidgets/pull/1268
Reset the number of buttons to skip deleting the old buttons in
wxToolBar::Recreate() as these buttons don't exist any more (having been
created in the old control) and trying to delete them just results in
debug error messages from TB_DELETEBUTTON.
Recreating the toolbar tried to offset the new toolbar window being
created by the size of the existing toolbar, when it was set up as the
main frame toolbar. Luckily, this didn't work because getting the size
of a wxWindow without a valid HWND failed, but it resulted in debug
warning messages and was a wrong thing to do in the first place.
Fix this by hiding the old toolbar before destroying it, this suffices
for the parent frame not to use it for the client area calculations.
If neither main widget nor connect widget is focusable (which notably
happens when they're the same anyhow, as is the case for wxChoice, for
example), still use the main widget as mnemonic instead of not using any
mnemonic at all.
This fixes activation of a wxChoice preceded by wxStaticText by pressing
the key combination corresponding to the label mnemonic, which didn't
work previously.
Due to a wrong "else" in RealizeTabOrder() implementation, we could set
the mnemonic widget for a previous widget using mnemonics (i.e.
wxStaticText or wxStaticBox) rather than the one closest to the actual
control activated by the mnemonic.
This truncates the control with GTK+ 3 where 40 or 60 pixels is never
enough for its width (even without speaking about high DPI displays) and
results in tons of GTK+ warnings.
This is a minor optimization and can significantly reduce flicker in a
not uncommon case when SetCellValue() is used to refresh all or many of
the grid cells if only few of them actually change.
See #9717.
Closes https://github.com/wxWidgets/wxWidgets/pull/1276
Don't assert in wxBoxSizer when both alignment flags and wxEXPAND are
used together if wxSHAPED is also used, as such flag combinations may
make sense and so shouldn't be forbidden.
Add a unit test checking that this is allowed.
Since 0185d61a2c wxToolBar height is
increased if the controls don't fit in it rather than decreasing the
size of the controls, which results in different appearance than in the
previous versions, so document this as well as the advice for restoring
the old behaviour.
This wastes less space in the toolbar and looks better and is more
compatible with 3.0 (although not totally so, but this is intentional
as 3.0 didn't use any margins at all, which looked bad).
Resetting the insertion point position to 0 after calling
wxTextCtrl::SetValue() or ChangeValue() which didn't really change the
control contents was unexpected, as such calls are supposed to be
"optimized away", and this was indeed the case under wxMSW and wxOSX,
but not in wxGTK.
So change wxGTK to follow the other ports, add a unit test checking for
this behaviour and officially document it.
As a side effect, this ensures that the numeric validator classes don't
reset the insertion point position to 0 on every focus loss under wxGTK,
as happened before.
This works around gcc -Wredundant-decls warning that was given (if
explicitly enabled) when both wx/vector.h and wx/utils.h were included.
The workaround is ugly, but it doesn't seem worth it to introduce a
separate wx/qsort.h header just for this single function, which seems to
be the only other way to fix this.
Closes https://github.com/wxWidgets/wxWidgets/pull/1271
Even if it's not supposed to do anything, avoid calling
wxTextCtrl::ChangeValue() completely if the text contents doesn't
actually change. This should be slightly more efficient and avoids any
chance of bugs such as the one resulting in the insertion point being
still moved to the beginning of the text even if it doesn't change in
wxGTK currently (see https://github.com/wxWidgets/wxWidgets/pull/1270).
With wxSTC, popup autocompletion lists and call tips need to be able to
show their information and respond to mouse clicks, but should never
take focus from their parent STC. This test verifies that these popups
function in this manner.
The AutoCompUseListCtrl method can be used to make an autocompletion
list look like it's being shown with a wxListCtrl instead of a
wxListBox. When this style is used, the list will have hot tracking.
On MSW, the colours will also be slightly different.
With some system themes, the default colors used for a list box can be
hard to read or otherwise unsuitable for use with an autocompletion
popup. This method lets a user manually specify colours for the list
box’s background, text, selection background, and selected text.
When switching between call tips in MSW, there can be a bit of flicker
when the first is closed and the new one is opened. To reduce the
flicker, store the call tip background in a bitmap and use a very brief
fade-in animation when showing the new call tip.
Previously wxSTCListBox was a class derived from wxListView and required
several extra steps to make the control look correct when it lacked
focus. This commit changes wxSTCListBox so that it is a wxVListBox and
is built to always draw itself looking as though it has focus.
In addition this splits the work previously done by ListBoxImpl class
among wxSTCListBox and a newly defined wxSTCListBoxVisualData class.
wxSTCListBox manages the work done by a specific list and
wxSTCListBoxVisualData manages the data common to all lists. All
ListBoxImpl methods now simply forward to a method of one of those 2
classes.
The newly defined wxSTCPopupWindow class has been built to have the
behavior necessary for showing the popup windows used by wxSTC. This
commit uses it as the base class of the window that shows autocompletion
lists.
A recent commit added the file src/stc/PlatWXcocoa.mm needed for wxSTC
with the cocoa port. This commit modifies the build system files to
use this new file when it is needed.
With the cocoa port, wxSTCPopupBase is defined by creating a floating
window using the cocoa api and then wrapping that window in a
wxNonOwnedWindow for use with wxWidgets.
The wxSTCPopupWindow is intended to serve as a popup window for showing
call tips and popup lists with wxSTC. This class is designed to show its
content and respond to mouse clicks, but it should never take focus from
its parent wxSTC. It is built with customizations for wxMSW, wxCocoa,
and wxGTK+ to function in that way.
This adds a demonstration of handling call tip clicks to the stc sample.
Instead of showing a single call tip, 3 different call tips can be
shown. The sample demonstrates how to move between the call tips
depending on if the up or down button was clicked in the call tip
window.
