Under MSW creating a wxSpinCtrl with a range of, say, 1..10 and the
default initial value of 0 sets its initial value to 1 (i.e. the closest
valid value) as expected, but the generic version still set it to the
invalid value of 0, which was unexpected, inconsistent and not useful.
Fix the generic version to follow MSW behaviour now and add a test
checking for this.
This was removed in 415f080c80 (Split wxGrid RANGE_SELECT event into
SELECTING and SELECTED, 2020-07-27) without preserving it for
compatibility. Do define it now, just as it was done for the non-CMD
equivalent of this macro EVT_GRID_RANGE_SELECT.
Also update the documentation to fix a typo from e2f316b19d (Mention
that wxEVT_GRID_RANGE_SELECT{ED,ING} are new in 3.1.5, 2020-08-18).
Use -1, not 0, for the not-yet-computed value. Prevents CPU-intensive
recomputation when the calculated size _is_ zero - e.g. because the
column is hidden.
No real changes: In wxImage::Rotate() don't needlessly wxRound numbers
that are already whole after having called ceil/floor.
Occurred since inception in 7a632f1056 (Added rotation to wxImage,
2000-02-06).
See https://github.com/wxWidgets/wxWidgets/pull/2460
Under at least some versions of Windows 10 with wxDVC themed text can be
clipped horizontally because of discrepancies between the text extent
as drawn by DrawThemeTextEx() and calculated with GetTextExtent()
earlier.
Work around the issue by always trying to use GetThemeTextExtent() in
DrawItemText(), not just for alignment of multi-line strings, and adjust
for any width differences similar to the existing adjustment for height.
See #18487.
Change wxGCDCImpl::DoGetTextExtent() from rounding to the nearest
integer to rounding up: if e.g. height is 15.3 then 16 pixels should be
used for height, and not 15. Rounding was previously improved from
casting (which appears to be the initial code) in 0417955ddb (adding
correct filling area to arc, correct rounding and clipping, 2007-10-21).
Issues with nearest rounding became more visible after off-by-one fixes
for wxDC::DrawLabel() with wxALIGN_RIGHT and wxALIGN_BOTTOM positioning.
When using e.g. wxALIGN_RIGHT with a width of 72.4 the text could now be
drawn beyond the extent on the right because the text is not offset by
one to the left any longer.
Revert e2e7d3d391 (Fix wxELLIPSIZE_END with wxALIGN_RIGHT in wxMSW
wxDataViewCtrl, 2016-03-18). This fix is no longer needed after
the previous commit reverted b642747fd2.
Reverting also allows for text to be drawn vertically aligned again
instead of always using top-left alignment. While the difference in
appearance by not having alignment can be minor with default row
heights, it becomes more noticeable with taller rows:
a wxDataViewCheckIconText column with a tall icon will have its text
stuck to the top of a row while other columns have their text vertically
centered. This already occurs by default when not explicitly specifying
an alignment (wxDVR_DEFAULT_ALIGNMENT) which results in
wxALIGN_CENTRE_VERTICAL being used for row alignment when rendering.
Revert b642747fd2 (Fix right aligned text position in wxDVC on MSW with
system theme, 2015-09-30) which in wxRendererXP::DrawItemText() mimicks
the off-by-one with right alignment of wxDC::DrawLabel() that got fixed
by the previous commit.
There's not a similar change copying wxDC::DrawLabel()'s former
off-by-one behaviour with wxALIGN_BOTTOM that would need reverting.
Both alignments now result in the same text positioning with both
drawing functions.
wxDC::DrawLabel() positions the text one to the left with wxALIGN_RIGHT
alignment and one up with wxALIGN_BOTTOM alignment. The same occurs in
wxControlRenderer::DrawBitmap() for bitmaps. Both off-by-ones exist
since inception in respectively 4d3c4c2f94 and bc60c3d699.
This fix vertically aligns wxALIGN_BOTTOM drawing of wxDC::DrawLabel()
with themed text drawing through wxRendererXP::DrawItemText().
When using non-TOP vertical alignment with wxRendererXP::DrawItemText()
either DT_VCENTER or DT_BOTTOM gets passed to DrawThemeTextEx() but
without the DT_SINGLELINE flag which is required for those alignment
flags to take effect, resulting in text always being top aligned.
Fix by passing DT_SINGLELINE when using either alignment, but only for
single lines as multi-lines are rendered as a single line with invisible
newline character. Draw multi-line text using top alignment and deal
with vertical alignment ourselves, using GetThemeTextExtent() to get
an accurate extent of the text.
Comment in wxRendererXP::DrawItemText() could be interpreted as
DrawThemeTextEx() being available for some XP editions but it is Vista+
only, so correct it.
This is intended for wxMSW to show differences between themed text
drawing (with wxRendererXP::DrawItemText() under Vista+) and
wxRendererGeneric::DrawItemText(). Use existing option to switch between
generic and native renderer (Ctrl-G) in the render sample to observe
the differences.
Some generic render functions aren't implemented and result in obtrusive
assert failures when switching to use the generic renderer in the render
sample. Instead show text saying the drawing function is not implemented
in the location where the sample would ordinarily draw the control.
To more easily expose problems add options to the dataview sample
related to rendering of items (applying mostly to the MyListModel page
only):
* Use left/centre/right alignment (Ctrl+1/2/3)
* Use top/centre/bottom alignment (Ctrl+4/5/6)
* Toggle tall row usage (Ctrl+7)
* Toggle keep on using small wx logo, regardless of row size (Ctrl+8)
* Toggle multi-line text usage (Ctrl+9)
For debugging convenience define DEBUG_RENDER_EXTENTS to draw a red
rectangle around a custom rendered cell's full rectangle, and a green
rect for the extent of the item appearing inside it. Custom renderers
ordinarily should not draw outside of the green rect. A notable
exception is drawn text, particularly multi-line ones.
Simply remove the not existent any longer shared-ld-sh from clean
targets in all makefile.
This should have been done in e663d9af2b (Stop using shared-ld wrapper
script under Mac, 2021-07-06).
The wxrc program does not depend on the GUI libraries, but only on
the base and XML libraries, so make it possible to build it in non-GUI
builds too.
Closes https://github.com/wxWidgets/wxWidgets/pull/2419
This wasn't done since the changes of c1c4c5516c (fixed unwanted owner
data accesses in virtual list ctrl, 2001-08-07), but there doesn't seem
to be any reason to avoid accessing the item in SendNotify() (any more?)
and if we ever did generate events for all the items in a virtual list
control, this would be already a problem, even if we didn't access the
line info from here.
So just revert the check for !IsVirtual() and always fill the item in
the generated event to make the behaviour of the generic version
consistent with the MSW one and slightly more useful.
See https://github.com/wxWidgets/wxWidgets/pull/2456Closes#19235.
Always set the label, even when not using wxTB_TEXT style, as otherwise
the items shown in the native "overflow" menu use empty strings as
labels and so can't be distinguished at all.
This undoes part of the changes of 1f7cd4807f (Don't show labels for
toolbars showing icons only in wxOSX, 2016-02-23), but they don't seem
necessary any longer, i.e. calling SetToolShortHelp() doesn't show the
toolbar label when using non-native toolbars, so #16669 remains fixed.
Closes#19226.
Use 2 separate functions instead to make the code more clear, as passing
false for indicate the refresh shouldn't be done was quite confusing.
Also get rid of a separate RefreshAll() which was called only from
RecalculatePositions().
No real changes.
This is similar to b03eaceea6 (Disable WebRequest::SSL::Ignore unit test
under AppVeyor, 2021-08-04) and just warns about the wxWebRequest
cancelling test failure when running it under AppVeyor instead of
failing the entire test suite, as this does happen sporadically (but
regularly) there for as yet unknown reason.
This already worked with the generic version, but silently failed with
wxMSW, so make it work with wxMSW too as it doesn't cost much and makes
wxListCtrl behave in the same way under all platforms.
Also document that SetImageList() can be used before the window is
created.
This test sporadically fails in builds with different compilers (both
MSVC and gcc) there for unknown reasons. Until we can find, and fix, the
underlying problem, disable this test to avoid spurious CI failures.
We need to account for the trailing NUL explicitly here, so add 1 to the
length returned by the first call to wx_regerror() to avoid chopping off
the last character of the error message.
MSVC 7 project files don't exist any longer, so don't try updating them
in upmake.
This should have been done in 8b854d2f92 (Remove MSVC 7 project files
and support for generating them, 2021-04-26).
