It is not forbidden to have function calls in static initializers, and
such code compiles fine, contrary to claims made by the text. Explain the
real reason why wxTRANSLATE is necessary.
This is a default description of the renderer content (for accessibility purposes).
Thanks to this implementation there is not necessary to override GetAccessibleDescription() in the renderers derived from wxDataViewCustomRenderer.
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.
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.
In wxGCDCImpl::ComputeScaleAndOrigin() current affine transformation matrix (applied with SetTransformMatrix, ResetTransformMatrix) has to be concatenated with current basic transformations (applied with SetDeviceOrigin, SetLogicalScale, etc.).
Closes#17674.
1. Elements of resulting matrix are modified directly (in-place) in Matrix3x2F::SetProduct() so none of the multiplied matrices can be the instance of the resulting matrix.
2. The parameter matrix in wxGraphicsMatrixData::Concat() should be a multiplicand, not a multiplier.
See #17670.
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.
wxGetKeyState() does not currently work on non-X11 GTK backends, and in some
cases it has been reported to crash. It seems that the most likely use case
for wxGetKeyState() is to query the modifier keys, so on non-X11 backends, use
GTK+ calls to retrieve the modifier key state.
Non-modifier keys are not currently implemented, update the documentation to
mention this.
Closes https://github.com/wxWidgets/wxWidgets/pull/320
Native ID2D1RenderTarget::SaveDrawingState method stores in ID2D1DrawingStateBlock only transform, antialiasing mode, text-rendering options and tags but not currently set ID2D1Layers (which are used in wxD2DContext for clipping purposes). Therefore current stack of layers has to be stored "manually" alongside ID2D1DrawingStateBlock in a dedicated data structure (LayerData) in PushState() and restored also "manually" in PopState().
Closes#17626.
This wasn't documented anywhere until now, so copy the contents of the table
in src/common/accelcmn.cpp to the documentation to have them all in one place.
This skeleton of documentation was replaced by (minimal but still more
valuable) real documentation in fcd5284aed but
the old classes were accidentally left in.
Added section to group similar functions in the documentation of wxGraphicsContext.
Fixed references to the section describing wxPGProperty attributes.
When wxPGProperty's text or background colours are modified with dedicated wxPropertyGridInterface utility functions (SetPropertyBackgroundColour, SetPropertyTextColour, SetPropertyColoursToDefault) then it is enough to redraw the property with new colours because its internal state remains unmodified and full refreshing is not necessary.
Closes#17588
ID2D1RenderTarget::PushAxisAlignedClip/PopAxisAlignedClip used to clip the region (with wxGraphicsRenderer::Clip) and ID2D1RenderTarget::PushLayer/PopLayer used to rendering to the transparent layer (with wxGraphicsRenderer::BeginLayer) are non independent but have to be used in the controlled sequences: "A PushAxisAlignedClip and PopAxisAlignedClip pair can occur around or within a PushLayer and PopLayer, but cannot overlap" (and of course finally each Push* call must have a matching Pop* call).
To control the sequence of access to the AxisAlignedClips and Layers there is implemented a wxStack data member holding Clips/Layers parameters which reflects a physical stack of respective Clips/Layers in ID2D1RenderTarget. This way we know in which order to pop and what to pop from ID2D1RenderTarget stack if there is a need to do so.
Closes#17590
When there is no clipping region currently set then current effective clipping region is identical with entire DC surface and therefore DC size should be returned as a region size.
Closes#17013
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.
