Just returning false is enough, there is no need to log a debug message as
well.
Also simplify the logic of this function a little by always returning true at
the end and returning false before on failure.
Closes#13759.
This merges a branch with a (slightly tweaked to apply) copy of the
cve-2016-0718-fix-2-2-1 branch from the official Expat repository at
https://sourceforge.net/p/expat/code_git/
On Gtk and OS X, but unfortunately not MSW, an assert fails if a
wxFileSystemWatcher is created too early. Therefore give a hint about
where and when one should be created.
Closes https://github.com/wxWidgets/wxWidgets/pull/287
The headers for this compiler, at least in the version packaged under Debian,
define BCN_DROPDOWN but not the NMBCDROPDOWN struct we also need, so we have
no choice but to redeclare the struct ourselves to allow this code to compile.
For some reason, "long" was used for window coordinates even though they're
really "int", and implicitly converting from the former to the latter resulted
in warnings in user code including this header with e.g. Apple clang.
Just use int to avoid conversions.
Selecting a leaf node in a wxDataViewCtrl and then pressing the right arrow
key resulted in using an out-of-bounds index for accessing the columns list.
Fix this by setting the current column to the first one, and not to the second
one which might not exist.
Closes#17537.
std::isnan() is always available when using C++11, so just use it.
Also pout the test for C++11 implementations of both wxIsNaN() and wxFinite()
first, eventually the rest of the checks will become obsolete and will be
removed.
Closes https://github.com/wxWidgets/wxWidgets/pull/283
Ensure the proper class hierarchy in wxGTK, this notably allows to override
SetValue() in classes derived from wxGauge, which didn't work in wxGTK (but
did in wxMSW and wxOSX) before.
Also remove the now unnecessary IsVertical().
When using the keyboard to select an item by typing the first characters of
its name, we need to make the item visible in addition to selecting it.
Closes#16336.
Since only geometry with closed sink (immutable) can be transferred to another geometry object with ID2D1PathGeometry::Stream() so we have to check if actual transfer succeeded and return NULL if not.
To ensure compatibility with Cairo renderer the new sub-path should be started at the joined endpoint of the current (just closed) sub-path.
Closes#17532
Because only ID2D1PathGeometry with closed sink (in the immutable state) can be transferred to another geometry object with ID2D1PathGeometry::Stream() so appending one wxGraphicsPath to another has to be done with source path geometry in the non-writable state and closing this geometry has to be done prior to any other operation.
But we want source wxGraphicsPath to stay in the writable state after appending it to another path so we have to prepare a writable copy of the source ID2D1PathGeometry and assign it to the source wxGraphicPath after the appending.
See #17532
Cairo renderer places MOVE_TO element into the path immediately after after the CLOSE_PATH element so to ensure that GDI+ will behave in the same way the new sub-path should be started at the joined endpoint of the current just closed sub-path.
See #17532
Since resulting wxGraphicPath should have the same state as appended path so we have to grab in wxGraphicsPath::AddPath also auxiliary data from appended wxGraphicsPath.
See #17532
When current point is not set before the call to wxGraphicsPath::AddCurveToPoint() then it should be set at first control point prior to adding a curve (function should behave as if preceded by MoveToPoint).
Closes#17526
When current point is not set before the call to wxGraphicsPath::AddCurveToPoint() then it should be set at first control point prior to adding a curve (function should behave as if preceded by MoveToPoint).
See #17526
When current point is not yet set then wxGraphicsPath::AddLineToPoint() should behave as MoveToPoint(). We have to determine whether current point is set or not using additional flag because native renderer doesn't provide any support regarding this matter.
See #17525
If there is necessary to start a new D2D figure prior to appending a curve to the path then this new figure should be started at the current point and not always at (0,0).
Closes#17521
When sub-path is closed with CloseSubpath() then current point should be moved to the joined endpoint of the sub-path (what is equivalent of moving it to the starting point of the sub-path). Native CloseFigure() doesn't move the native current point to the starting point of the figure so we need to maintain it on our own in this case.
To implement this behaviour we need to store the starting point of the figure in a dedicate data member and use it to update the current point when the figure is closed.
But native GDI+ renderer doesn't offer any support for updating directly the current point (only explicit drawing operations update its value) so we need also to remember our "logical" current point (being the result of calling CloseSubPath, MoveToPoint, etc.) in a dedicated data member and use it instead of the native current point in the next operation which requires current point location.
Closes#17520
When sub-path is closed with CloseSubpath() then current point should be moved to the joined endpoint of the sub-path (what is equivalent of moving it to the starting point of the sub-path). To implement this behaviour we need to store on our own the starting point of the figure in a dedicate data member because native D2D renderer apparently doesn't offer any support for retrieving it.
See #17520
If there is necessary to start a new D2D figure prior to appending the line to the path it should be started at the current point and not always at (0,0).
See #17520
Circle/ellipse should be appended as a closed sub-path and the current point after the operation should be moved to "the rightmost point" of the figure ((x+r,y) and (x+w,y+h/2) respectively).
See #17520
