If the event handler destroys the wxWindow, then the subsequent call to SetupCursor(event) will miserably fail .
Moved setting the cursor before the event is handled.
GtkStock names are used for GTK+2, theme names for GTK+3 and later.
Theme replacements for stock items are those used by GTK+, from
gtk+-3.22.26/gtk/deprecated/gtkiconfactory.c. The list is as it was
prior to 4862884e, with no additions, deletions or other changes.
This could be unexpected as it seems reasonable that the model won't be
ever asked about the value of a cell if it's not going to appear in it
anyhow -- however it could still happen during the column width
computation in the generic wxDataViewCtrl implementation.
Fix this in a minimally invasive way by just skipping the call to
GetValue() in this case.
Don't use gtk_tree_view_set_rules_hint() in GTK+4, it's not available.
It is also deprecated in GTK+3 since 3.14, and the documentation advises
to not use it at all, but I will leave the decision about whether to
remove it entirely to someone else.
Support the GTK+4 API for adding buttons to dialogs (via __WXGTK4__):
- set_icon_name() instead of image_new_from_stock()/set_image()
- gtk_box_pack_end() takes only two parameters
GTK+3 deprecates GTK_STOCK_CANCEL and GTK_STOCK_SAVE etc. and GTK+4
removes them entirely. The API documentation recommends using the
strings "Cancel" and "Save" instead, use them (or the appropriate
translation.)
In GTK+4 gtk_init_check() takes no arguments, while in GTK+3 you could
pass argc/argv.
I'm not quite sure how to pass any arguments to GTK+4, so just call
gtk_init_check() in GTK+4.
GTK+4 does not support the gdk_screen_get_monitor_scale_factor() API
(since gdk has become more backend independent.)
Use gtk_widget_get_scale_factor() API instead on the app top window.
TODO: This does not solve the multi-monitor problem, for that it would
be necessary to use the scale factor of the widget on which the action
is being peformed.
Apparently, in some situations the left edge of the first tab is not
drawn when it's not selected under Windows 10. While it doesn't seem to
affect all the systems (and couldn't be reproduced here), drawing the
left edge explicitly shouldn't do any harm and should fix the problem
for the systems that are affected by it, so just do it always.
Closes#17714.
With larger fonts, there is an excessive gap between the box and the first (and last) radio button.
Instead of using the dynamic character size, use the fixed size of the radio button to determine this height.
Do not use 'RADIO_SIZE 20' as the fixed width of the radio button, but use the actual width as returned by wxRendererNative.
wxRendererNative has no GetRadioButtonSize, so for now use GetCheckBoxSize. It returns the same sizes.
Also add a half character width to account for the space between the button and the label.
There is no need to add extra width to the label of the static box.
Closes#18010.
Trying to give all the remaining space after allocating enough to the
other columns to the first one doesn't work well with wxDataViewCtrl,
which tries to do the same thing, but with the last column, so we
actually get some strange mix of behaviours, with both the first and
last columns changing size after the control itself is resized.
Stop fighting with wxDataViewCtrl and just let it to its own thing.
Closes#17476.
Reduce the number of calls to GetLineStart() in generic wxDataViewCtrl
code and thus slightly improve its performance when variable line height
is used.
See https://github.com/wxWidgets/wxWidgets/pull/438
Declare the variables just before using them (and also initialize them
at the same time); use more readable variable names; fix braces style
and add a comment explaining why do we do all this in the first place.
No real changes.
Just turn off background erasing to avoid having horrible flicker which
can be seen perfectly well simply by drag-resizing a column in a list
control with non-default background colour.
See https://github.com/wxWidgets/wxWidgets/pull/374
Add wxMSWWinStyleUpdater and wxMSWWinExStyleUpdater helper classes which
allow writing code changing GWL_STYLE and GWL_EXSTYLE bits,
respectively, in a shorter and more clear way.
There should be no real changes in behaviour.
Replace the hack with resizing the control to the minimal possible size
while it's frozen with just disabling its scrollbars in the frozen
state. This should also fix the original problem (of scrollbar jumping
around wildly as the items are added), but without different problems
due to the control being resized unexpectedly.
Unfortunately we don't have a reproducer for the original problem, which
the commits 6754c300cf ("Freeze wxTreeCtrl
in wxMSW by hiding it") and 4e1e8dc51b
("Change wxMSW wxTreeCtrl::DoFreeze() to not hide the tree any more" --
but resize it instead) tried to fix, so it's difficult to be sure that
it really doesn't exist any more, but it does seem like it ought to be
as the comment added back then spoke of the problem with scrollbar
updating and this really shouldn't happen if scrollbars are completely
disabled.
See https://github.com/wxWidgets/wxWidgets/pull/375
This function could (and did) return completely wrong results because
the value of the pointer returned by setlocale() could be (and was)
changed by the subsequent call to setlocale() with different arguments.
Fix the problem by copying the returned value into wxString immediately,
without any intervening setlocale() calls.
Ensure that m_locale is always initialized to null pointer, as it could
remain not initialized at all if information for wxLanguage could be
found, but its locale name was empty, which resulted in a crash in dtor
when the wxXLocale object was destroyed as freelocale() was called with
an invalid pointer.
Don't crash trying to use an uninitialized font in
GetPartialTextExtents() later if the font was created using
CreateFont(sizeInPixels, facename, flags) overload.
Closes#18021.
This will allow projects to use static wxWidgets libraries and zlib
(either directly or indirectly, as can heppen e.g. via Boost.IOStreams)
at the same time without link conflicts.
See #15314.
We do use wxStaticBox colour for painting its background (as can be seen
with test code from #18018, for example) under MSW, so don't say that we
don't.
Also, the reasons for not doing it mentioned in the comment are either
obsolete (wxGTK3 does do it too, unlike wxGTK2) or lost (the link to the
mailing list message doesn't work any longer and can't be recovered).
Closes#17913.
Returning true/false from wxCairoFontData::Apply() to indicate whether
Pango should or not be used was not very clear, so prefer to test for
the font explicitly in the code calling Apply() and make Apply() itself
void, consistently with the method with the same name in the other
classes.
Also avoid calling it at all from GetTextExtent() when using Pango, this
is completely unnecessary as the text colour doesn't have any bearing on
its extents.
Also use static_cast and const_cast as appropriate instead of C-style
casts.
This corrects f75387850b and just uses the
newly added assign() overload taking the buffer directly: as the buffer
already knows its length, this makes it unnecessary to pass it
separately.
Closes#16490.
Although it's the same color the control already had, overriding it
can have unexpected consequences, such as overriding the text selection
colors with GTK3. Fixes invisible wxSearchCtrl selection with GTK3.
It is possible for CGDisplayModeCopyPixelEncoding to return NULL, e.g.
during a switch between the built-in screen and an external monitor on a
Macbook. Check the return value to prevent a crash.
Closes#18015.
