Explicitly document that wxDataViewRenderer::SetValue() is never called
with null values (if we ever really need this, we should add a separate
ClearValue() method) and also document that MakeHighlighted() both
receives and must return a non-null value (the latter is required
because the returned value is passed to SetValue()).
See #18934.
This reverts commit f68c88b8d2 which
doesn't seem necessary any longer: the originally observed problem can't
be reproduced in contemporary macOS versions (10.14+), while calling
SetValue() even for null values results in asserts from several
renderers which don't expect this to happen.
This commit is best viewed ignoring whitespace-only changes.
Closes#18934.
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.
Calling ReleaseMouse() from wxEVT_MOUSE_CAPTURE_LOST handler could
result in bogus asserts about ReleaseMouse() reentrancy because the
function generating "capture lost" events in wx itself wrongly set the
wxMouseCapture::changing flag, instead of just examining it, as it was
supposed to do.
This corrects a problem introduced back in b0ad1918b9 (No changes, just
use wxRecursionGuard instead of manual boolean flag., 2013-08-18) which,
contrary to the commit message, did change the behaviour by replacing a
simple test with the use of wxRecursionGuard here.
This was also changed in 3c28244806 (Improve wxGrid appearance in dark
mode under macOS, 2020-08-07) but there doesn't appear to be any good
reason to do it as wxSYS_COLOUR_3DDKSHADOW is the same as the previously
used wxSYS_COLOUR_3DSHADOW (a.k.a. wxSYS_COLOUR_BTNSHADOW) under Mac, so
this didn't change anything there -- but did make the shadows darker and
hence more pronounced and more noticeable under MSW.
Undo this change to restore the old and nicer looking appearance.
The changes of 3c28244806 (Improve wxGrid appearance in dark mode under
macOS, 2020-08-07) resulted in using white highlight colour over white
background under at least MSW and probably elsewhere, making the grid
cursor invisible by default.
Fix this by using wxSYS_COLOUR_WINDOWTEXT which must contrast with
wxSYS_COLOUR_WINDOW used for the background colour.
This isn't needed when the comment comes right before the define,
and also in newer doxygen versions it causes the __WXDEBUG__ macro
to be not documented because it interprets @def __WXDEBUG__ as being
the WXDEBUG macro instead.
This provides a less intrusive, and also usable by the end users rather
than only by the developers, way of doing the same thing as the just
added wxSizerFlags::DisableConsistencyChecks() does.
We already disabled the warnings inside windows.h, but since bf5090bcf3
(Enable Winsock 2 and IPv6 build options by default, 2021-04-24) we
could get warnings from winsock2.h, so move its inclusion inside the
region where the warnings were disabled too.
For the record, the warnings were, rather surprisingly, C4668, which is
disabled by default, but apparently was enabled somewhere inside (at
least some versions of) SDK headers.
This commit is best viewed with --color-moved git option.
This currently means macOS 10.11 only, which is only used on Travis CI
and Python 2 installation there is broken anyhow, so this doesn't make
anything worse than it already is.
These functions don't need to be members of wxGtkPrintNativeData as they
don't use this object at all, so one shouldn't be required to call them.
And rather than making them static, just make them private functions
instead.
No real changes, this is just a refactoring.
The paper size and orientation in wxPrintData were never updated because
we didn't retrieve them from GTK correctly: they need to be extracted
from "default-page-setup" property and not the main GtkPrintSettings
themselves, at least with GTK 3.
This is necessary in order to get the information entered by the user in
the dialog and was already done in PrintDialog(), but not Print()
itself -- now do it there as well.
No real changes, just make it simpler to do other things before
returning successfully by handling error returns separately.
This is also more consistent with PrintDialog() method of the same
class.
No real changes.
Don't add -l to libraries already containing it (for example -lpthread).
Change libraries with format libName.so or libName.a to -lName,
configure also uses -l for these libraries. Account for possible invalid
libraries (Name-NOTFOUND) which could happen with imported libraries,
for example OpenGL::OpenGL.
Closes https://github.com/wxWidgets/wxWidgets/pull/2359
Right clicking on the column header shouldn't generate context menu
events, but it did because our gtk_dataview_button_press_callback() got
these events for both the "bin" window, containing the items, and the
"header" window.
Fix this by filtering out the events not sent to the right window.
It would be even better to not get these events in the first place, i.e.
somehow not connect to them in the first place, but it's not clear how
to do this, so settle for this solution for now.
For testing this fix, just right click any column in the dataview
sample: previously this generated both messages about the column header
right click and the context menu in wxGTK, while now it only generates
the former, as in the generic version.
