wxFrameBase code unintentionally excluded the function generating
wxUpdateUIEvents for the menus from compilation when wxUSE_STATUSBAR was
turned off.
Move OnMenuOpen() out of #if wxUSE_STATUSBAR section to ensure that it's
compiled whenever wxUSE_MENUS==1.
Closes#17553.
Correct the search to completely match the full header name and not only
its beginning by appending ": " to the specified search string.
This prevents GetHeaderValue("Language") from returning "eam: wxWidgets team"
if there is a "Language-Team" header in the catalog, for example.
Closes#17555.
No real changes, just add a new platform-specific NewImpl() method instead of
making wxSecretValue ctor itself platform-specific.
This makes adding other ctors for this class simpler.
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).
To handle properly all combinations of the start and end angles and to ensure consistency with Cairo renderer behaviour there is necessary:
1. To normalize angle values the same way as it is done in Cairo.
and
2. When end angle equals start angle then actually no arc should be added but current point of the path has to be updated.
3. When difference between end angle and start angle >= 2*pi then in addition to the arc itself also one or more full circles have to be added to the path.
Closes#17558
To handle properly all combinations of the start and end angles and to ensure consistency with Cairo renderer behaviour there is necessary
1. To normalize angle values the same way as it is done in Cairo.
and
2. When difference between end angle and start angle >= 2*pi then in addition to the arc itself also one or more full circles have to be added to the path.
See #17558
See #17557
Since 202f62b4c4 x64 configurations exist
for MSVC 8 and 9 projects. Because MSVC 7 is the minimal supported
version, and doesn't support 64-bit builds, remove the section in
install.txt about x64 configurations being available only in MSVC 10
project files and later.
There are straightforward ways to draw rectangles, circles and ellipses using native methods provided by Cairo renderer and they should be used instead of generic implementations.
See #17554
Since for some renderers circles and/or ellipses are basic figures so it would be worth to test the performance of drawing them.
Respective tests are enabled with new command line options: "--circles" or "--ellipses".
Since there are several graphics renderers available under wxMSW it would be good to have ability to test graphics performance of any of them and not only the performance of default one.
Therefore new feature to run the tests with selected graphics renderer has been implemented in the benchmark application. Renderer can be selected with optional command line option: "/r renderer_name", when `renderer_name` can be either gdiplus, direct2d, cairo.
When no renderer is explicitly selected then default renderer is used.
The hack used in cc774bb301 to include some
standard headers after undefining __STRICT_ANSI__ doesn't work when
precompiled headers are used because the headers had been already included
from wx/wxprec.h then.
So instead bite the bullet and just reproduce MinGW stdlib.h declarations to
define "environ" ourselves, it's not that bad and hopefully won't need much
maintenance as later versions won't need the strict ANSI workarounds at all.
As for tzset(), wxDECL_FOR_STRICT_MINGW32() can be used for it without any
problems at all, not sure why hasn't it been done like this since the
beginning.
See #16984.
This function is not present in older MinGW import libraries, up to at least
MinGW 4.8.1, so we can't use it directly as it was done in
22f0801378 and we need to load it dynamically.
This was already done in wxDC code, so just reuse the same wrapper function
after extracting it (and a few others, for consistency) into a new header.
On OS X at least, the user is free to customize numbers formatting rules
and use more than one character for separators. Don’t assert in such
cases (the rules are untrusted input), but instead fall back to
something reasonable, as is already done if we can’t retrieve the rules.
Reworked calculations of the center of the arc and start/end angles of the arc to get correct results for any spatial orientation of starting and ending lines.
Closes#17552
Modified calculations of sweep angle to get its correct value for all combinations of start/end angle values and clockwise/counter-clockwise drawing.
See #17552
In addition to copying the underlying geometry sink itself also auxiliary data, like collection of transformed geometries and positional data have to copied the the new wxD2DPathData instance.
Because wxGraphicsPath comprises current ID2D1PathGeometry object and the collection of transformed (sub-)geometries (ID2D1TransformedGeometry objects) so to concatenate two paths we need to concatenate their current geometries as well as to combine the collections of transformed geometries.
Unfortunately, it seems that this is not a straightforward method to apply transformation to the current underlying path geometry (ID2D1PathGeometry object) "in-place" (ie. transform it and use for further graphics operations). Some simple methods offered by Direct2D are not useful for these purposes:
1. ID2D1Factory::CreateTransformedGeometry() converts ID2D1PathGeometry object to ID2D1TransformedGeometry object and ID2D1TransformedGeometry inherits from ID2D1Geometry (not from ID2D1PathGeometry) and cannot be used for path operations.
2. ID2D1Geometry::CombineWithGeometry() which could be used to get final geometry by combining empty geometry with transformed geometry doesn't offer any combine mode which would produce a "sum" of geometries (D2D1_COMBINE_MODE_UNION gives kind of outline). Moreover the result is stored in ID2D1SimplifiedGeometrySink not in ID2DGeometrySink.
So, it seems that ability to transform the wxGraphicsPath (even several times) and still use it after this operation(s) can be achieved by using a geometry group object (ID2D1GeometryGroup) this way:
1. After applying transformation to the current path geometry with ID2D1Factory::CreateTransformedGeometry() the result is stored in the collection of transformed geometries (an auxiliary array) and after that a new (empty) geometry is open (in the same state as just closed one) and this geometry is used as a current one for further graphics operations.
2. Above steps are done at every transformation so our effective geometry will be a superposition of all previously transformed geometries stored in the collection (array) and the current operational geometry.
3. If there is necessary to use this combined effective geometry in any operation then ID2D1GeometryGroup created with ID2D1Factory::CreateGeometryGroup() from the collection of stored geometries will act as a proxy geometry.
Closes#17549
A GTK+ bug involving GtkHandleBox somehow prevents drawing of its child
since 3.19.7. Avoid this by disabling the docking functionality, which
is preferable to having the bar be blank.
See #17539
This just checks that pressing a key with "Alt" modifier can be used to open a
menu and that pressing the menu item letter then selects an item from it.
Scale the coordinates passed to MouseMove() by the GTK scaling factor to
ensure that the mouse clicks are really delivered to the correct windows,
without this change wxUIActionSimulator was unusable on systems using high DPI
(i.e. GDK_SCALE of 2).
Per-monitor DPI scaling is still not supported however.
Adding a call to XSync() to wxUIActionSimulatorX11Impl seems to fix the
problems with the focus snapping back to the control having it previously
after simulating a mouse click and changing the focus afterwards using
wxWindow::SetFocus(), as the uiaction sample did.
Admittedly, it's not really clear why does doing it help, but at the very
leasy this XSync() call shouldn't do any harm.
Choose between wxUIActionSimulatorXTestImpl and
wxUIActionSimulatorPlainX11Impl dynamically, depending on whether XTest
extension is available during run-time or not.
Also decouple the two implementation to keep them clearly separated.
This is not a real move-ctor but std::auto_ptr<>-like "stealing" ctor. It
still allows to pass Display ownership to another function which is all that
is needed for our purposes.
Instead of opening connection to X display in every method, do it once in
ctor, as we can store the display across multiple calls after the recent
refactoring.
This does require allocating a separate "impl" object for each public object,
but should still be much less wasteful than opening and closing the display
connections all the time.
Extract platform-specific code in a wxUIActionSimulatorImpl-derived class
instead of keeping it in wxUIActionSimulator itself.
This will allow determining which implementation to use dynamically (i.e. at
run-time and not compile-time) to use later and already allows to get rid of
an __WXOSX__ #ifdef in common code.
The implementation using XSendEvent() with classic input events can't work
with GTK+ 3 anyhow because it uses XInput2 which is incompatible with them, so
warn the user about this and don't compile useless code into the library.
