Scintilla conversions use UTF-16, as indicated by their names, while wxString
uses UTF-32 under Unix, so they don't work correctly for the characters
outside of BMP.
Simply use our own UTF-8 conversions, it doesn't seem possible to get invalid
UTF-8 sequences here anyhow, so the comment saying that Scintilla functions
are used to avoid asserts doesn't seem to be relevant.
Closes#15621.
The function such as fn_str(), wc_str(), and ToAscii() have
configuration-dependent return types, yet different variants were claimed to
be member function overloads. This is incorrect, as a member function cannot
be overloaded only by its return type and, for any given platform/build
variant only one of them is available.
Closes https://github.com/wxWidgets/wxWidgets/pull/260
32bpp wxBitmaps selected into wxMemoryDC can represent either 0RGB or ARGB bitmaps and hence there is necessary to instruct renderer how to interpret 32bpp contents while creating a wxGraphicsContext. wxBitmap::HasAlpha() flag is used for these purposes and its value is passed to wxD2DContext ctor (wxD2DContext is used internally as a backend D2D component) and next used to configure physical renderer created with ID2D1Factory::CreateDCRenderTarget.
Closes#17465.
cairo_surface_create_similar_image() introduced by the changes of
d6afb66388 is only available in 1.12 and later,
check for it being available and fall back to cairo_surface_create_similar()
with older versions.
This should fix Travis CI builds.
Not onlu has Scintilla no support for RTL languages, it is rendered into
a mirrored DC on Windows and so guaranteed unreadable and unsable. Fix
it by explicitly setting the window's layout direction to LTR.
Fixed creating wxCairoBitmapData from 32bpp wxBitmap (with and without alpha channel). This also fixes wxCairoRenderer::CreateBitmap method.
1. 32bpp bitmap can represent under MSW either ARGB or RGB bitmap so there is necessary to examine its real contents with wxBitmap::HasAlpha function.
2. ARGB bitmaps are premultiplied and there is not necessary to premultiply them again.
There is nothing we can do about these (harmless) warnings, so just
disable them. Also make sure that the header is included via
wx/msw/wrapshl.h everywhere.
The check added in 841af56084 was not good
enough, some MinGW versions do have imagehlp.h, but don't define all the API
functions we need in it. Luckily, we can check for this simply by verifying
that API_VERSION_NUMBER is big enough.
Closes#17451.
There is no need to handle Carbon port any more, so simplify the script and
just append the Cocoa-specific tags to the main tags file instead of creating
another one.
Refresh(&rect) was used instead of Refresh(true, &rect) mistakenly, thanks to
clang for warning about always-true-conversion-to-bool here.
Fix this by using less error-prone and more clear RefreshRect().
AX_CXX_COMPILE_STDCXX() macro does not define HAVE_CXX11 when C++11 is
required (and not optional, as with --enable-cxx11), so the build was broken
when --with-cxx=11 was used under OS X as -stdlib=libc++ was not used.
Fix this and also leave only a single AX_CXX_COMPILE_STDCXX() check for C++11,
this saves us ~1000 lines in configure.
As we do it for MinGW now, do it also for MSVC in a similar way: this is more
straightforward and less annoying than raising an exception (which can be
caught by a debugger and, at least, is logged by it) and ensures we use
similar code for MinGW and MSVC which should hopefully minimizing the risk of
breaking one or the other without noticing in the future.
Normally there should be no changes in behaviour.
This class can be used even without SEH, provided debug help API is available,
so just make wxUSE_STACKWALKER dependent on wxUSE_DBGHELP instead of
unconditionally disabling it if SEH support is not available.
MinGW64 and TDM-GCC come with imagehlp.h and can compile the code using debug
help API too, so enable wxUSE_DBGHELP when using these compilers by default
and also allow enabling it via a configure option.
