In a wxFontEnumerator, if false is returned from OnFacename() or
OnFontEncoding(), the enumeration is supposed to stop. This was not happening
on wxGTK.
Closes https://github.com/wxWidgets/wxWidgets/pull/311
Currently region given in device coordinates is decomposed into the stripes which are next transformed to the logical coordinates required by underlying wxGraphicsContext::Clip() function. Some of these stripes given in device coordinates can have 1-pixel height what after transformation to logical coordinates can give zero-height stripes (after rounding). This can lead to the situation that in the region transformed to logical coordinates some stripes can disappear and final transformed region shape is different from the source shape (it has gaps).
To fix this issue device coordinates of the region are not manually transformed to the logical coordinates but instead wxGraphicsContext's is temporarily set to the state where its logical coordinates are equivalent to device coordinates and thus clipping region can be applied directly.
Closes#17609
When wxImage is rescaled with wxIMAGE_QUALITY_BILINEAR, wxIMAGE_QUALITY_BICUBIC or wxIMAGE_QUALITY_BOX_AVERAGE algorithm then for proper interpolation there is necessary to uniformly (linearly) map entire pixel range in the new image to the entire pixel range in the current image, i.e. pixels positions (integer values) in range [0..newDim-1] has to be mapped to "virtual" pixel positions (not necessary integer values) exactly in the range [0..oldDim-1].
[0..oldDim-1] range of target mapping is required because for proper interpolation every "virtual" pixel has to be located between two physical pixels in the current image.
Thus scaling ratio used to find corresponding pixels in the current image should be (oldDim-1)/(newDim-1) and not oldDim/newDim (which is used now).
When image is e.g. upsampled oldDim/newDim ratio then some new rightmost/botommost pixels are mapped to old pixels > (oldDim-1) and their values are improperly interpolated (in the current implementation their positions are just truncated to (oldDim-1) to bypass the problem and upsampled image looks like it was shifted left/up). The larger scaling ratio the effect is more visible.
Note:
Because reference images used currently in the unit tests were created with improper scaling there is necessary to upload new reference images created with fixed scaling.
Closes#17594
Because source wxRegion contains regions given in device coordinates and underlying wxGraphicsContext::Clip() function expects regions in logical coordinates so we have to convert device coordinates of all region components to source coordinates prior to calling this function.
Effective clipping box (always calculated in logical units) is the result of intersection of clipping box of the provided region with either clipping box of previously set clipping region (if set) or with wxGCDC surface extents if no clipping region is set. This way effective clipping box is always inside the wxGCDC surface.
Note: Effective clipping box can be an empty region.
See #17596
All versions of MinGW seem to have this function, so use it to ensure that
wxGetCwd() returns the correct result even when the current directory contains
non-ASCII characters.
Closes https://github.com/wxWidgets/wxWidgets/pull/307
Because wxDC can be the subject of geometric transformations (like translation, scaling) so we cannot assume in the calculations of the clipping box that DC origin is always at (0,0) and its logical size is the same as physical size. To get correct result we have to use logical coordinates of wxDC area in all clipping box calculations.
Graphics renderers accept negative clipping box size but for internal calculations done in wxDCImpl::DoSetClippingRegion() we need to have a box defined by (x,y) at top-left corner and having non-negative size so we need to recalculate parameters if necessary.
While setting a clipping box there is necessary to intersect it either with current clipping region location if such region exists or with wxDC surface extents if no clipping region is set. This way effective clipping box will be always inside the wxDC surface.
Note: Effective clipping box can be an empty region.
See #17013
There is no way to show the hint without native support in a control with
wxTE_PASSWORD style, so simply ignore them completely in this case.
Closes#17078.
Chinese, Japanese etc translations use a special style for the menu mnemonics
and append them to the translated menu label in brackets, e.g. the menu label
could have the form of "<translation-of-file> (&F)".
Check for this style of mnemonics in wxStripMenuCodes() too and strip them as
well.
It doesn't make much sense to always use wxCONTROL_FOCUSED in wxDataViewCtrl
code whenever wxDATAVIEW_CELL_SELECTED state bit is set, wxCONTROL_SELECTED
seems to be enough and is with the native MSW wxRenderer implementation which
doesn't even test for wxCONTROL_FOCUSED anyhow, while the generic one did and
didn't use the correct colour unless it was set.
No real changes, but this will make upcoming commits more straightforward and
already simplifies the code a little bit.
Many improvements in wxSVGFileDC to improve its support of wxDC API including:
- Enabled usage of clipping regions.
- Correctly draw polypolygons.
- Draw lines as one long line instead of many short lines.
- Drawing text improvements (position, multi-line, underlined, strike-through).
- Support more brush and pen styles.
- Add Saving as SVG to drawing sample.
- Implemented Clear().
- Set the SVG title.
- Produce valid svg/xml.
- Correctly draw ellipses and arcs.
See https://github.com/wxWidgets/wxWidgets/pull/215
For some combinations of start and end angles, the wrong large-arc-flag was calculated. Fixed by correctly converting the wxDC angles to SVG angles (shift -90 degrees, and invert to clockwise direction).
Arcs with the same start and end point (circles) where not drawn because the angle becomes 0 degrees. Fixed by drawing two half circles.
Elliptic arcs with a non-transparent brush had an extra line from the center to the start point of the arc. Fixed by first drawing the arc without border, then only the border.
Arcs with small angles would become invisible because the start and end point map to the same (integer) coordinate. Very large arcs would be distorted because the start and end point coordinates did not line up. Using floating point values resolves this.
See issue #17557.
Ellipses with the same start and end point (circles) where not drawn because the angle becomes 0 degrees. Fixed by drawing two half circles.
Do not close ellipses if a transparent brush is used (to match wxDC behavior).
See issue #17557.
Override SetDeviceOrigin, SetLogicalOrigin and SetAxisOrientation from wxDC and mark the graphics as changed, so the correct transform translations are applied.
Use the correct doc-type and specify the encoding. 'title' is not a valid attribute of <image> so remove it.
Removed superfluous white-space and improved indenting in generated XML.
Support underlined and strike-through text.
Set the text length (see http://trac.wxwidgets.org/ticket/17271).
Preserve leading and trailing white-space.
Use wxS macro consistently.
Closes#17271.
Do not draw each line separately because the lines will not be connected. E.g. when editing a SVG, moving a point should also move the connecting lines.
Each polygon in the poly-polygon needs to end with the start-point. The implementation is similar to the wxDCImpl implementation, except for the extra end points that are inserted.
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
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.
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.
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.
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).
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.
