Doing this under all platforms results in too many false positives,
which can't be avoided currently, e.g. even if an application uses "Tab"
as an accelerator only under MSW, these messages still appear (in debug
builds, but this is more than sufficient for them to be annoying).
For now, restrict the messages to wxGTK only. In the future we could
revert to giving them under all platforms if we provide some way of
disabling them, e.g. qualifying accelerators with "[port]" or "[!port]"
string before them.
This partially reverts 6596f5a98d, see
https://github.com/wxWidgets/wxWidgets/pull/1505
Closes https://github.com/wxWidgets/wxWidgets/pull/1566
Declaring the copy ctor/assignment operator for a local class without
defining them triggers MSVC warning C4822, so don't do this to avoid
unnecessary noise in the build logs (we could disable the warning or
conditionally do this for non-MSVC compilers, but it doesn't seem to be
worth doing this for a class used inside a single function and very
unlikely to be copied accidentally).
Override DoEnable() in wxGrid instead of Enable() to ensure that the
grid is shown appropriately for its current state whenever either it or
its parent is disabled.
Note that this also fixes the bug with only the main grid window being
refreshed, but not the row/column headers, which also need to be.
It doesn't really matter whether the grid is disabled because it was
explicitly disabled itself or because it's implicitly disabled due to
its parent being disabled, it should still show its disabled status to
the user by rendering its headers in a greyed out state.
Avoid setting state to DragSelectingState unless dragging items in
wxTreeCtrl is explicitly allowed, as this this causes bad behaviour
downstream with subsequent selections when the client does anything in
the event handler beyond simply not allowing the event.
Basically, we can't be guaranteed of the mouse state on return from the
event handler, so dropping into drag selection mode is potentially
inappropriate (or just plain bad).
Closes https://github.com/wxWidgets/wxWidgets/pull/1523
In wx API, calling wxTreeCtrl::SelectItem() is supposed to generate an
event.
Also use Qt selection model to support single-selection mode.
Closes https://github.com/wxWidgets/wxWidgets/pull/1453
These events use a different convention from all the other ones in Qt
and need to be ignored, rather than accepted, to prevent the default
action from occurring.
And these events are also sent to disabled windows, which are never
supposed to receive them in wx API.
Closes https://github.com/wxWidgets/wxWidgets/pull/1371
Let the wx layer handle default-ness, as the auto behaviour has unhappy
consequences that can't be controlled via the wx API. (For example, a
Delete button being considered default simply because it's the first
button in the dialog.)
Closes https://github.com/wxWidgets/wxWidgets/pull/1366
This was previously done only under Mac, but it doesn't seem to make
much sense to skip the mouse event if we handled it by capturing the
mouse and it seems to create problems in wxQt too, so just generalize
the Mac behaviour to all platforms.
See https://github.com/wxWidgets/wxWidgets/pull/1360
Qt notebook page changed events had the wrong "previous page" index in
circumstances where the page has been changed by methods other than
clicking on the tabs, for example using the "Pages->Next page" menu
option in the notebook sample.
Closes https://github.com/wxWidgets/wxWidgets/pull/1359
No real changes, this is just a refactoring to allow reusing the same
loop waiting until we can get the real window geometry in other tests.
This commit is best viewed with --color-moved.
Using "move" is correct for positioning, as it takes into account the
frame extent. Unfortunately, there is no corresponding API to set the
frame size. So we need to compute the effective client size and use
"resize". We can't use "setGeometry" for this purpose, since a widget's
"geometry" excludes the frame size. We would need to adjust the position
to go from frame to client coordinates. It's more straightforward to
simply have Qt do it with "move".
Closes https://github.com/wxWidgets/wxWidgets/pull/1349
Handle some mouse events explicitly when a wxQtScrollArea is set as
"mouse captured".
The issue arises in that the QScrollArea has two methods: event() and
viewportEvent(). Normally a "QAbstractScrollAreaFilter" is set up by Qt
which routes any events to the viewportEvent() method. And the normal
event() method throws mouse events away (for reasons I'm not aware of -
but it is what it is). If a wx window with a scroll area (e.g.
wxRichTextCtrl) sets capture, the wxQtScrollArea (QScroll-derived) gets
set as the direct "mouse grabber", and all events then bypass the filter
and are sent directly to the "event" method, which throws them away. The
typical result is that the window setting capture no longer gets mouse
events, it keeps capture since it's looking for a mouse up that never
comes, and the app more or less locks up since all mouse events are
being effectively discarded.
This change catches any event that comes in via the event() method and,
when the mouse is captured by the widget, forwards it on to the
viewportEvent method instead, performing what the filter would do via
the normal event routing.
It doesn't forward on "mouse press" events because the initial event
that causes the capture ends up being fed back again, resulting in a
"captured twice" error. The underlying reason I can see for this "being
fed back again" is that, for some inexplicable reason, the
wxRichTextCtrl "skips" the event even though it has actually processed
it and taken capture. That means this solution isn't 100%, but it does
fix the 99%+ cases where the capture is only gotten to redirect mouse
moves and button ups.
Perhaps an alternative solution might be to stop grabbing the mouse in
wxQtScrollArea, but this would require more changes.
Closes https://github.com/wxWidgets/wxWidgets/pull/1346
Under wxGTK+2, when wxBitmap has a wxMask but this mask shouldn't be used
in the actual drawing (useMask parameter in wxDC::DrawBitmap() is set to
false), we need to get bitmap data from the buffer with raw (original,
non-masked) data and not from the buffer containing data with mask applied.
Close#18498.
Under wxGTK+2 bitmap data with mask and without it (raw) should be stored
in the separate GdkPixbuf buffers - just like it's done in wxGTK+3. These
two buffers are necessary because only GdkPixbuf with raw bitmap data
(original, non-masked) should be copied when wxBitmapRefData instance is
cloned e.g. in SetMask(). GdkPixbuf with masked data is not copied and is
created on first use in wxBitmap::GetPixbuf().
Closes#18508.
See #18498.
The initial value was not taken into account before because the best
size computed before it was set, i.e. for the empty control, was always
used, as it was never invalidated.
Do invalidate it now if the control is created with non-empty value, in
order to adjust its best, and initial, size appropriately to its
contents.
Closes#18507.
Closes https://github.com/wxWidgets/wxWidgets/pull/1560
Cast the dialog pointer to wxFileDialogBase to avoid failures when using
wxGenericFileDialog, which inherits from wxFileDialogBase, but not from
wxFileDialog itself.
Closes#18506.
Use wxHeaderCtrl-specific GetColumnTitleWidth() function to account for
the native header control margins, otherwise the computed width could be
insufficient for short columns, resulting in their ellipsization.
