Compiler seems to generate incorrect code for the dithering code taken from
libjpeg, where it is known to create problems too, so use the same workaround
as libjpeg uses and disable optimizations for this function.
This is unsatisfactory and it would be great to find a way to tweak the code
to avoid the problem, but it's still better than crashing.
See #17764.
Manually dispatching events to eligible windows is error-prone and
should really be the responsibility of the system. But the old
approach of blocking in nextEventMatchingMask:untilDate:inMode:dequeue
seems to fail because while this blocks, events can't even enter the
queue.
Thus, revert to the old logic, but instead of blocking in
nextEventMatchingMask, first block on processing the input source via
[NSRunLoop runMode:beforeDate].
This resolves the original problem which was also fixed by the commit
4a83fd4696 but doesn't seem to introduce any
regressions, and seems to be a much cleaner fix overall.
See #17737.
Closes https://github.com/wxWidgets/wxWidgets/pull/365
If a disabled wxBitmapComboBox had to be recreated, it lost its disabled
status and became unexpectedly enabled.
Fix this by explicitly disabling it back in RecreateControl() if necessary.
Closes https://github.com/wxWidgets/wxWidgets/pull/376
Exclude code added in 92dc929b3f from build in
32 bit mode because it fails to compile, apparently due to missing Objective-C
runtime support for per-instance variables in 32 bit runtime.
Allow using custom Windows class names for our windows and use this to give a
unique class name allowing to identify it in the screen readers to
wxDataViewCtrl.
Closes https://github.com/wxWidgets/wxWidgets/pull/373
Take the "player" of the right type in -[wxAVView initWithFrame:player:]
method: we need a wxAVPlayer, which has a writable "playerLayer" field that we
set, and not an arbitrary AVPlayer here.
This fixes a warning which could become a problem if anything else than
wxAVPlayer was ever passed as parameter to this function.
Using "%20c" in scanf() doesn't work unless we really have exactly 20
characters, so use "%20[^)]" to take up to 20 characters until the closing
parenthesis instead.
Closes#17739.
This method allows to use the Windows class to use for the window being
created instead of always using "wxWindow" or "wxWindowNR".
This can be useful to make it possible to handle some windows specially from
outside the application, e.g. use specific class names for accessibility
purposes as will be done by the next commit.
Add a flag to let wxApp::GetRegisteredClassName() register just a single Win32
class instead of always registering two of them: the "normal" (but rarely used)
version and the "NR" version used unless wxFULL_REPAINT_ON_RESIZE style is
specified.
With the new RegClass_OnlyNR, only the latter is registered and used.
This is not used yet, but will be soon.
Determine which class name to use in MSWCreate() caller instead of doing it
partly there and partly in MSWCreate() itself, which used to add the "NR"
suffix if necessary -- now it doesn't do this any more and just really created
the window using the given class.
No real changes, just prepare for future enhancements.
Disabled appearance should only be used for disabled rows of otherwise
activable or editable renderers, not for inert ones. A typical example
is a bitmap renderer which rendered bitmaps slightly lighter due to its
disabled appearance. With this fix, the behavior is now consistent
across the three implementations.
Use wxPoint and wxSize instead of individual "int" variables to make the code
slightly shorter and avoid clang warnings about "y" and "h" being possibly
uninitialized (which couldn't happen, but the compiler didn't understand it,
at least in non-optimized builds).
Compile accessibility support on Windows by default now that the generic
wxDataViewCtrl control implements accessible interface. After the
changes from 7dab555f71, accessibility
support is much more lightweight and doesn't interfere with normal win32
behavior, so this change shouldn't affect accessibility-unaware code in
any way.
Change NotifyEvent() implementation so that it doesn't call
::NotifyWinEvent() immediately, but only in the next iteration of the
event loop. This makes it easier to write code that uses, because it
must be called after the changes it notifies about were fully made and
are visible in the corresponding window's accessible interface.
Items in wxDataViewCtrl are only read-only if there's no editable
column, in which case all items are read-only. This flag is only useful
for accessibility if only some of the items in the list are read-only;
if all of them are, it's just noise.
For consistency with the Unix version, call wxProcess::SetPid() even when
executing the child process synchronously in wxMSW too.
This allows code dispatching events during synchronous execution to access the
PID of the child, if needed.
Closes https://github.com/wxWidgets/wxWidgets/pull/369
__USE_MINGW_ANSI_STDIO is apparently not defined when using MinGW as a
cross-compiler from Linux, so 7c730334a2
resulted in -Wundef warning about this.
Fix this by checking if the macro is defined before testing its value.
See #17736.
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
