There is no reason to call ::GetMonitorInfo() all the time, e.g. just to
determine if the monitor is primary, as we can just store it entirely.
We already invalidate the information stored for all the displays
whenever anything changes, so the cached information doesn't risk
getting out of sync.
Previously, the first monitor was created instead and while it was often
also the primary one, this wasn't always the case.
In particular, this makes wxGetDisplayPPI() always return something
reasonable instead of returning (0, 0) when the first monitor is not the
primary one, as expected by plenty of code, including our own printing
sample, which divides by the values returned from wxGetDisplayPPI()
without checking if they're zero.
This is not necessarily the case at least under MSW, so while it makes
sense to do this by default in wxDisplayImpl::IsPrimary()
implementation, MSW-specific version should override it instead of being
totally unused as it was until now.
wxMemoryDC and wxScreenDC dtors were freeing a context they didn't own, potentially
causing a crash. Fixed by having the base wxWindowDC dtor free the context.
See #18566
When wxGetTBItemRect() is called on a control tool, it can cause a
TB_GETITEMRECT error message. Swap the if statements around so
wxGetTBItemRect is only called when it is needed.
Closes https://github.com/wxWidgets/wxWidgets/pull/1639
This could result in infinite recursion in wxX11, as the test for the
new size being different from the old one which was supposed to stop the
recursion, failed there in case the new size was 0: as wxX11 can't use 0
size for the window, the actual size was always different and so we kept
sending size events to the parent, which kept resizing the toolbar etc.
It could be argued that there is a bug in wxX11 and that GetSize() must
return the same value as was passed to SetSize(), even if it was 0, and
this might even be correct, in theory, but it doesn't seem worth to do
it just to accommodate this weird use case, especially because resizing
the parent from the child shouldn't be necessary in the first place and
none of wxToolBar implementations in the other ports does it.
So just remove this code completely.
Closes#18554.
Instead of repeating the same checks in several places, do it in a
single one.
Also use the smallest possible valid size (1, 1) instead of the totally
arbitrary (20, 20).
on these systems scrollbars on comboboxes are not always shown, even if the system is configured to do so, in these cases show all possible to avoid the impression of a limited subset
see https://github.com/wxWidgets/wxWidgets/pull/1534/files
Make wxEVT_MENU_HIGHLIGHT generation when there is no highlighted item
consistent across all the major ports: use wxID_NONE instead of wxID_ANY
in wxGTK and send these events, which were previously not sent at all in
this case, in wxOSX.
See https://github.com/wxWidgets/wxWidgets/pull/1637
This avoids glib warnings
object class 'GtkTextTag' has no property named 'underline-rgba-set'
when calling g_object_get() with older GTK and just avoids doing useless
work.
The changes of 3241e7a850 resulted in
Layout() not called any longer from wxEVT_SIZE handler for windows that
didn't use neither sizers nor constraints themselves, but did call
SetAutoLayout(true).
Fix this regression by checking for GetAutoLayout() explicitly.
See #18472.
This function is not supposed to overwrite the given alignment values
unless the alignment is specifically set for the given cell, but it
always overwrote them when called on m_defaultCellAttr, i.e. the
attribute used by the cells that don't have any special attribute.
This meant that custom attributes had to be set (or, more efficiently, a
custom attribute provider returning non-null attributes for all cells
had to be used) previously just to make the right alignment used by
default by number or date renderers work.
Fix this by ignoring the values set in the default attribute in this
function.
Also add a unit test (which required adding a special helper class just
to allow testing wxGrid::GetCellAttr() used by the renderers) that used
to fail but passes now.
This caused wxTextCtrl to become to high at higher DPI.
It was added to fix appearance of wxSearchCtrl at high DPI. Remove an unneeded
FromDIP there too, so it gets the same height as a normal wxTextCtrl.
And centre the textctrl inside the searchctrl.
Ensure that all native controls get WM_NCCALCSIZE soon after creation,
so that we can tell Windows about the themed controls we draw ourselves
in WM_NCPAINT.
Otherwise we could end up without any visible borders at all and, worse,
with bad display artefacts after resizing the control.
Just call SetWindowPos(SWP_FRAMECHANGED) to ensure that WM_NCCALCSIZE is
generated, even if the control is not resized later, which happens for
controls with fixed initial size.
Closes#18549.
This is unexpected, so add the check for the modifiers, as is done in
generic wxDataViewCtrl, to only accept the "real" Enter here and not
Ctrl-M sending the same key code.
Closes#17458.
Add labels for the columns using date format and labels for the cells
using date renderer/editor explicitly to give a better idea about what's
going on here.
Also use the same rows numbers for date cells as for the column ones for
consistency.
No real changes.
See 659ab78c6d
DoClose() shouldn't do anything if CFSocket hadn't been created at all
(as will be the case for blocking sockets) instead of creating it only
to destroy it immediately afterwards.
Ensure that last wxDataViewCtrl columns is always expanded to fit the
control width and a unit test checking for the scenario in which this
wasn't the case before, but is now.
See https://github.com/wxWidgets/wxWidgets/pull/1313
