Recent MSVS 2017 versions (15.9.x) as well as MSVS 2019 give warning
C4548 about "expression before comma having no effect" when including
standard CRT headers.
This happens because when building projects targeting 8.1 SDK, as the
IDE uses the hard coded 10.0.240.0 version of UCRT headers in this case
(see \Common7\IDE\VC\VCTargets\Microsoft.Cpp.Common.props), and the
headers in this version haven't been, and will never be, updated to
avoid this warning, as was done in later 10.0.x UCRT versions.
Fix this by explicitly disabling the warning in wx/beforestd.h, as even
setting the warning level to 1 for the standard headers somehow isn't
enough to suppress it if it's enabled.
This is always 0 for any still supported compiler, so remove the option
and configure checks for it.
Still define it as 0 for compatibility, just in case it's used outside
of the library.
We don't support MSVC 6 (__VISUALC__ == 1200) or eVC (1201) since more
than 5 years (see f4b80e5337), so it's
useless to keep code compiled only when this compiler is used.
Improve the class description.
Mention that one needs to call wxAutomationObject::SetConvertVariantFlags()
with wxOleConvertVariant_ReturnSafeArrays to actually receive a
wxVariant with SAFEARRAY (if possible).
Make better use of now-documented wxSafeArray in the code examples.
Closes https://github.com/wxWidgets/wxWidgets/pull/1611
Add wxMSVC_VERSION_ABI_COMPAT definition to the version of the file
included in the binary distribution to make it compatible with the
actual DLL names.
Closes#18510.
The loop computing "colswidth" (the sum of widths including last column)
actually incorrectly computed "lastColX" (the sum of widths until the
last column), fix this.
See #18295.
Use "relative pixels" (known as DIPs in wx) instead of dialog units, as
the latter ones don't scale correctly due to rounding errors when using
high DPI.
Also take into account the fact that the 1px invisible border around the
visible part of the buttons is not scaled by the standard control, so
don't apply scaling to this part when determining the best size neither.
Closes#18528.
This results in buttons being forced to be too tall when using high DPI
and is useless anyhow, as all callers of this function deal with the
height by increasing it to the minimum acceptable value already (or
discard it entirely in wxMessageDialog::AdjustButtonLabels()).
See #18528.
Avoid spurious error in the unit test by calling Now() and UNow() a few
times in a row until they return the same second, as we may be unlucky
enough for this not to be the case when we call them just once.
Fix autosizing broken in 3c72396a36 and
not fully fixed by f7e335c031.
Simplify the code to make it more obviously correct, by separating the
computation of the extent suitable for the label and determining the
size to use taking into account the extents of both the column data and
the its column.
Also add the unit test checking that auto-sizing works correctly in all
the different cases.
Closes https://github.com/wxWidgets/wxWidgets/pull/1600
Co-Authored-By: Ilya Sinitsyn <the_siv@mail.ru>
On DC with a non-rotated coordinate system drawing a filled rectangle with ExtTextOut() Win API is faster than drawing a line with MoveTo()/LineTo() so on such DCs we can use ExtTextOut() to draw horizontal/vertical lines with solid colors and square ends instead of calling MoveTo()/LineTo().
See #18517.
This method is supposed to be overridden in the sub-windows of a
composite control (and is indeed correctly implemented in
wxGridSubwindow), but it doesn't make any sense to implement it in the
parent window itself.
This method was probably never executed (which is how the problem went
unnoticed for 10+ years since 760be3f7cb),
but it's still wrong to define it here, so remove it.
This is unnecessary as TAB navigation is not supposed to work between
wxGrid children and actually harmful as this resulted in SetFocus()
doing nothing, instead of setting focus to wxGridWindow, if the focus
was on wxGrid itself for some reason (this happened at least in the grid
unit tests and resulted in failures because the in-place editor didn't
appear as expected).
Somehow, mouse release events generated immediately after the mouse
press ones are sometimes (not always, but often enough to reliably
prevent the test suite from passing) simply lost, i.e. not received by
the GTK event loop.
The only workaround seems to be to introduce an artificial delay, which
does avoid the problem, at the price of making the tests run longer and,
worse, not really solving the underlying problem, whatever it is. But
it's still better than nothing.
Unbind the event handler referencing a local variable, as leaving it
bound could result in a crash later if another paint event was generated
for the window for whatever reason.
Doing it like this requires using 2 different objects, but the
complexity can be still hidden inside WaitForPaint class, with the 2nd
object being just a member of it, and, in fact, makes the code using it
simpler as it doesn't need to use a boolean variable with it.
Restore the checks for the model stamp, reverting the changes of
18594afe76: we still need to ignore the
calls to at least iter_children() and iter_nth_child() model methods
that can be called from inside gtk_tree_view_set_model() when we reset
the model, as running these methods crashes when trying to use the
pointers to already deleted items.
For consistency and robustness, add checks for the model stamp to all
the methods and not just those two, just in case other ones end up being
called later in some way.
Also add a unit test checking that DeleteAllItems() doesn't crash and
does delete all items.
Closes#18533.
The previous fix in 5442edbbe9 corrected
the type for the older NetBSD versions, but not NetBSD 10, which now
uses "void*", as all the other platforms, so restrict the original fix
to NetBSD versions < 10 only.
See #18199.
For some reason, names were used for cyan and light grey, even though
all the other ones used RGB values since refactoring the stock objects
to be created on demand in f516d98637.
Use RGB values for these two as well now.
Closes#18530.
This is an ugly workaround for a mysterious problem occurring with the
simulated "Enter" presses under GTK, but it's worth it, as it allows all
grid tests, including the ones using wxUIActionSimulator, to pass now
under wxGTK2 (a couple of tests still fail under wxGTK3).
For some reason, mouse press events were still received without
flushing, but mouse release ones were not received by GTK itself (and a
fortiori by wxGTK) without it.
