This function was defined in wxGTK and wxOSX, but not in wxMSW or the
other ports, but it can be useful there too, so make it public and
define it in common code.
When touch events were enabled, normal mouse move and click events were
not generated any longer. Fix this by doing the following two things:
First, emulate the LeftDown, LeftUp, and Motion events, that are no
longer triggered when using the "touch-event".
In addition, remove GDK_BUTTON1_MASK in the press callback, that is
never set when using a mouse, but that is set for some reason by GTK
when using a touchscreen.
See https://github.com/wxWidgets/wxWidgets/pull/2539Closes#19265.
Signed-off-by: Thierry Bultel <tbultel@free.fr>
We accidentally ended up with two functions doing the same thing, since
DoGetBorderSize() was added in 743b426605 (Added DoGetClientBestSize()
and use it for a couple of controls in wxMSW., 2009-06-22), as we
already had GetWindowBorderSize() added even earlier in 333d70525c
(added wxWindow::GetWindowBorderSize(), 2006-11-25), so remove the
redundant non-public function and use GetWindowBorderSize() everywhere.
This does change the behaviour of GetWindowBorderSize() in wxMSW, wxGTK
and wxUniv, as it now does what DoGetBorderSize() used to do, but this
should be an improvement, as DoGetBorderSize() implementation was more
precise.
Connect to key-{press,release}-event on the "focus widget" rather than
the main widget, to ensure that we get them before the native control
does and so can generate the key events even for the keys handled by the
control internally.
This allows to get events for the arrow keys in wxDataViewCtrl, for
example, while previously these keys were consumed by the control
itself, as could be seen with the following patch to the sample
---------------------------------- >8 --------------------------------------
diff --git a/samples/treelist/treelist.cpp
b/samples/treelist/treelist.cpp
index af6905cecb..74894cc9a9 100644
--- a/samples/treelist/treelist.cpp
+++ b/samples/treelist/treelist.cpp
@@ -349,6 +349,10 @@ bool MyApp::OnInit()
sizer->Add(textLog, wxSizerFlags(1).Expand());
SetSizer(sizer);
+ m_treelist->GetView()->Bind(wxEVT_KEY_DOWN, [](wxKeyEvent& e) {
+ wxLogMessage("Key in tree: %d", e.GetKeyCode());
+ e.Skip();
+ });
// Finally show everything.
Show();
---------------------------------- >8 --------------------------------------
Pressing arrow keys didn't generate the expected message before (unless
the focus was on the control header and not on the main area itself).
This may fix similar issues with other controls setting m_focusWidget as
well.
3217a4e8a2 (Fix best size for windows which are hidden when TLW is shown
with GTK3, 2021-04-30) did not account for possibility that window needing
revalidated best size is also the TLW.
See #16088
Relying on "check-resize" to detect when a "size-allocate" is in progess is
insufficient, resulting in the possibility of a window ending up with the wrong
size or position after inital layout. Using our existing "size-allocate"
handlers should be enough to detect the cases we care about.
See #18865
Limit the changes of d06e97e8d9 (Make sure toplevel is active in
SetFocus(), 2020-07-08) to GTK 3 only as they break GTK 2 GUI test
suite, resulting in many CI failures.
See #18783.
Restore IsFocusable() check that was commented out, without any real
explanation, by c7bfb76a2c (A number of focus handling improvements:
Left clicking on a window only focuses the window if not processed.
wxControlContainer::SetFocus moved to wxControlContainerBase so that a
container now focuses the first child even on wxGTK. wxAuiBook is now a
container, need for correct navigation on wxGTK., 2007-08-18).
This is needed to avoid giving focus on click to the windows that
explicitly override AcceptsFocus() to return false, as e.g.
wxGridColLabelWindow and other wxGrid subwindow classes do. From the
user point of view, previously clicking on a grid row/column label just
disabled the user of arrow keys, which was very inconvenient (and didn't
happen under MSW).
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.
If the popup menu position was explicitly specified, it wasn't taken
into account correctly in wxGTK code as it always clamped it to the
primary display boundaries, even if the window showing the menu wasn't
on this monitor at all, typically resulting in the menu shown at the
left or right edge of the monitor instead of the correct position.
Fix this by using the display containing the window instead. This
requires passing the window, or rather the menu from which it can be
retrieved, to wxPopupMenuPositionCallback too, so add a helper struct to
pass both the position and the menu to it.
Closes https://github.com/wxWidgets/wxWidgets/pull/1621
If neither main widget nor connect widget is focusable (which notably
happens when they're the same anyhow, as is the case for wxChoice, for
example), still use the main widget as mnemonic instead of not using any
mnemonic at all.
This fixes activation of a wxChoice preceded by wxStaticText by pressing
the key combination corresponding to the label mnemonic, which didn't
work previously.
Due to a wrong "else" in RealizeTabOrder() implementation, we could set
the mnemonic widget for a previous widget using mnemonics (i.e.
wxStaticText or wxStaticBox) rather than the one closest to the actual
control activated by the mnemonic.
If a mouse event handler calls Refresh(), increase the likelyhood that a
paint event can be issued before the next mouse event occurs, by requesting
more mouse events from the the end of the handler rather than the start.
See #18314
Don't forbid calling Enable() before creating the window and just do
nothing in this case and do disable the window when it's actually
created if it's supposed to be disabled.
Note that this doesn't work for classes overriding Enable() directly,
such as wxButton or wxCheckBox, currently.
wxWindow::GetContentScaleFactor() always returned 1 before the window
was shown in wxGTK, which was rather annoying as typically icons are
initialized on application startup, i.e. before showing the windows, and
so the wrong scale factor was silently used for them.
It could happen that the window remained as the global "pending focus"
even after it lost its focus, resulting in FindFocus() still returning
it as the currently focused window, even though it didn't have focus any
more.
This notably broke focus logic of wxCompositeWindow and could result in
missing wxEVT_KILL_FOCUS for windows using it, such as wxDatePickerCtrl,
and quite likely was responsible for other focus problems in wxGTK as
well.
No real changes, just add a helper wxDumpWindow() function to make focus
logging less verbose and slightly more readable (as the label is not
shown any more if it's empty).
