Instead of using the size of the first item bitmap, use the size best
suited for all the bitmaps, which may result in better appearance if the
different bitmaps are not all available in the same sizes.
This also fixes the unit test after 80a736250e (Fix margin between
wxBitmapComboBox images and text in high DPI, 2022-05-25) and should
have been part of it.
Add support for the missing wxBU_NOTEXT style, bitmaps for the other
than default states (pressed, focus, disabled and current) and margins
to wxBitmapXmlHandler.
Note that the images for the other states were previously already
supported by wxBitmapButton XRC handler, but not by the wxBitmap one,
even though both bitmap classes support them.
Closes#22451.
Using GetContentScaleFactor() worked just fine for wxOSX and wxGTK,
where it's the same as GetDPIScaleFactor() anyhow, and, until recently,
didn't matter for wxMSW where the scale factor was just ignored.
However since 9e5c8a8027 (Respect bitmap content scale factor in wxMSW
wxMemoryDC, 2022-03-26) it is important to specify the actually correct
scale factor when creating the backing bitmap in wxSTC code, as
otherwise wxMemoryDC would try to compensate for it by rescaling the
font, which should be unnecessary and resulted in a very noticeable
performance regression.
Simply using GetDPIScaleFactor() fixes the problem for wxMSW without
affecting the other platforms.
Closes#22450.
Don't use FromDIP() with m_usedImgSize which is expressed in logical,
and not DPI-independent, pixels already and also update the image size
when the DPI changes.
Closes#22436.
This function didn't work at all in this case because the drag context
wasn't set in target_drag_data_received(), unlike in all the other
callbacks.
Do set it here too to fix it, this notably makes dropping data on
generic wxDataViewCtrl work correctly in wxGTK.
Closes#22453.
Recent changes to wxGrid (see #22292) resulted in an assertion being
triggered when dragging row or column to the corner window. Fix this by
adding a check for the new position validity.
Closes#22432.
Closes#22443.
This was broken by 6feeed9fe9 (Handle transparency to the best of our
ability in wxImageList, 2022-05-05) as using alpha, rather than mask,
for these images resulted in alpha channel being just ignored.
Work around this by making at least one pixel not quite transparent in
this case.
This also makes things work for images using alpha channel with only 0
values, rather than mask covering the entire bitmap.
See #22400.
Closes#22437.
Even though it's better to not specify the preview frame size at all,
the size should still be used if it was explicitly specified, but this
didn't happen any more after the addition of the call to Fit().
Fix this now by only doing the equivalent of Fit() if no size was
explicitly given.
Also add advice about not setting the size explicitly to the
documentation.
Position of the editor should be adjusted after setting new virtual size
because this operation can scroll wxPropertyGrid contents and scroll
position needs to be taken into account.
See #22428.
Close the path corresponding to the polygon to ensure that the starting
and finishing edges are joined correctly, which wasn't the case before
as could be easily seen when using thicker pens.
Closes#22440.
Having borders around the controls toolbar and preview canvas not only
wasted space, but also let the frame background show through, which
looked just ugly under MSW, where it is dark grey and so clashes with
the control bar background.
Simply remove them to save space and improve appearance too.
Give a reasonable default size to wxPreviewCanvas and fit wxPreviewFrame
to its contents.
Remove the useless call to Fit() from SizerWithButtons: the size set
inside it was just ignored anyhow.
This also allows to stop hardcoding the size in the sample, so don't do
this any more.
See #22439.
No real changes, just remove the useless call which was left over the
very first version of this code added in 7bcb11d307 (Many changes to the
printing classes., 1999-03-25).
Don't hardcode 70px size for the combobox, but let it determine its own
size instead, as 70 may well not be enough, depending on the theme and
the font size.
Closes#22439.
Don't use wxWithImages::GetImage(), which is limited to only a single
bitmap resolution, but use GetBitmapBundle() instead to ensure that we
show the representation of the bitmap appropriate for the current
resolution.
This would seem to be required for drawing it correctly in the disabled
state, for example, but is still insufficient to fix its appearance, at
least with GTK 3.
See #22431.
The fix of a5a5b1bb15 (Fix restoring focus after showing native modal
dialogs in wxMSW, 2022-04-07) wasn't quite correct as it used the parent
window specified when showing the dialog, but it should have been using
the effective dialog parent, i.e. owner window in MSW terms.
Fix this by passing GetParentForModalDialog() to wxWindowDisabler, which
ensures that the preserve the same behaviour as before, including
refreshing the owner window after the dialog as dismissed -- which turns
out to be important because some existing code relies on this happening,
see #22362.
This commit should hopefully fix the last regression after d311c705d7
(Make native dialogs application-modal in wxMSW, 2022-04-01) and still
solve the original problem (see #11887), while preserving the original
behaviour when there is just one top-level window.
In the future it might be useful to run the code with WXTRACE=gtklog to
see if any GTK log messages we're filtering don't need to be filtered
any longer.
These messages are due to an assertion failure deep inside ATK which
doesn't indicate any real problem (as failure to get the label of an
already destroyed tab is normal and is already handled correctly in the
GTK code) and can't be avoided, so suppress them to avoid showing them
to the users who can't do anything at all about them anyhow, but can be
scared by the "CRITICAL" GTK messages.
Closes#22176.
Refactor the code to separate setting of the log callback from the
filtering decision.
Right now the only existing filter is the one just checking the log
level, which is used by GTKSuppressDiagnostics(), but this will allow
adding other filters in the upcoming commits.
Compare the row position with the number of rows, not columns, fixing a
regression introduced in 3719ab3725 (Add support for rearranging wxGrid
rows order interactively, 2022-04-02) (see #22260).
Closes#22420.
Closes#22423.
Fix a layout issue when wxFlexGridSizer contains items that return true
from InformFirstDirection(), such as wxWrapSizer.
If didAdjustMinSize == true, the minimum width has probably changed, and
we should recalculate it. Otherwise we end up using incorrect delta in
DoAdjustForGrowables, which might push items too far to the right.
Closes#22421.
This was broken by the changes of 6383bc39ff (Add convenient
wxDCImpl::CalcBoundingBox() overloads and use them, 2022-04-30), fix it
by calling the overloaded wxDCImpl::CalcBoundingBox() instead of the
wxDC version for which the overloads were not added.
Closes#22418.
This is slightly more efficient and simpler than using a separate
critical section and can easily be done now that wxAtomicInc() returns
the new value.
No real changes.
Use gs_initData.csInit only to ensure that we call wxEntryStart() once
even if there are multiple calls to wxInitialize() from multiple
threads, but don't keep it locked for the duration of that function as
this is unnecessary and results in -- probably benign in practice, but
still annoying -- warnings from the thread sanitizer about lock order
inversions due to locking csInit first before locking gs_mutexGui in
wxThreadModule::OnInit() and then acquiring csInit again while
gs_mutexGui is still locked in wxUninitialize().
This shouldn't result in any observable changes in behaviour.
