This was broken, possibly by 25c9b032a8 (Don't call CacheBestSize() from
DoGetBestSize() implementations, 2016-04-03), as it didn't change the
min size of the status bar and so it was resized to it when it was
managed by wxFrame.
See https://github.com/wxWidgets/wxWidgets/pull/2133Closes#18996.
Failing it is not useful, this results in the CI failure when in 99% of
the cases the transient network problem which resulted in this test
failure has nothing to do with the changes being tested.
Don't loop indefinitely until we run out of memory, possibly after
wrapping around INT_MAX, but impose an arbitrary limit of 128MiB for the
max allocation done by wxString::PrintfV() when the provided format
string or one of the arguments are invalid.
This notably fixes a crash when trying to use "%c" to output an invalid
Unicode character.
Also improve comment explaining DoStringPrintfV() logic and change the
size type to size_t from int.
Co-Authored-By: Arrigo Marchiori <ardovm@yahoo.it>
This makes it more compatible with the standard behaviour of vswprintf()
and allows to use the same logic in the builds using our version of this
function and the normal ones in DoStringPrintfV(), simplifying its
(already rather hairy) logic.
Update the tests to not require any particular return value in case of
buffer overflow, as this differs between Unicode and non-Unicode builds.
When we finally drop the latter, we should just check that it always
returns -1 in this case.
Note that ideal would be to return the actually needed size of the
buffer in case of the error due to buffer being too small, but this
isn't that simple to do and it's probably not worth spending time on
improving this code as long as we still need to use the buffer doubling
strategy in DoStringPrintfV() when using the standard vswprintf().
Ensure that vertical rules extend to the bottom of the window on the
non-first page of the control too.
This was probably broken in 5ae2a8ebb8 (Simplify API for extending
wxListCtrl background display, 2020-11-09).
Closes https://github.com/wxWidgets/wxWidgets/pull/2130
Reduce duplication and simplify the test code by using the same macro
for any number of printf() arguments.
Note that this relies on "##__VA_ARGS__" gcc extension to work even for
CMP0(), i.e. when there are no parameters at all. If this ever becomes a
problem, we can always reintroduce a separate CMP_NO_ARGS() macro.
This is not ideal, as resetting the page contents loses the current
selection and redoes a lot of work that could be avoided, but it's
(much) better than nothing, as it fixes the window appearance after e.g.
moving it to another monitor.
Closes#18564.
This replaces the fix of f4dcac9f44 (Return wxFont adjusted to DPI in
wxHtmlWinParser::CreateCurrentFont(), 2020-11-25) adjusting the font
explicitly under MSW with a better fix, associating the correct window
(and hence DPI) with the device context used in OnPaint().
See #18564.
This used to work previously but got broken when using C++17 by
c3810da549 (Allow using noexcept methods with event tables macros,
2020-04-09), as cast added to deal with noexcept handlers relied on
argument type deduction which can't be done for overloaded functions.
Fix this by extracting the event argument type from the function pointer
type and specifying it explicitly, while still letting the compiler
deduce the class.
Add a test case checking that using overloaded event handlers compiles.
See #18721.
Closes#18896.
Handling mask when converting wxBitmap to wxImage was accidentally
broken by 7e9afad53a (Add real support for monochrome bitmaps to wxMSW,
2020-10-19). Fix this now and reuse the new wxMonoPixelData to make the
code simpler and more readable.
This commit is best viewed ignoring whitespace-only changes, as it
unindents a large block of code.
Closes https://github.com/wxWidgets/wxWidgets/pull/2125Closes#18974, #18975.
In the context of wxPlatformInfo, 'architecture' means either '32 bit' or
'64 bit'. Anywhere outside the context of wxPlatformInfo, this concept is
known as 'bitness'.
For the rest of the world, 'architecture' generally refers to the CPU
instruction set architecture, i.e. something like x86, x86_64, arm64, whereas
'operating system architecture' refers to the design of separating kernel
space, user space, etc.
This might compile with even earlier MSVS versions, but it definitely
does with the recent ones, so enable the test for this compiler, even if
it still doesn't define __cplusplus to indicate C++11 conformance by
default.
Make sure these headers can be compiled even when the control they're
written for is not available in the build. Including them in this case
doesn't make much sense, of course, but not giving any errors is still
nicer and consistent with the rest of wx headers.
Replace the overloads added in c2e5f3520a (Add a wxRound() overload for
int, 2020-11-05) and 1cf7c47934 (Add more wxRound() compatibility
overloads and improve docs, 2020-11-05) with a template function that
should work for all integer types.
This fixes compilation of existing code using wxRound() with size_t
values: while this doesn't make any sense, it doesn't make much less
sense than using it with int, so let people avoid having to change their
code when upgrading to wx 3.2.
Also add at least some minimal tests for this function.
Closes https://github.com/wxWidgets/wxWidgets/pull/2119
This requires refactoring NewCloseButton() in order to extract
CreateCloseButton() from it, as XRC relies on being able to use two-step
creation which was previously impossible for this kind of buttons.
CreateCloseButton() is rather unusual, as it has to be declared in the
derived, platform-specific class, in order to be able to call its
Create(), but is defined only once in common, platform-independent,
code. However the only alternative seems to be to have a static
function, e.g. InitCloseButton(), which wouldn't be very pretty neither.
Closes https://github.com/wxWidgets/wxWidgets/pull/2118
IsEnabled() wrongly returned true even when the TLW was actually
disabled due to a native modal dialog using it as owner being currently
shown.
Fix this by trusting the actual HWND state, rather than our internal
m_isEnabled, except before the window is created.
Do it for TLWs only even if, in principle, we could check for
WS_DISABLED for the other windows too. However this would make
IsThisEnabled() inconsistent with the other platforms, where it returns
true when the window parent is disabled, but the window itself isn't,
which is currently also emulated by wxMSW, but wouldn't be the case if
we trusted WS_DISABLED presence. And while there might be other problems
due to lying about the actual window state in this function, it doesn't
seem to create any problems in practice, so for now leave the old logic
in place.
As a side effect, this makes wxWindowDisabler work correctly when a
message box is shown by another window when it's created, as it will now
correctly avoid re-enabling the message box parent in its dtor.
Closes https://github.com/wxWidgets/wxWidgets/pull/2117
See #11887.
No real changes, just get rid of an unnecessary instance of
wxWindowList: this one can be safely replaced with a vector because it's
a private member and so changing its type doesn't affect compatibility.
No real changes, just remove asserts verifying that a pointer is
non-null right before dereferencing it, as they're perfectly useless for
all the usual reasons and just add extra code to relatively often used
functions.
This resulted in a crash when WM_ACTIVATE was received from inside
wxWindow dtor, executed after wxTopLevelWindowMSW dtor, and passed to a
handler defined in wxTopLevelWindowMSW and using its already destroyed
members.
Perhaps we should avoid dispatching any messages when the window is
being destroyed, but it's not totally obvious that this is not going to
break something, so for now apply just this minimal fix.
Closes#18970.
This partially reverts 44d732b8a5 (Use TB_SETBUTTONINFO when updating
stretchable toolbar separators, 2019-02-24) and restores the behaviour
before this commit for the vertical toolbars only, as the new code
doesn't work for them, even though like it seems it should (and we don't
get any error when using it).
Still keep the simpler path for horizontal toolbars, as there doesn't
seem to be any problems with it in this case.
