This is not really an option as building requires it to be 1, so don't
make it one in setup.h/configure/cmake and just hardcode it as 1 for
compatibility.
Closes#18558.
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.
Including <winsock.h> and <winsock2.h> is incompatible and if the
application wants to use the latter, it may be convenient to define
wxUSE_WINSOCK2 when building wxWidgets instead of having to work around
winsock.h implicit inclusion from include/wx/msw/wrapwin.h.
Closes https://github.com/wxWidgets/wxWidgets/pull/1122
Prepare for using liblzma in wxWidgets code by adding the necessary
option and updating the configure check for it (which had been already
present due to libtiff possible dependency on liblzma).
No real changes yet.
Commit bc13119494 removed the inclusion of
xlocale.h because it is not (and never was) needed under Linux with
glibc, but it is still needed under macOS, so this (silently) disabled
wxXLocale support under Mac when using configure and broke the build
when using cmake.
Fix both problems by using xlocale.h only if it's available, both in
configure and in cmake.
Add autoconf and bakefile support for detecting and using GTK+4, similar
to how GTK+3 is detected and used.
GTK+3 is checked for first before GTK+4, this can be overridden in
`./configure` using `--with-gtk=4`.
With GTK+4 the `__WXGTK4__` `#define` is also set in `setup.h.in`.
This commit does not regenerate any files.
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.
Handle this feature as all the other ones and provide a configure switch
and a setup.h option to disable it if necessary, as it may be desirable
to do it, especially under Linux, to avoid extra dependency on pangoft2
if this functionality is unnecessary.
FcConfigAppFontAddFile() that we use is only available since 2.8, so
check for at least this version of the library in configure.
Also change the macro guarding its use to the more semantically
appropriate "wxHAVE" rather than "wxUSE" and make it more precise by
adding "2_8_0" suffix to it.
This function tries to determine the preferred first day of week to use in
calendars. The procedure for obtaining this information is highly
platform-dependent, and is not possible on all platforms; in that case
Sunday is used as the fallback value.
Implementations are included for MSW, OSX, and Linux.
While we have to keep these conversions enabled by default, they are very
dangerous as they can result in silent data loss on any system not using a
locale with UTF-8 encoding, i.e. always under MSW.
Allow mitigating this by defining wxNO_UNSAFE_WXSTRING_CONV when compiling the
application code using the library, which makes these conversions invisible to
the user code, and so can be used without recompiling the library.
Also add wxUSE_UNSAFE_WXSTRING_CONV which can be set to 0 when compiling the
library to disable these conversions globally for all applications using it.
Closes#11830.
Undo the apparently manual change to setup.h.in in
8b5387bc3d by regenerating it.
Notice that this doesn't actually change anything as wxUSE_ACCESSIBILITY will
be correctly set to 1 by configure by default, but doing this avoids having
unrelated changes in the future commits.
Compile accessibility support on Windows by default now that the generic
wxDataViewCtrl control implements accessible interface. After the
changes from 7dab555f71, accessibility
support is much more lightweight and doesn't interfere with normal win32
behavior, so this change shouldn't affect accessibility-unaware code in
any way.
QTKit has been removed from OS X 10.12 SDK.
QTKit has been superseded by AVFoundation since OS X 10.7.
Since wxWidgets >= 3.1 requires 10.7 anyway there is no reason to support the old API.
Additionally the AVFoundation implementation may use AVKit (available since 10.9). It will be used when available and the deployment target is met.
Closes https://github.com/wxWidgets/wxWidgets/pull/337
Since OS X Sierra 10.12 QTKit has been removed. wxMediaCtrl for OS X already had a fallback to AVFoundation implemented. This makes sure this will be used and the correct media Frameworks are used for linking.
Add a new class allowing to store passwords and other sensitive information
using the OS-provided facilities.
Add implementations for all the main platforms, documentation and a new sample
(which contains an ad hoc unit test as the real unit test for this class would
probably be a bad idea as it wouldn't run in non-interactive contexts and
could show OS level dialog boxes if it did).
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.
Changes of d053a90486 only updated the generated
wx/msw/setup0.h file but not the file wx/msw/setup_inc.h from which it is
generated and so would have been lost after the next modification to the
latter.
Modify the latter one too to ensure that the changes stick.
See https://github.com/wxWidgets/wxWidgets/pull/238
Some Windows8+ APIs are only accessible via WinRT which is based on COM. However there are a few dependencies to get to the interfaces via functions defined in roapi.h. Using RoInitialize, RoUninitialize, etc. directly from it's windows headers adds dependencies to the WinRT dlls leaving the resulting exe unable to launch on earlier Windows versions. The wxWinRT functions wrap this with dynamic loading. Additionally wxWinRT::TempStringRef adds a convenient wrapper to HSTRING which is used extensively in WinRT APIs.
This symbol was wrongly added to include/wx/msw/setup0.h directly in
075ef6551e, so it didn't work when
cross-compiling from Unix (which doesn't use this file) and would have been
lost after any future modification of include/wx/setup_inc.h where it should
have been added in the first place.
Do this now and also make the check for this symbol in wx/progdlg.h a bit more
readable.
This constant wasn't very useful as it contained the description of the OS on
the machine where the library was built, not the one on which the application
using it was running. It also wasn't used anywhere in wxWidgets and apparently
wasn't meant to be used outside of it.
Finally, putting the output of `uname -r` into it created problems with
creating reproducible builds as just a change in the kernel version changed
the build results.
Closes#17002.
This is a simple animated control indicating some program activity.
Provide native GTK+ (for > 2.20) and OS X implementations as well as a generic
one used under MSW.
Update the sample and the documentation.
Use AC_CACHE_CHECK() to avoid recompiling the test program(s) every time
configure runs and also simplify the checks. This required renaming
ac_wxgtkXXX to wx_cv_gtkXXX (cached variables must have "cv" in them).
Also make the checks more logical, by simply setting wx_cv_gtkXXX if
wx_cv_gtkYYY is set with XXX < YYY.
Finally, and the real reason for these changes, add test for __WXGTK220__
which will be used by the upcoming commits to check whether GtkSpinner is
available.
This is a simple high level helper combining an arbitrary control showing
multiple items with the buttons allowing to add items to and remove items from
this control, but using the buttons and the layout appropriate for the current
platform.
Add the implementation itself, an example of using it to the dialogs sample
and the documentation.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78462 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This didn't do (almost) anything, so just remove it, using MFC and wxWidgets
together works just fine without it.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78277 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This option, which is on by default unless the use of STL is disabled,
provides better interoperability with the standard library when it can be done
without breaking backwards compatibility.
The first example of its use is to allow passing std::vector<> of any string
compatible type to wxItemContainer::Append(), Insert() and Set(), allowing to
directly initialize various wxControls deriving from it such as wxChoice,
wxComboBox, wxListBox from a std::vector<> of strings.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78066 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Define it and wxUSE_GRAPHICS_DIRECT2D, when it's supposed to be enabled, as
wxUSE_GRAPHICS_CONTEXT instead. This ensures they are set to 0 if the use of
wxGraphicsContext is entirely disabled, as is the case when using MinGW under
MSW by default for example.
Closes#16558.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77711 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Define it in wx/msw/setup_inc.h and not in wx/msw/setup0.h itself to ensure
that it survives the regeneration of this file using build/update-setup-h.
Also only set wxUSE_GRAPHICS_DIRECT2D to 1 for VC10+ and not VC9 as the latter
lacks Direct2D header in its default SDK version.
Finally also update comments to explain the various settings more clearly and
remove outdated information (wxGraphicsContext is not experimental any more).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77669 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This compiler is not being developed since several years and almost certainly
can't be used to build the current wxWidgets sources anyhow, so remove all
support for it, including a lot of extremely ugly workarounds for its bugs
with template functions.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76546 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Most importantly, this allows us to remove all MSLU-related stuff.
Some functions which were previously loaded dynamically can now be just used
directly, too.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76535 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This port is not used and is not being worked on, so remove it to reduce the
amount of the code which needs to be updated for every global change.
Also remove tests for VisualAge compiler which isn't used since ages.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76533 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't support this compiler any more, this allows to get rid of tons of
MSVC6-specific workarounds, in particular we can now use Bind() and natural
template functions calls in the library code.
Also remove MSVC6 project and solution files and don't generate them when
bakefile_gen is ran any more (removing the remaining occurrences of msvc6prj
from the bakefiles results in weird bake-time errors, so it's simpler to just
leave them there).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76532 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Detect its support in the code by testing __cplusplus value and using specific
checks for MSVC and Clang as configure detects it as being available when
using recent g++ versions in non-C++11 mode, which do support this keyword but
warn when it is used without -std={gnu,c}++11 option, which makes actually
using it a bad idea in this case.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76174 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Make overriding virtual methods more explicit and enable additional checks
provided by C++11 compilers when "override" is used.
Closes#16100.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76173 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
