This library doesn't really exist any more and is preserved only for
compatibility, there is no need to have dependencies on it, just depend
on "core" instead.
This fixes sporadic errors when building DLL configurations as the html
library build could have been still in progress when xrc library,
requiring it, was linked.
Reverting the commits broke indentation, which resulted in
-Wmisleading-indentation from (recent) gcc, so fix it by indenting the
restored "if" properly.
See #13130.
Use "new" (available since 10.5, for most part) values of the enum
instead of the deprecated ones, which are still defined, but might not
be in the future.
No real changes.
Call CTFontCreateUIFontForLanguage() only once for every
CTFontUIFontType value and cache the results, as it is expensive to do
it every time wxSystemSettings::GetFont() is called.
Closes#19191.
This commit is best viewed ignoring whitespace-only changes.
Revert both 53eff92ea7 (Call AdjustForBitmapMargins() only once in
wxAnyButton, 2021-04-24), which was completely wrong and was due to not
reading the code attentively enough, and the subsequent 5d508b6e6 (Fix
regression in sizes of buttons with bitmaps in wxMSW, 2021-07-08) which
fixed the problem introduced by the first commit partly, but not
completely.
Closes#13130.
For some reason, we used "vc_x64_lib" as the output directory for the
libraries, but "vc_mswu_x64" as the output directory for the samples.
Place the arch suffix, i.e. "_x64" part, always after the compiler
prefix (possibly including version), for consistency with both the
library output directories and with MSBuild project files, as
build/msw/wx_setup.props uses $(wxCompilerPrefix)$(wxArchSuffix)_...
as wxIntRootDir value.
Add wxUILocale class providing functionality which can be implemented
portably for all major platforms, including macOS, and doesn't force
the change of the global C locale, unlike wxLocale.
See https://github.com/wxWidgets/wxWidgets/pull/2464
Use the colour directly in implementation class method and ensure that
we pass it the correct colour from wxWindow::SetForegroundColour()
itself.
This simplifies the logic a bit and avoids clang warning about unused
"col" parameter in wxWidgetCocoaImpl::SetForegroundColour().
Closes https://github.com/wxWidgets/wxWidgets/pull/2491
Note that this support is still incomplete, notably we don't have
*_vc17.sln files yet and the official build scripts haven't been updated
to build MSVS 2022 binaries neither.
There is nothing that can be done about the warnings saying that using
transform matrix is not supported for the given DC kind and it's not
going to change any time soon (i.e. implementing support for transform
matrix for wxSVGFileDC is not planned), but in the meanwhile it results
in a lot of useless output in the CI logs when running the tests, making
it difficult to find real problems in the test.
This commit is best viewed ignoring whitespace-only changes.
Include all extra libraries we need (except for OpenGL ones, as there is
still a separate library for it, even in monolithic build) in wx-config
--libs output for static monolithic build as the application (may) need
all of them, as all the libraries are part of the single monolithic one
in this case.
It seems that we had an attempt to fix this as far back as in 5719eab2bf
(Fix missing 3rd party builtin libs for static monolithic builds.,
2006-09-17), but it was insufficient as it didn't take the dependencies
of the other GUI libraries (e.g. "media") into account.
Closes#19175.
Make the lines colour less bright to avoid having too high contrast
between the lines and the background, notably in dark mode under macOS.
See #19116.
Although the compiler is already shown as part of the build signature,
it doesn't always show the exact compiler version used, which can be
useful as well, so add it here.
It was already disabled under AppVeyor and it also fails when using
GitHub Actions.
This almost certainly indicates that there is a bug in our code, but as
the failure still can't be reproduced locally, it's difficult to debug
and fix, so for now just also disable the test when using GitHub CI.
The condition guarding wxEVT_TEXT_URL test was changed to use
wxHAS_2CHAR_NEWLINES in 15c5125572 (Refactoring, 2021-08-07) but
shouldn't have been as this has nothing to do with the use of "\r\n"
under MSW.
No real changes.
Append the path to the directory containing the DLLs to PATH to allow
the tests to find them.
Also quote the value of the "Configuration" property as it may (and
does) contain spaces.
It seems inconsistent to have MSVS 2019 solution for the main library
itself, but only MSVS 2017 (and earlier) one(s) for the sample and the
tests, so add MSVS 2019 solution to them too.
Now that these Direct2D tests are compiled, disable those of them that
fail under Wine due to missing support for Direct2D functionality we use
in Wine implementation.
Don't even give a warning message because there would be too many of
them in these tests, just skip them silently.
This dialog is non-modal and so using GetParentForModalDialog() for it
is not quite right, because this function checks that the candidate
parent window is visible, which may not be the case for a modeless
dialog parent, as the dialog isn't necessarily going to be shown
immediately, but may well be shown later, after showing its parent.
And not allowing to use the not yet shown parent was also inconsistent
with the native MSW version which didn't have any problem with this.
So fix this by adding new GetParentForModelessDialog() function and
using it for this modeless dialog instead. This required slightly
refactoring wxDialog code to allow reusing most of it between the old
GetParentForModalDialog() and the new function.
Check for Direct2D headers (only, as DLLs are loaded during run-time
anyhow) and enable Direct2D-based wxGraphicsContext implementation if
they are available when building wxMSW with configure.
This is more consistent with EnableProofCheck() and allows to retrieve
the current state of grammar checking under macOS, which can be checked
by user and so can be useful to know.
There doesn't seem to be any need to have these functions here as the
base class implementation already does exactly the same thing (i.e.
nothing at all).
