If there is requested to set/unset a single property (without recursion) as a read-only (wxPropertyGridInterface::SetPropertyReadOnly) or to hide/show it (wxPropertyGridInterface::HideProperty) then first check if property is already in the requested state and if so do nothing. This prevents from unneeded refreshing of the display.
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
This doesn't make sense, these functions can only be ever used with a single
parameter ("cellpos" for the former and "cellspan" for the latter), so just
hard-code it inside the functions themselves.
No real changes, just make the code less confusing.
Introduce a new type for XRC values imaginatively called just "pair of
integers" which can be used for values not expressed in pixels and hence for
which it doesn't make sense to use dialog units nor to scale them by the DPI.
Use this new type for wxGridBagSizer position and span elements to prevent
them from being changed when using higher than normal DPI.
Closes#17592.
"position" argument is input/output and must point after the newly inserted
text on return, but we didn't do it when handling the insertion specially.
Closes#17591.
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
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
Because CreateRectRgn() Win API requires that (x1,y1) parameters represent the top-left corner of the clipping box so if a box with negative values of the width or height is passed to wxMSWDCImpl::DoSetClippingRegion() (what means that (x,y) doesn't represent top-left corner) we need to recalculate passed parameters to get the box with (x,y) at top-left corner.
This reverts commit 71dfb3b414 which fixed
appearance of the captions in high contrast mode but broke them for wxGTK.
Ideal would be to make this code work in wxGTK too or, in the worst, case only
use this code for wxMSW, but for now at least avoid breaking wxGTK appearance
by default.
See #16186.
This reverts 6c40531fb7 ("Make main thread wake
up code more efficient and less error-prone in wxMSW") as, while being more
efficient, the new code doesn't work at all when we're not running the message
loop ourselves as it happens when the user opens a menu or starts resizing a
window because in both cases Windows runs a local message loop dispatching the
messages itself and this message loop doesn't react to our event object being
signalled.
So this approach can't work and needs to be reverted, even if it reintroduces
the danger of overflowing the message queue (see #9053).
Closes#17579.
Allocating 100px (+ margins) for empty listboxes in wxMSW resulted in a
surprising behaviour when the best size of a listbox became (significantly)
smaller after adding some items to it.
One possible solution could be to ensure that all listboxes are at least as
wide as empty ones, but it seems wrong to insist on always allocating 100+ px
when a listbox could be much narrower.
So try to mitigate the problem by making the empty listboxes narrower by
default which should reduce the chance of them becoming narrower still after
appending some items to them, even if it doesn't completely eliminate it.
Also, as a side effect, this commit replaces non-font-and-DPI-dependent
hard-coded 100px value with a more reasonable value based on text metrics.
This assert was redundant as a similar check is done in the base class dtor.
And while usually this assert is just annoying, instead of being helpful, when
running the unit test suite which installs a custom assert handler throwing an
exception, it is actively harmful as generating 2 asserts during the
destruction of a window with mouse capture results in immediate termination
(even in C++98 mode, unfortunately the whole idea of throwing from dtor is
probably unsalvageable anyhow when using C++11).
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.
Only use TBSTYLE_AUTOSIZE, adjusting each button to the size it really needs,
for the toolbars with wxTB_HORZ_LAYOUT style as they don't have any uniform
button size anyhow.
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.
Fix regression introduced by bd388e9827: bitmap
buttons could now be made significantly taller than the text control height if
their bitmap was big enough. Only make buttons taller if they wouldn't be tall
enough on their own, instead of always increasing their height, even if it's
already big enough.
Closes#17576.
This resulted in a crash in GetDefaultEditorForCell() later when GetEditor()
was called from HideCellEditControl() which is itself always called from
wxGrid dtor because GetDefaultEditorForCell() dereferenced m_table without
checking if it was not null any more.
Add the missing check to this function and GetDefaultRendererForCell() too,
for consistency.
In addition, dismiss the cell editor immediately when changing table instead
of doing it at some later time, as it just doesn't make sense to continue
showing it any more as the data it was started to edit doesn't belong to us
any longer.
The loop over the existing selection was buggy and took into account only one
corner of the block instead of the entire block and also skipped some blocks
entirely.
Closes#17572.
Because label is implemented in the control tool as a separate wxStaticText object which exists only if label is non-empty so we need to handle appropriately also the cases when non-empty label is set to empty and vice versa.
Setting a new label for the button tool with TB_SETBUTTONINFO would require to do some additional actions for other items in the toolbar (manual re-positioning items in the control tools, updating stretchable spacers) so it is easier just to re-create the toolbar with Realize().
See #17567
Even if we don't have any way to determine the real margin, don't assert in
this method implementation in wxGTK and wxOSX, but just return 0 instead.
This fixes asserts when trying to fit a column of wxDataViewCtrl, by double
clicking a separator after it, to its contents.
See #13685.
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.
Add new method allowing to use wxRendererNative::DrawItemText() for actually
rendering the text instead of wxDC::DrawLabel().
This will be used for markup support in (generic) wxDataViewCtrl.
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
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.
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.
