This should be a no-op, as runModalSession's documentation states that
it will handle dispatch event for the modal's window. However, in
practice, it does not seem to be doing so frequently enough for modal
UI to keep up with two-finger scroll events. Dequeuing and manually
dispatching the next event seems to mitigate this.
Note that we only dispatch events that are associated with the modal
dialog's window, or with no window at all, to prevent other windows
from responding to inputs while the modal is present.
Closes#17737
Closes https://github.com/wxWidgets/wxWidgets/pull/365
webkitgtk apparently manipulates our scrollbar GtkAdjustment directly, setting
all members to zero to disable it. Since we never do that, those values were
unexpected. This is a better fix for the problem papered over by 45d66f592
Add wxDataViewRenderer:: SetValueAdjuster() and a
wxDataViewValueAdjuster class. This can be used to customize rendering
of values depending on whether they are highlighted (selection) or not,
without having to implement an entire new custom renderer.
Add wxHAS_STDPATHS_INSTALL_PREFIX to make checking for
wxStandardPaths::GetInstallPrefix()'s availability simpler, as the
condition under which it is compiled is nontrivial.
Fixes compilation after 2c24ee9216 on
Cygwin, which is a UNIX, but its wxStandardPaths implementation is a
Windows one.
Avoid the problems 3b4ee5a0 attempted to address in a much simpler way:
when a "size-allocate" is in progress, call gtk_widget_size_allocate()
directly, rather than deferring a call to gtk_widget_queue_resize().
See #17585
Allow only permitted combinations of text, bitmap and command link.
Also avoid null pointer crash when combining "Bitmap only" with "Use command link button".
The changes introduced in ea160f0 accidentally omitted this search
location, so only wx's own install prefix was searched. This probably
went undetected for so long because these two are often, but not always,
the same.
Fixes#17740.
wxMSW propagates accelerators to the top menu in wxMenu::UpdateAccel(),
but the reverse operation in wxMenu::DoRemove() didn't do it, resulting
in leaked leftover accelerator entries that could prevent the same
accelerator from working if an item using it was later added. Fix by
adding RemoveAccel() helper method that behaves analogously to
UpdateAccel().
Take advantage of Windows 10's flat appearance to completely fill the
button's area with background color. This isn't as easily possible in
other versions and can't be done by e.g. enlarging the painted rectangle
because focus ring (which we don't want to override) may be thin or
thick depending on user settings.
MSW buttons are highlighted by the theme when the mouse hovers over
them. This servers as a feedback to the user that the button is
clickable, so it's desirable to preserve it even if the button uses a
custom background color.
ATSU was deprecated for a long time and was finally removed from OS X
SDK in 10.11. wxOSX_USE_ATSU_TEXT was unconditionally disabled already,
so the code was never used and can be safely removed.
It does more harm than good: if an item uses background colors in the
markup, it stands to reason it's important and simply eliminating it
would result in confusing rendering. The decision how to best handle
background color in selection is application-specific.
Check NSCell's backgroundStyle property to determine whether the row's
content should be rendered normally or in the appearance for selected
rows, instead of previously used isHighlighted. The latter reports the
row as selected even if the control doesn't have focus and the selection
is therefore rendered in light gray rather than blue. In that case, e.g.
reducing colors of the text is not necessary and native controls don't
do it either.
This change makes the behavior match the native one and only renders
highlighted appearance if the row background is blue/dark.
This also matches wxDATAVIEW_CELL_SELECTED to dark background rather
than being selected. This is consistent with its purpose (alternative
appearance) as well as with what the generic wxDataViewCtrl
implementation does.
When using MinGW own, more standard-compliant, STDIO library, the correct
format specified to use for long long values is "%lld" and not "%I64d" as when
using MSVC CRT.
Closes#17736.
This patch allows specification of the maximum width of static texts
created with wxDialog::CreateTextSizer.
The patch preserves backwards compatibility by setting the previous
width value as the default argument value.
Closes https://github.com/wxWidgets/wxWidgets/pull/355
Using Bind() with a method of the class deriving from wxEvtHandler
non-publicly used to result in a compile-time error, but at least with C++11
we can detect this case and allow the code to compile.
Closes#17623.
It's not really clear why, but clang 4.0 has decided to start giving warnings
about using the result of an expression constructed using the preprocessor
"defined" operation in #if checks, so trivially avoid doing this.
Instead of combining the language, country and codepage and passing the
resulting string to setlocale(), the locale name can be used instead for
setlocale() on Windows Vista and onwards.
Closes https://github.com/wxWidgets/wxWidgets/pull/358
This fixes a crash that occurs when switching locale from Korean to
Norwegian Bokmål, since the language_country.codepage string resolves to
"Norwegian Bokmål_Norway.1252" and mbstowcs trips up on the non-ASCII
character.
Use the length provided to SetData() instead of assuming it is NUL-terminated
in the wxNEEDS_UTF16_FOR_TEXT_DATAOBJ case too, and not only in the
wxNEEDS_UTF8_FOR_TEXT_DATAOBJ onem, as was done by the previous attempt to fix
this in 20c130a578.
Closes#9522.
This was broken by 05857e66c0 which introduced
dependencies on protocols only declared in 10.11 headers.
Fix build by checking if we're using 10.11 SDK and using these protocols only
in this case.
This is more efficient than calling GetTextExtent() with a growing string in a
loop as we used to do (with ~60 character string wrapped on 2 lines it brings
wrapping time down from 4ms to 600us).
It is also slightly more accurate under macOS, even though it's still off and
some text may be truncated when wrapping.
