This partially reverts 44d732b8a5 (Use TB_SETBUTTONINFO when updating
stretchable toolbar separators, 2019-02-24) and restores the behaviour
before this commit for the vertical toolbars only, as the new code
doesn't work for them, even though like it seems it should (and we don't
get any error when using it).
Still keep the simpler path for horizontal toolbars, as there doesn't
seem to be any problems with it in this case.
Preserve the ampersands in the string, which is consistent with wxGTK
behaviour and less surprising than the default behaviour, which creates
mnemonics in the tooltips that are, of course, perfectly useless, as
they can't be activated from keyboard anyhow.
Turn on TTS_NOPREFIX, which is already used by wxToolTip, to fix this.
Closes#18899.
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
When we create a toolbar from within the event handler of another toolbar several times (so we have a chain of embedded toolbars) and the last toolbar is destroyed, gs_liveToolbar variable is reset in its dtor what prevents from executing the part of code in MSWCommand() for other existing toolbars if they are still in their event handlers too (still executing OnLeftClick() function). This may happen when toolbars are created in the chain of modal dialog boxes.
To prevent this interference between the toolbars from occurring we have to keep track of all of active toolbars in the chain instead of keeping track of only the last one.
Closes#18309.
This removes irregular behaviour in setting the label of a control. Creating
a control with label now behaves the same as setting or changing the label
later on. And behaves the same as for other tools in the wxToolBar.
Closes https://github.com/wxWidgets/wxWidgets/pull/1289
Don't assume that all the items (except for the controls) have the same
size in wxToolBar::DoGetBestSize(), this is manifestly not true at least
for the separators and resulted in too much space left over at the end
of the toolbar.
DoGetBestSize() mistakenly added extra (half of) padding for each tool
explicitly when the padding is already taken into account of by
GetToolSize() itself, so this resulted in extra space at the end of the
toolbar proportional to the number of buttons in it.
Avoid allocating too much space to the control in the toolbar, it may
have been made smaller than its best size on purpose and, in any case,
we don't resize the control, so it's useless to allocate more space to
it than it's going to use.
See #18294.
Reset the number of buttons to skip deleting the old buttons in
wxToolBar::Recreate() as these buttons don't exist any more (having been
created in the old control) and trying to delete them just results in
debug error messages from TB_DELETEBUTTON.
Recreating the toolbar tried to offset the new toolbar window being
created by the size of the existing toolbar, when it was set up as the
main frame toolbar. Luckily, this didn't work because getting the size
of a wxWindow without a valid HWND failed, but it resulted in debug
warning messages and was a wrong thing to do in the first place.
Fix this by hiding the old toolbar before destroying it, this suffices
for the parent frame not to use it for the client area calculations.
This wastes less space in the toolbar and looks better and is more
compatible with 3.0 (although not totally so, but this is intentional
as 3.0 didn't use any margins at all, which looked bad).
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.
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.
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.
This is simpler than TB_DELETEBUTTON followed by TB_INSERTBUTTON and
avoids weird side effects of using the old messages which affect the
toolbar size.
There should be no changes in behaviour with this change.
Encapsulate the logic for deciding whether we should show the labels for
the embedded controls or not in a small helper function, to make it
simpler to change it in the future if needed and also to have a single
place to explain why do we do what we do now.
No real changes.
To avoid separate calls to SetWidth/Height/Size/Depth functions after calling SetHBITMAP() use newly implemented InitFromHBITMAP() function which allows to set HBITMAP together with its parameters in one call.
While it is not guaranteed in general that destroying a window from an
event handler for an event originating from this window itself works, it
did use to work in the case of wxToolBar and its event handlers. However
this stopped working since faffaaae29 as
it added a test using the now deleted object member fields after the
call to the event handler.
To fix this regression without reintroducing the bug fixed by that
commit (see #16762), add an ugly way to check if the toolbar is still
alive after a call to its event handler and do it explicitly after
OnLeftClick() returns.
Closes#17732.
If the user mixes bitmaps with alpha channel and without it, wxMSW
toolbar rendered the masked bitmap with black background due to changes
in 195df9af7f
In such case, convert bitmaps that don't have an alpha channel into ones
that do so that they are all consistent and can use the same rendering
method.
Fixes#17795.
wxToolBar::Realize() code for handling bitmaps with alpha channel was
incorrectly blending them with the toolbar’s background color, resulting
in much lighter appearance and broken antialiasing.
Fix it by clearing the composite bitmap to be initially transparent if
bitmaps with alpha channel are used. Doing so uncovered another bug in
how the composite RGBA bitmap was passed to native toolbar control, so
fix that as well.
Only use TBSTYLE_AUTOSIZE, adjusting each button to the size it really needs,
for the toolbars with wxTB_HORZ_LAYOUT style as they don't have any uniform
button size anyhow.
Because label is implemented in the control tool as a separate wxStaticText object which exists only if label is non-empty so we need to handle appropriately also the cases when non-empty label is set to empty and vice versa.
Setting a new label for the button tool with TB_SETBUTTONINFO would require to do some additional actions for other items in the toolbar (manual re-positioning items in the control tools, updating stretchable spacers) so it is easier just to re-create the toolbar with Realize().
See #17567
An old check - used for reasons that no longer apply - was preventing
correct rendering of wxToolBar background in wxMSW. Fix this by removing
the obsolete check.
See #9666 for the original reason for the check.
Tools containing controls should be enabled/disabled in a different way from
the button tools in wxToolBar::DoEnableTool(). The control and its label (if
any) need to be explicitly enabled/disabled for wxToolBarBase::EnableTool() to
work properly.
Closes#17346.
