This avoids conflicts with another method with the same name defined in
generic wxGenericFileDirButton, which must neither override nor hide
this method of wxButton.
This ctor is not needed as the inherited wxObject ctor is sufficient and
defining it but not operator=() explicitly results in -Wdeprecated-copy
from gcc 10.
This is not needed any longer after the changes of the last commit.
Note that the (still existent) public wxGetDisplaySizeMM() didn't use
this function, but used PPI instead.
Use "#pragma message" instead of "#warning" with this compiler to fix
the build after the recent changes of 589e043358 (Add an explicit
warning about missing OpenGL support in wxQt, 2020-07-06).
GetPaths/GetFilenames() must be used instead when more than one file
could be selected: document this and assert if the wrong functions are
called.
Closes https://github.com/wxWidgets/wxWidgets/pull/1883
This doesn't work anyhow, so it's better to prevent the code doing this
from compiling instead of getting run-time asserts or worse.
Also simplify construction of these events inside wxWidgets by passing
the window itself to the ctor instead of passing just its ID and calling
SetEventObject() separately later.
For consistency, do the same thing for wxNcPaintEvent too.
Put common code from all the different ports into it.
This is not very useful right now, but it will allow to change this
function once, instead of applying the same change to all ports, in the
upcoming commit.
Use setCurrentText(), which works for non-editable combo boxes as well
as for editable ones, instead of setEditText(), which only works for the
latter ones.
Closes https://github.com/wxWidgets/wxWidgets/pull/1542
This prevented the user from dragging the items in wxTreeCtrl, which is
something that's supposed to be possible.
To allow selection by dragging, we'd need to extend wx API with a method
indicating that dragging is not used in this particular control.
Closes https://github.com/wxWidgets/wxWidgets/pull/1458
It's preferable to use code which is simpler to understand to wx
developers not necessarily familiar with Qt API and which can also be
reused with the other ports if necessary.
In this particular case, using wxString::AfterFirst() also results in
shorter and more clear code too.
See https://github.com/wxWidgets/wxWidgets/pull/1544
The previous commit fixed accelerators support in wxQt for the items
created in XRC, but not for those created directly in the code, as
wxMenuItem::SetItemLabel() is not called in this case.
Refactor the code to extract UpdateShortcutsFromLabel() from
SetItemLabel() and call the new function both from there and from
wxMenuItem ctor, to ensure that the accelerators are taken into account
in any case.
This commit is best viewed with "git diff --color-moved".
See https://github.com/wxWidgets/wxWidgets/pull/1544
Give the application code a possibility to disable or otherwise change
the menu items before the popup menu is shown, as in the other ports.
Closes https://github.com/wxWidgets/wxWidgets/pull/1532
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
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
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
Building on windowFlags() meant that we inherited a bunch of default
flags that were not affected by Qt::CustomizeWindowHint because we
explicitly specified them when calling setWindowFlags().
Instead of doing this, start with nothing and just add the styles that
we need.
This notably ensures that the frames created without wxCLOSE_BOX style
actually don't have any close button.
Closes https://github.com/wxWidgets/wxWidgets/pull/1335
