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.
Add autoconf and bakefile support for detecting and using GTK+4, similar
to how GTK+3 is detected and used.
GTK+3 is checked for first before GTK+4, this can be overridden in
`./configure` using `--with-gtk=4`.
With GTK+4 the `__WXGTK4__` `#define` is also set in `setup.h.in`.
This commit does not regenerate any files.
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 test didn't make sense at all as it didn't actually test "C" locale
formats as calling setlocale(LC_ALL, "C") didn't actually change the
values returned by wxLocale::GetInfo(), so it still returned the values
corresponding to the French locale set in this test setUp() method and
the test only passed because it used wrong values (i.e. the same ones as
in French locale test).
We also don't have any simple way to test "C" locale formats, we can
only test them for wxLANGUAGE_DEFAULT, but this corresponds to the OS
defaults which can be customized by user (e.g. in the control panel
under MSW) and so we can't expect them to be equal to any fixed values.
The simplest solution is to just drop this test, as it's not very useful
anyhow (French locale test above already covers the same code).
This was broken by 9507bc430e which
stopped defining HAVE_LOCALE_T in configure but didn't update the code
using it.
Restore the old behaviour by continuing to define HAVE_LOCALE_T even if
we don't test (just) for it any longer.
See https://github.com/wxWidgets/wxWidgets/pull/461
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.
