This message just seems too weird and unreliable, so get rid of it and
compute the toolbar size entirely on our own, which at the very least
gives predictable and reproducible results and makes GetSize()
consistent with GetBestSize().
The toolbar height doesn't remain exactly the same as before, with 1px
differences here and there, but now the height is the same initially and
after changing the toolbar styles, while previously the height changed
when doing this.
Don't truncate addresses under Win64 when printing debug messages using
wxMemStruct.
This avoids build errors if wxUSE_DEBUG_CONTEXT = 1 when building on
Win64.
Closes https://github.com/wxWidgets/wxWidgets/pull/1249
Restore the hack with making the toolbars with wxTB_FLAT style 3px less
tall than the value given to them by TB_AUTOSIZE.
There is no real explanation for doing this, this adjustment was added
by 98b9643647 back in 2002 with the
rationale "make flat toolbars look slightly better", but after doing it
for 17 years during which nobody complained about this, we probably
should keep doing it now.
There doesn't seem to be any good reason to add 3px to the vertical
component of the toolbar best size and it's not clear how can the
original problem be reproduced.
This basically reverts c118d8b06e.
Tool packing seems to be relevant only in the major toolbar direction,
i.e. horizontally when the controls are shown, and adding it in vertical
direction too made the toolbar too tall.
After the changes of 6b8b3ee379 we could
use NSCriticalAlertStyle for message boxes with wxICON_WARNING, if they
also has Yes/No or Cancel button, but never for wxICON_ERROR, for which
just NSWarningAlertStyle was used, which seems counterintuitive, so
change the code to use NSCriticalAlertStyle for either wxICON_WARNING or
wxICON_ERROR message boxes asking the user about something.
Closes https://github.com/wxWidgets/wxWidgets/pull/1242
- Remove duplicate wxConsoleAppTraits::CreateEventLoop()
It's already defined for Unix as well as Windows
- Remove wxEventLoop AddSourceForFD() "override"
the base version is static and therefore clearly not meant to be overridden
wxToolBar handled its size in a very unique way as it waited to be
resized and then set its size correctly from its own WM_SIZE handler.
This was very confusing and, worse, broke a very natural assumption that
after calling SetSize(size) on a window this window does have the
specified size -- which wasn't necessarily the case for wxToolBar,
resulting in problems such as the one in #18294.
The reason for doing it in such weird way is that the native toolbar
control is weird itself and uses a specific message (TB_AUTOSIZE) to
update its size and, moreover, doesn't always do it correctly (notably
for the vertical toolbars). It seems that we can make it work more or
less as wanted if we use TB_SETBUTTONSIZE _after_ TB_AUTOSIZE (why does
it need to be done in this order remains a complete mystery) and if we
correct the width of vertical toolbars in UpdateSize() (which is not
called from WM_SIZE handler but only from Realize() and other methods
modifying the toolbar, so it's not a problem for it to change the size).
The only known problem with this commit known at this time is that
stretchable separators in vertical don't work any longer, it seems that
the size passed to TB_SETBUTTONSIZE is just ignored in this case.
However stretchable toolbar separators are pretty rare nowadays and even
more so in vertical toolbars, so, arguably, this is not a big loss.
Also tweak the layout of the labels for the embedded controls to make
them more similar for the labels used for the normal tools and, notably,
allocate enough space if the label is longer than the control itself.
Closes#18294.
When computing the fixed size of MSW toolbars, don't take stretchable
separators into account as this doesn't make sense and so, even if this
doesn't matter currently because the separators still have their
initial, fixed size when total fixed size is computed, but would start
mattering if UpdateStretchableSpacersSize() is ever called before this
is done and it also just makes more sense to skip them here.
