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
Complete support for fractional point sizes and font weights other than
light/bold.
Also harmonize wxFont API and implementation among all ports (fixing
compilation of those of them that were broken by recent changes).
See https://github.com/wxWidgets/wxWidgets/pull/919
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
When using an out of source build, the files are not in the default wxWidgets directories.
Also search in the current directory, parent directory and sample sub-directories.
Closes https://trac.wxwidgets.org/ticket/18118
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.
Advanced gradients are drawn using wxGraphicsContext and hence bounding box for underlying wxDC is not updated automatically. We need to update bounding box with extents of all used graphics paths.
Determine actual size of drawing area and use it (instead of virtual size of the window) as a dimension of the images to be saved. Thanks to this clipping, produced images contain only results of drawing operations and not lot of empty background space.
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.
This adds an additional screen to the drawing sample showing all available wxSystemColour values. It makes sense for testing these values but also provides a convenient overview of available colours for the library user.
For some systems (like OS X, GTK+ 3) drawing with transparency is supporting by native wxDC and in this case "Alpha screen" sample can be shown even if wxGraphicsContext is not used/enabled. For such wxDC's all drawing operations can be done directly without using wxGraphicsContext.
Because graphics renderer is not only selected via menu but also directly in the application (in MyFrame::OnShow) there is necessary to update menu items responsible for selecting graphics context to represent current state of the application.
This is done in EVT_UPDATE_UI handlers where there is checked what graphics renderer is currently in use and state of the menu items is updated accordingly.
Closes#16971.
It was confusing to not see anything when selecting one of the screens using
wxGraphicsRenderer if a renderer hadn't been selected from the menu before.
Switch to using wxGC automatically now if one of these screens selected and
there was no previously selected renderer.
Explicitly include $(BCCDIR)/include/windows/sdk directory in the resource
compiler options, as it needs it to find windows.h.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77993 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
In particular, allow switching between GDI+ and Direct2D under Windows, which
is very convenient for comparing the rendering results.
This can also be useful when using Cairo.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77692 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
No real changes, just make the "File" menu (which was also renamed to
"Drawing" as it has nothing to do with files) less long by splitting off the
screen selection in a separate menu.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77691 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is not only wasteful, but creating a Direct2D surface associated with a
wxDC makes it impossible to paint on the DC using GDI functions, so this
completely broke the initial display in the sample.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77690 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This shows inconsistency in handling of radial gradients with and without
stops in current wxMSW GDI+-based wxGraphicsContext implementation.
See #16443.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77473 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This merges in the latest sources from GSoC 2014 wxQt project with just a few
minor corrections, mostly undoing wrong changes to common files in that branch
(results of a previous bad merge?) and getting rid of whitespace-only changes.
Also remove debug logging from wxGrid.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77455 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
