Fix the bug introduced in ec0734f96f (Install DLLs in bindir, not
libdir, when using MSW toolchains, 2021-01-09): the directory where the
DLLs were installed wasn't created any more, resulting in errors if it
didn't exist.
Update to latest bakefile version adding the missing mkdir command to
fix this and also use a released bakefile version for the wx makefiles.
Regenerate configure to match the new version.
See #14601.
The year is now included in the copyright string used in the makefiles
and so they need to be regenerated every time the year changes (which
happens surprisingly frequently).
It would be better to define a single variable with the year number to
avoid having to do this in the future.
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.
Simply remove the not existent any longer shared-ld-sh from clean
targets in all makefile.
This should have been done in e663d9af2b (Stop using shared-ld wrapper
script under Mac, 2021-07-06).
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.
This is a more hackish but more compatible solution to the problem of
data sent using wxIPC_UTF8TEXT format being simply lost when using DDE
for IPC classes. We must use CF_TEXT for the DDE to pass our data, but
we can try to decode it as UTF-8 in the client and assume it was sent in
this format if it worked. This obviously suffers from false positives as
any ASCII string will still be assumed to be UTF-8, but there shouldn't
be any real harm coming from this.
This change also makes sending data in wxIPC_UTF{16,32}TEXT formats work
as well by converting it to UTF-8.
Update the sample to call Advise() with both wxIPC_UTF{8,16}TEXT formats
and remove the now unnecessary wxDDEConnection::m_dataType member.
Closes#17900.
This reverts commit c657fd3d61 because
changing the format of DDE advise requests/replies is not a good idea:
other applications (those using previous versions of wxWidgets or even
not using wxWidgets at all) may rely on getting data in real CF_TEXT
format rather than in one of text formats preceded by the extra byte
containing the actual format and the previous commit would have silently
broken this.
Another fix for #17900 will be implemented instead.
wxIPC API doesn't map well onto DDE, as we don't have wxIPCFormat
parameter in StartAdvise() but do allow specifying the format when
calling Advise() itself, whereas DDE requires specifying the format when
establishing the advise loop and the data always must use this format
later.
Because of this, we have to pass the actual format with the data itself
instead of relying on DDE formats support. This has the advantage of
allowing wxIPC_UTF8TEXT to work, while previously it didn't and
couldn't, as DDE only supports the standard (or custom, but registered)
clipboard formats and it wasn't one of them. Of course, this also has a
disadvantage of having to make another copy of the data, but this seems
unavoidable.
This change allow Advise() overload taking wxString to work, including
for non-ASCII strings, as shown by the update to the IPC sample. It also
makes wxDDEConnection::m_dataType unnecessary, as we must always use the
format passed to DDE callback anyhow when handling XTYP_ADVREQ.
Closes#17900.
DDE code translates wxIPC_PRIVATE to wxIPC_TEXT internally since a
change done in 9d86099269, but same commit
also added a warning to the ipc sample stating that wxIPC_PRIVATE
doesn't work, which isn't really the case.
Remove the warning to avoid the confusion.
See #7470.
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
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
Still use Connect() in unit tests which were written explicitly for it
and in EventConnector, which can't use Bind() as it uses a variable for
the event type.
No real changes, just use the newer and more convenient function.
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.
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.
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.
"%d" can't be used for size_t which may be of greater size than int, so use
"%lu" with a cast to unsigned long, as is done elsewhere because "%z" is
unfortunately not portable.
Closes#17255.
