Apply the appropriate style to any text being inserted, not just the text
added by the program. This not only fixes the bug with default style not being
used for the text entered by user, but also makes the code simpler.
Closes#17523.
When x- or y-coordinate of DC origin > 0 then surface created with cairo_win32_surface_create() is not fully operational (for some Cairo operations memory access violation errors occur - see Cairo bug 96482) so in this case we would need to apply a workaround and pass non-transformed DC to Cairo and next apply original DC transformation to the Cairo context operations on our own.
Closes#17564
When render target to draw to a DC (created with ID2D1Factory::CreateDCRenderTarget method) is bound to the device context with ID2D1DCRenderTarget::BindDC method then not only the logical size of a DC needs to be taken into account but also the origin of this DC.
To get proper drawing output the coordinates of all drawing operations should be internally adjusted by this initial origin.
This corrective translation should be used only internally by wxGraphicsContext object and shouldn't be exposed through e.g. GetTransform() function and therefore it is stored separately (in a dedicated variable) and "subtracted" from actual transformation settings for reporting purposes.
See #17564
Miscellaneous picker control related fixes, notably fix background and improve
small button size under MSW.
Also make wxSIZE_FORCE_EVENT really work in wxMSW and remove the now unneeded
src/msw/panel.cpp.
See https://github.com/wxWidgets/wxWidgets/pull/296
The ellipsis buttons of wxFilePickerCtrl (and similar controls) with
wxFLP_SMALL style looked too big because their min height was greater than
that of the accompanying text control.
Fix this by making the buttons as tall as text controls and not as tall as
standard buttons, this seems to be more aesthetically pleasing.
They just seem completely useless, not documented and only used by wxPickerBase
itself internally. Replace the code using them with wxSizerFlags which is more
clear and also doesn't hard code the border sizes (especially in the case of
the picker control which doesn't even have borders in the first place) and
prepare for removing them later.
A picker control could have a completely broken appearance if its size was
never changed from the initial size under MSW. For the picker controls inside
a sizer this was indirectly fixed by the previous commit ("Make
wxSIZE_FORCE_EVENT work if only position changed in wxMSW"), but the controls
not managed by a sizer still didn't come up correctly, so add an explicit
Layout() call to ensure they do.
If the position changed but the size didn't, we just call Win32 API for
updating the window geometry but it didn't generate WM_SIZE in this case, so
even when wxSIZE_FORCE_EVENT was used, no wxSizeEvent was sent.
This MSW-specific hack is actually needed by all windows containing more than
one control, even if they don't derive from wxPanel (which is just the most
commonly used class for such windows), otherwise the parts of the window not
covered by the child controls won't have the correct appearance when the
window itself is inside a wxNotebook.
So do this for all classes inheriting from wxNavigationEnabled<>, notably this
fixes the wrong background for all kinds of picker controls (wxDirPickerCtrl,
wxFilePickerCtrl, ...) when they're used inside a wxNotebook.
After moving this method out of wxPanel, src/msw/panel.cpp became empty, so
also delete it and remove it from {bake,make,project} files.
In AddRoundedRectangle() we know in advance (angle = 90 deg) or can easily determine (center point) parameters of all arcs at the vertices of the rectangle so instead of using AddArcToPoint() function which is generic and hence computationally expensive we can use AddArc() function which implementation is simpler and execution should be faster.
For the sake of compatibility with Cairo (and Direct2D) an initial line segment should be added to the path from the current point (if set) to the beginning of the arc.
Closes#17557
Vertical scrollbar didn't appear even when the number of lines in the control
became one greater than the maximal fitting number of lines, but only when one
more line was added.
This seems to have been a simple off-by-one error in SetScrollbar() calls, so
fix this by adding 1 to the upper end of the range.
Closes#17548.
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
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
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
