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.
* changing datatransfer from CFPasteboard to NSPasteboard API
* factoring and cleaning up
* Switching back naming
* missed file
* getting wxCFStringRef to be independent of system headers
* add unichar include
* using wxCFStringRef in header
* moving to private headers, change method name
* adapting to lesser content in cfstring.h
* Removing malloc/free usage
* use wxScopedArray throughout
* using wxMemoryBuffer instead of char[]
* fixing nonprecomp headers
* missing forward decl in non-precomp builds
React to the WM_DPICHANGED event and update the size of the child windows and
the top-level window. Scale the minimum and maximum window size to the new DPI.
Only react to WM_DPICHANGED when DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 is
used.
This was only used in wxUniv, wxRA_SPECIFY_[COLS/ROWS] can be used instead.
Do not remove them from the definitions, to not break user code.
Closes#18100.
This is a preliminary ARM64 platform support for wxWidgets at "it
compiles" stage. This will allow building and testing wxWidgets based
apps for oncoming Windows 10 ARM64.
Requirements:
- Visual Studio 2017 Update 4 or later with Visual C++ compilers and
libraries for ARM64 component installed
Building:
1. Open command prompt.
2. Change directory to build\msw subfolder.
3. Run "C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Auxiliary\Build\vcvarsamd64_arm64.bat" once.
4. Use `nmake TARGET_CPU=ARM64 ...` to build required flavor of wxWidget
libraries.
Notes:
1. Building of *.sln/*.vcxproj files does not support ARM64 yet. This
requires to hardcode Windows SDK to 10.0.15063.0 or later in
*.vcxproj files, which would render them non-compilable in older
Visual Studio versions. Microsoft is aware of this issue and is
planning a fix in the next version of Visual Studio.
2. wxmsw31ud_gl.dll does not build yet. Awaiting Microsoft to deliver
missing opengl32.lib for ARM64. Please, specify USE_OPENGL=0.
Closes https://github.com/wxWidgets/wxWidgets/pull/923
These warnings are unavoidable in a few places, and testing for gcc
version and suppressing them is too verbose, so define helper macros
making it a bit less painful.
WNDPROC and FARPROC are not the same thing in MSW and it's wrong to use
WXFARPROC as the type of different window procedures we use.
Introduce WXWNDPROC which is more clear and correct and use it instead.
Also get rid of a few casts which are not necessary any longer.
MinGW compiler predefines WIN32, meaning that wx/msw/winundef.h was
always included from wx/defs.h, even when it was completely unnecessary.
This was just inefficient, but harmless, until the changes of
042d922e88 which broke MinGW compilation
as wxUSE_UNICODE_WINDOWS_H was incorrectly defined during the very first
inclusion of wx/msw/winundef.h, before _UNICODE could be defined
correctly by windows.h.
Fix this by checking whether windows.h was really already included.
When using configure, use the same family of hash sets/maps when
building wxWidgets and the applications using it as doing otherwise
results in ABI incompatibility.
Fix the problem with compiling user code including wx/debug.h as the
first wxWidgets header under MSW. This ought to work, but didn't,
because wx/debug.h included wx/chartype.h without including wx/defs.h
(because there is already an inclusion in the other direction), which
defines SIZEOF_WCHAR_T required by wx/chartype.h, first.
Notice that we repurpose the existing but completely unused (no mentions
of it or the symbols defined in it anywhere neither in wxWidgets nor in
any of the code search engines) wx/types.h header as it has a fitting
name and this avoids having to add a new header and remove the existing
one.
Fix compilation/link problems due to symbols redefinitions in user code
that could happen if it included some wx header first, then <windows.h>
(possibly indirectly, e.g. via another third party library) and then
another wx header -- in this case, the second wx header wasn't protected
from <windows.h> redefinitions resulting in all the usual problems.
Avoid this by always including winundef.h whenever any wx header is
included, not just when wx/defs.h is included for the first time.
* using fontAttributes dictionary allows for better emulation of bold typefaces, also switch to using color from context, this allows keeping the same dict throughout, as a side effect fix font caching
* reverting in order to maintain crossplatform compatibility
* applying review suggestions
* applying review suggestions
This makes sense and avoids an error if some other header sabotages our
__has_warning definition check by providing a dummy definition for it (as ICU
does, for whatever reason).
__USE_MINGW_ANSI_STDIO is apparently not defined when using MinGW as a
cross-compiler from Linux, so 7c730334a2
resulted in -Wundef warning about this.
Fix this by checking if the macro is defined before testing its value.
See #17736.
When using MinGW own, more standard-compliant, STDIO library, the correct
format specified to use for long long values is "%lld" and not "%I64d" as when
using MSVC CRT.
Closes#17736.
This is unnecessary as we know that we have them in C++11 mode and we can't
compile them in non-C++11 mode even if they exist.
Not doing it simplifies the code and works around a bug in clang 3.2.
Closes https://github.com/wxWidgets/wxWidgets/pull/247
This symbol is tested using "#if", so it should be always defined and there is
no need for testing whether this is the case.
Moreover, doing this useless check triggers warning C4574 (which is disabled
by default, but it's useful enough to enable it explicitly) with VC14 about
using "#ifdef" with a symbol defined as 0.
No real changes, just remove the nonsensical comment from wx/defs.h which
completely lost its meaning since wxWindowID typedef was replaced by a class 8
years ago in cf2810aa39.
In practice, almost everybody using validators also seems to use this style,
so make it the default (this hadn't been done when it was originally
introduced because of compatibility concerns, but now, 15+ years later, it's
probably safe enough to change this).
Cocoa has been the default toolkit in wxWidgets for a long time. There is really no good reason to use Carbon in 2016 and this removes a lot of unused and unmaintained code.
These constants were defined in the middle of the wxKeyCode enum, value-wise,
which made it difficult to end new elements to the enum as they could clash
with the existing ones if they were simply added at the end.
The added macros wxCLANG_WARNING_{SUPPRESS,RESTORE} are similar to
wxGCC_WARNING_{SUPPRESS,RESTORE}, but the `wxCLANG_' version will expand to
compiler pragmas only when the warning name is known to the compiler.
They use clang's __has_warning feature.
Windows CE doesn't seem to be supported by Microsoft any longer. Last CE
release was in early 2013 and the PocketPC and Smartphone targets supported by
wxWidgets are long gone.
The build files where already removed in an earlier cleanup this commit
removes all files, every #ifdef and all documentation regarding the Windows CE
support.
Closes https://github.com/wxWidgets/wxWidgets/pull/81
Its value (0x80000000) is outside of the int type range on 32 bit platforms,
but we still want to allow using it as an initializer of int and/or long
variables for consistency with the other types, so cast it to int explicitly
to suppress -Wnarrowing warnings from recent g++ which were given when doing
this before.
g++ 4.9.2 added support of __has_include() but, unlike clang, refuses to
compile the <type_traits> header that is detected as existing now in C++98
mode, so the build was broken with it when not using configure (i.e. under
MSW).
Fix this by, first, testing for C++11 compilers separately (which seems like a
good idea anyhow as it will allow using these headers with other compilers)
and, second, not trusting g++ __has_include() for C++11 headers in C++98 mode.
Make wxICON_WARNING and wxICON_ERROR the primary constants for their
purpose and define their visual Windows-based synonyms wxICON_HAND and
wxICON_EXCLAMATION in terms of the semantic ones, instead of the other
way around.
