For some reason, 7f10d1fa8a handled
wxSYS_CARET_ON_MSEC and wxSYS_CARET_OFF_MSEC differently in wxGTK, even
though it looks like they should be handled in exactly the same way.
Change the code to do this, which results in returning 0 for the former
setting if the caret doesn't blink at all, just as was already the case
for the latter one.
See https://github.com/wxWidgets/wxWidgets/pull/1285
See #17629.
The documentation stated that (a) wxSYS_CARET_{ON|OFF}_MSEC settings
were not supported on MSW and (b) if a setting was not supported a
negative value was returned. However, when calling
wxSystemSettings::GetMetric(wxSYS_CARET_{ON|OFF}_MSEC), not only the
method asserted but 0 was returned instead of a negative value.
Fix this by using the value returned by ::GetCaretBlinkTime() for
wxSYS_CARET_{ON|OFF}_MSEC.
The documentation for wxSYS_CARET_TIMEOUT_MSEC does not list any
platform limitations; however, attempting to obtain this value resulted
in an assert and 0 returned. Fix this by returning -1. Returning -1 may
not the be the ideal solution, but there is no value reserved for the
setting not being supported and the caret on MSW usually blinks.
Closes https://github.com/wxWidgets/wxWidgets/pull/1285
This removes irregular behaviour in setting the label of a control. Creating
a control with label now behaves the same as setting or changing the label
later on. And behaves the same as for other tools in the wxToolBar.
Closes https://github.com/wxWidgets/wxWidgets/pull/1289
Under GTK+ 3 wxSpinButton (being a part wxSpinCtrl editor) is always
displayed horizontally and its minimal width is greater than 18 pixels
so its best width has to be left unmodified and we can only attempt
to fit its height to the height of the wxSpinCtrl property cell.
For other ports wxSpinButton can be displayed vertically and scaled as
necessary.
Closes#18385.
Don't assume that all the items (except for the controls) have the same
size in wxToolBar::DoGetBestSize(), this is manifestly not true at least
for the separators and resulted in too much space left over at the end
of the toolbar.
DoGetBestSize() mistakenly added extra (half of) padding for each tool
explicitly when the padding is already taken into account of by
GetToolSize() itself, so this resulted in extra space at the end of the
toolbar proportional to the number of buttons in it.
Commit 58d4b0e209 introduced a regression:
if a previous popup still existed when the new one was shown, dismissing
the second popup would result in the owner window losing its "active"
appearance.
This was due to the fact that ::GetActiveWindow() still returned the
former popup when it was about to be dismissed, so it was too early to
call it in WM_NCACTIVATE handler. Do it now in DismissOnDeactivate()
itself which is both simpler and more correct.
Avoid allocating too much space to the control in the toolbar, it may
have been made smaller than its best size on purpose and, in any case,
we don't resize the control, so it's useless to allocate more space to
it than it's going to use.
See #18294.
Only invalidate display cache when something related to the displays has
changed and not whenever any system option has.
This should avoid completely unnecessary refreshes when a UAC prompt is
shown, for example: even if doing this works now, after the previous
commit, we still don't have to do it at all.
Passing screen HDC to EnumDisplayMonitors() doesn't work if we do it
while a UAC prompt is shown or during log-off process, so change the
code enumerating the displays to use monitor-appropriate HDC instead.
This fixes the problem with losing display information entirely if
WM_SETTINGSCHANGE was generated when showing UAC prompt, as it happens
when "automatic background color" option is set under Windows 10.
wxEVT_DISPLAY_CHANGED notifies not only about the change of resolution
of a display, but also about removal or addition of a new display, so we
need to completely repopulate the notebook showing the displays on
receiving it.
wxDisplay::InvalidateCache() does the same thing this function does, so
just remove it to avoid confusion.
This also allows to get rid of ms_factory duplicating the factory
pointer stored at wxDisplay level.
See https://github.com/wxWidgets/wxWidgets/pull/1281
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