All still supported versions of MinGW/Cygwin provide w32api.h file, so
there is no need to test for it.
This allows to simplify the code, but also remove the definition of
HAVE_W32API_H from bake- and makefiles and this, in turn, allows to get
rid of extra flags in MinGW format entirely, as we don't support gcc
2.95 for which they were originally needed neither.
Put linker flags determined by configure after -L$(LIBDIRNAME) option
pointing to the directory containing the libraries being built, to
ensure that we link with these libraries rather than any wx libraries
globally installed in the system, as could be the case since the changes
of ec091c9f2b (Don't override CFLAGS etc in configure-generated
makefile, 2020-02-02).
See #18729.
CPPFLAGS, CFLAGS, CXXFLAGS and LDFLAGS are supposed to be under
user-control and putting configure-determined options in them broke
something as simple as running "make CXXFLAGS=-Wno-some-extra-warning"
because this overrode the CXXFLAGS set by configure and required for
build.
Improve this by using WX_*FLAGS in the generated makefile and leaving
the user-controlled FLAGS alone. This is still not ideal as running
"configure CFLAGS=-DFOO" and then "make CFLAGS=-DBAR" will define both
FOO and BAR, as configure copies CFLAGS to WX_CFLAGS, and so setting it
on make command line won't override it, as it should, but this should be
a much more rare and also much less severe problem, so we should be able
to live with it for now.
Normally this commit shouldn't result in any user-visible changes, i.e.
it shouldn't break any previously working scenarios and only make some
previously broken ones work.
Done by running misc/scripts/inc_release, manually updating version.bkl,
rebaking and rerunning autoconf.
Also a header for the next version to the change log.
During the samples-wide removal of obsolete wxT macros in
f58ea62596, the macros were
accidentally removed also from the place where they were required
(string literal casted to void* and then retrieved as wxChar*). This led
to names for m_tab and m_enter controls displayed wrong when logging
text events.
Fix this by restoring wxS() in this particular place.
See https://github.com/wxWidgets/wxWidgets/pull/945
Closes https://github.com/wxWidgets/wxWidgets/pull/1226
Pass wxStrings directly to wxString::Format("%s") and similar
pseudo-vararg functions, there is no need for c_str() there since
wxWidgets 2.9.
Closes https://github.com/wxWidgets/wxWidgets/pull/1009
The use of wxS() is an optimization which can be used to avoid an
implicit conversion from narrow to wide strings, but such optimizations
are not really needed in the samples and just make their code less
readable, so remove them.
Closes https://github.com/wxWidgets/wxWidgets/pull/956
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
This undocumented "private" class was used for various windows UxTheme
functions which are available since WinXP. As wxWidgets 3.1 is XP+ it
does not make sense anymore to load the theme functions dynamically.
In addition to showing the position returned by HitTest(), also show its
return value which is not necessarily wxTE_HT_ON_TEXT if it is not
wxTE_HT_UNKNOWN under MSW.
Passing long argument to "%c" printf format specifier was correctly
flagged as invalid in 64 bit Unix builds where long != int.
Fix this by just making the "keycode" variable int in the first place,
there doesn't seem to be any reason whatsoever for it to be long and
this allows us to get rid of a couple of existing casts instead of
adding yet another one.
This library is now required when wxUSE_ACCESSIBILITY==1, but was only linked,
using a compiler-specific pragma, when using MSVC resulting in link errors
with gcc.
Fix this by adding the library to the bakefile for non-MSVC compilers and
rebaking.
There is no way to show the hint without native support in a control with
wxTE_PASSWORD style, so simply ignore them completely in this case.
Closes#17078.
Update misc/scripts/inc_release script: remove non-existent any more files and
update the version in the MSVS 200x project files not generated by bakefile
any more and MSVS 201x project files which were not previously taken into
account.
Run it and rebake.
Allow automatically converting lower-case letters entered into wxTextCtrl to
upper-case equivalents. Provide generic fallback and implement the method
natively for all the major platforms.
Also update the text sample to show it in action.
This style was unconditionally used for all multiline controls for some
reason, meaning that wxEVT_TEXT_ENTER could be received even for the controls
not using wxTE_PROCESS_ENTER explicitly, which was unexpected.
Don't do this any more to conform to the expected behaviour.
Also do use wxTE_PROCESS_ENTER for the text control supposed to allow handling
"Enter" in the text sample: surprisingly, it didn't have this style before,
although it was clearly supposed to.
Closes#1913.
This might indicate a bug with the default size being too small for wxTextCtrl
in wxOSX, but without this change the control was barely big enough to show
one line of text under OS X 10.8, so make it bigger to have a more reasonable
initial appearance.
Dragging the mouse (even accidentally by a pixel or two) resulted in a
confusing "Unknown event" line in the log, so don't log these messages neither
just as we already don't log the mouse motion events.
Don't prevent people from using hints in wxMSW and wxGTK2, where they work
with multiline text controls too, even though they do not work with wxGTK3 nor
wxOSX.
Closes#14456.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78316 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
