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.
Add CMake-based build system.
Merge the original branch without any changes except for resolving the
conflict due to moving the contents of .travis.yml to a separate file by
propagating the changes done in this file since then to the new script
and rerunning ./build/update-setup-h and ./build/cmake/update_files.py
to update the file lists changed in the meanwhile.
Closes https://github.com/wxWidgets/wxWidgets/pull/330
This extends the changes done 01cd702ee3
to another test case and so makes as much sense as the other commit.
It's still not clear what's really going on here as, somehow, this test
passed under AppVeyor before, which shouldn't have been happening if the
explanation in that commit message was correct. And it also doesn't
explain why did it suddenly fail after a completely unrelated change,
see https://ci.appveyor.com/project/wxWidgets/wxwidgets/build/2502/job/l24gc2j0j7h7huxl
It seems that MinGW-w32 started distributing GDI+ headers since this
version and MinGW-w64 might have supported them for even longer, but
it's difficult to test for the MinGW distribution used in this header,
as it is included before wx/msw/gccpriv.h which defines
__MINGW32_TOOLCHAIN__ and __MINGW64_TOOLCHAIN__ symbols and changing
this is tricky due to relative order of defining UNICODE and
wxUSE_UNICODE and including MinGW headers, which can only be included
once UNICODE is set properly.
But while the fully correct solution is difficult, just checking for the
compiler version should solve the problem in 99.99% of the cases in
practice as there should be vanishingly few people using MinGW-w64 with
gcc < 4.8 currently, so this simple solution is good enough.
Closes#17973.
Fix a copy-and-pasto in the header and also mention that wxURLDataObject
derives from wxDataObjectComposite, and not wxTextDataObject, in wxGTK
too.
Also add a note about the exact base class being an implementation
detail.
Closes https://github.com/wxWidgets/wxWidgets/pull/624
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.
A recent change fixing monolithic build broke the normal build when
using built-in libraries under Unix as -lwxzlib now came before -lwxpng
and so zlib symbols used by libpng were not found (in fact, they could
still be found in the system library which is usually available under
Unix, so the problem wasn't seen immediately, but it was still there).
See https://github.com/wxWidgets/wxWidgets/pull/621
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.
This is more convenient and less error prone than using the existing
ctor taking char pointer and length as the buffer contains both.
Also add the corresponding assign() overload for consistency.
See #16490.
Show non-printable characters when comparing strings more clearly if the
comparison fails, this is notably useful for strings containing NULs as
they were previously completely lost.
wx-config didn't report -lwxscintilla for `wx-config --libs stc` in static
monolithic build.
Since stc is a part of monolithic lib, -lwxscintilla will be reported
for `wx-config --libs` now as well.
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.
