We need to reset the default button using DM_SETDEFID too, otherwise
calling DM_SETDEFID later, when setting the new default button, seems to
restore BS_DEFPUSHBUTTON on the previous default button (but only if its
ID is positive, which probably explains why this bug went unnoticed for
so long), resulting in having 2 buttons with BS_DEFPUSHBUTTON in the
dialog.
Closes#19245.
This commit is best viewed ignoring whitespace-only changes.
Previously the edge event ContentLoading was used which was
triggered earlier than DOMContentLoaded. This event wasn't
available in earlier SDK versions.
Minimum required SDK version is now:
1.0.705.50 (Released 2021-01-25)
Fixes#19202
See https://github.com/wxWidgets/wxWidgets/pull/2468
Remove this bundle key from the generic Info.plist files as it's not
really useful there because none of our samples except "internat" is
localized.
So just add a special Info.plist for this sample and add values
corresponding to all the languages for which we have translations to its
CFBundleLocalizations.
Also update inc_year script to update them automatically the next time,
to prevent them from becoming 3 (for one, or 13 for the other one) years
out of date again.
Don't use CFBundleSignature, it was only needed for Classic Mac OS
compatibility. Similarly, LSRequiresCarbon was used to distinguish the
"new" Carbon applications from the Classic ones and is not needed any
longer.
CSResourcesFileMapped might still be used, but it's just an optimization
and we don't need it and it's just a s gratuitous difference with the
template used by Xcode, so remove it too.
Just put the keys in the same order as the one used in Xcode template
and samples/minimal/Info_cocoa.plist based on it (which is almost
alphabetical order, except for LSMinimumSystemVersion which comes after
NSPrincipalClass at the very end for whatever reason).
No real changes.
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.
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.
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 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.
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.
With both GTK 2 and 3 if a wxDVC cell has a background colour attribute
set then wxDataViewCustomRenderer::RenderText() sets the cell's
background property. With wxDataViewCheckIconText this results in items
drawn prior to the text to be painted over.
Reproducible using the dataview sample which on the MyListModel page
uses a background cell colour for the first column of odd-indexed rows.
Fix by drawing the text first, followed by the checkbox and possible
icon as before. There appear to be no other custom renderers in wx which
draw multiple items and may have needed fixing as well.
This commit is best viewed with git --color-moved option.
Closes https://github.com/wxWidgets/wxWidgets/pull/2449
This reverts commit 95f1b262a4 ("Store clipping box coordinates in
device units in wxWindowDCImpl, wxGTKDCImpl", 2021-07-26) because
device coordinates can be used to determine final clipping box
coordinates more accurately only if current logical coordinates
are not stored directly in the corresponding variables of the base
class wxDCImpl.
If derived class sets clipping region in a legitimate way by call to
DoSetClippingRegion() instead of directly storing logical coordinates
of the box in the internal variables we can store coordinates in
device units to determine final logical coordinates more reliably even
in case when coordinate transformations were applied to DC
in the meantime.
