Don't make the controls with wxTE_DONTWRAP (a.k.a. wxHSCROLL) style
"infinitely" wide, but just "very" wide to allow alignment still work in it.
See #17529.
Disabled controls are not supposed to accept any input, so don't send any
mouse events to them.
This fixes the behaviour of wxSlider which could be moved (and generated the
corresponding events) even when it was disabled.
Closes#17194.
Don't unconditionally use wxWidgets' implementation of IAccessible for
all windows when wxUSE_ACCESSIBILITY is 1, because it is inferior to the
system provided one: it often lacks appropriate labels, doesn't fully
support navigation and wxIAccessible isn't fully implemented.
The approach, when using MSAA, recommended by Microsoft documentation is
to customize accessibility for custom controls only, by proxying to the
standard and overriding what is necessary. By making this change, user
code is still allowed to customize accessibility if needed, without
negatively impacting standard controls that don't need any custom code.
See also https://github.com/wxWidgets/wxWidgets/pull/340
The purpose of this method is to provide a textual description of the renderer's content to the class implementing accessibility framework in wxDVC (wxDataViewCtrlAccessible).
It is exposed if wxUSE_ACCESSIBILITY is set to 1.
By default double dashes are converted to en-dashes in the output (and triple
ones -- to em-dashes), but this is undesirable when double dashes are used not
as a punctuation mark but in command line options or as C++ decrement
operator, so escape them to avoid such conversion in this case.
Allow the user to customize smart quotes and dashes substutions on OS X
and also provide the OSXDisableAllSmartSubstitutions() method for
disabling them all at once.
This reverts ill-advised commits
c07523734f and
8d42890df4 that disabled native OS X
behavior of substituting dashes and quotes with typographically correct
characters if the user has this feature enabled.
This was a bad idea for two reasons:
1. It made wx applications behave non-natively, and thus be worse, in a
highly noticeable area.
2. It made it impossible for applications that want to behave correctly
to restore the native behavior, because once
setAutomaticDashSubstitutionEnabled or
setAutomaticQuoteSubstitutionEnabled is called (as wxTextCtrl
constructor does), it's no longer possible to obtain its original,
default setting.
It's not better to disable native functionality by default, it's better to
be native and make customizations possible. wxWindow API exposes access
to the native control and if an application desires to disable
substitution behavior, it can easily do so from user code.
See also #186 and #241.
wxIAccessible should return a NULL BSTR to the accessibility framework if strings returned from wxIAccessible::get_accName() and get_accValue() are empty because this convention is already applied to the other methods returning string values, like get_accHelp(), get_accDescription().
Because query for item rectangle is executed in the context of wxDataViewCtrl so coordinates of retrieved rectangle should be specified in wxDataViewCtrl client coordinates (not in wxDataViewMainWindow coordinates).
To return correct coordinates it is necessary to convert rectangle coordinates retrieved by wxDataViewMainWindow::GetItemRect() from wxDataViewMainWindow client coordinates to wxDataViewCtrl client coordinates (they can different due to the presence of the header in wxDataViewCtrl client area).
Point coordinates passed from wxDataViewCtrl::HitTest() to wxDataViewMainWindow::HitTest()
should be converted from wxDataViewCtrl client coordinates to wxDataViewMainWindow client coordinates because they can different due to the presence of the header in wxDataViewCtrl client area.
Since accessibility framework supports signaling E_INVALIDARG error, it would be good to have a corresponding flag indicating this error in wxAccessible functions.
In response to wxACC_INVALID_ARG returned by wxAccessible functions, wxIAccessible should return E_INVALIDARG to the framework.
Bounding box coordinates have to be calculated and stored internally in device units to be independent on changes of logical coordinates between calls to wxDC::CalcBoundingBox.
These stored coordinates are converted to the logical units on demand when they are retrieved with call to wxDC::MinX, MinY, MaxX or MaxY.
Closes#17667.
Don't bother with checking for some really obsolete compilers and just assume
that C++98 keywords "explicit", "{static,const,dynamic}_cast" and support for
partial template specialization is always available.
Closes#17655.
Graphics renderers (exposed through wxGraphicsContext) support arbitrary affine transformations so it is possible to add support for affine transformations in wxGCDC by implementing all wxGCDC::*TransformMatrix() functions with calls to respective wxGraphicsContext functions.
Additionally, this implementation adds support for affine transformations in wxDC under wxGTK3 because in this port wxDC is equivalent to wxGCDC.
Member data containing clipping box have to be updated not only when the clipping region is explicitly changed by SetClippingRegion()/DestroyClippingRegion() but also when wxDC coordinates are transformed with SetDeviceOrigin(), SetLogicalOrigin(), SetUserScale(), SetLogicalScale(), SetTransformMatrix() or ResetTransformMatrix().
When any of these functions is called then clipping box data are marked as invalid and updated by recalculating extents of the clipping region in new coordinates at nearest call to GetClippingBox().
Closes#17646.
Member data containing clipping box have to be updated not only when the clipping region is explicitly changed by SetClippingRegion()/DestroyClippingRegion() but also when existing wxGraphicsContext is associated with wxGCDC using SetGraphicsContext() or when wxGCDC coordinates are transformed with SetDeviceOrigin(), SetLogicalOrigin(), SetUserScale() or SetLogicalScale().
When any of these functions is called then clipping box data are marked as invalid and retrieved from underlying graphics context using wxGraphicsContext::GetClipBox() at nearest call to GetClippingBox().
See #17646.
Member data containing clipping box have to be updated not only when the clipping region is explicitly changed by SetClippingRegion()/DestroyClippingRegion() but also when existing HDC is associated with wxDC using SetHDC() or when wxDC coordinates are transformed with SetDeviceOrigin(), SetLogicalOrigin(), SetUserScale(), SetLogicalScale(), SetTransformMatrix() or ResetTransformMatrix().
When any of these functions is called then clipping box data are marked as invalid and updated using GetClipBox() Win API at nearest call to GetClippingBox().
See #17646.
When complex transformation (including e.g. rotation) is applied to DC then coordinates of the clip box return by GetClipBox() API can be inaccurate due to the rounding errors.
To compensate these errors we need to fill rectangle which is slightly larger then just retrieved clip box.
Closes#17636.
If underlying graphics context is rotated then drawing a rectangle with origin at (0,0) doesn't cover all the drawing area. To draw over entire area we need to get extents of the actual clipping region (with applied all transformations) and use it as coordinates of the drawn rectangle.
See #17636.
Width and height were exchanged in the loops, so the conversion code didn't
work correctly and overflowed the pixel buffer (due to extra padding in the
row stride) for non-square bitmaps. It also resulted in a completely wrong
bitmap appearance, but somehow this managed to go unnoticed, unlike the memory
errors.
Closes#17633.
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
While setting a clipping region 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. Effective clipping box can be an empty region.
Clipping box parameters are calculated and stored in logical coordinates.
Focus rectangle was still drawn around the label when it was empty with some
themes, so hide it completely to ensure this doesn't happen.
Closes#17443.
