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.
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.
Tool padding value should be taken into account also in sizing custom made tools (with controls) to get the same visual appearance and behaviour for all tools (buttons).
Don't set orthogonal padding value to zero but preserve its current value (using MSWSetPadding method).
This way vertical padding is not zeroed when horizontal padding is set and horizontal padding is not zeroed when vertical padding is set.
If padding value (stored in m_toolPacking) has been assigned prior to creating the toolbar (with SetToolPacking) then apply this padding to just created toolbar.
Otherwise initialize this variable with current padding retrieved from the toolbar to let GetToolPacking return proper padding value.
Implemented new method MSWSetPadding() to set padding for native toolbar.
Windows CE doesn't seem to be supported by Microsoft any longer. Last CE
release was in early 2013 and the PocketPC and Smartphone targets supported by
wxWidgets are long gone.
The build files where already removed in an earlier cleanup this commit
removes all files, every #ifdef and all documentation regarding the Windows CE
support.
Closes https://github.com/wxWidgets/wxWidgets/pull/81
Deleting a tool from its own event handler resulted in at least in an assert
and could also lead to a crash as an already deallocated pointer was
dereferenced.
Fix this by checking if the tool with the same ID is still available after the
event handler finishes.
See #16762.
Make sure to reset the "to be deleted" flag we set on the tool when removing
it from the toolbar to avoid layout problems if the tool is added back later.
Closes#16735.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78279 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Windows doesn't use the correct image for checked disabled tools, at least up
to and including Windows 7, so don't put such tools in the "checked" state at
all: this doesn't matter as they are disabled anyhow, but shows the correct
image for them.
Closes#12989.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78248 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Rely on being able to set the separator size, which is supported since
comctl32.dll v4.71 (the version distributed with IE 4.0...).
This allows to remove big chunks of code dealing with multiple separators and
simplifies the rest.
Closes#16129.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76215 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The toolbar was in an inconsistent state when recalculating the sizes of the
separators used as placeholders for the controls and stretch spacers as the
tool was already deleted from the native toolbar but still present in wx
internal toolbar data and this resulted in discrepancies between the indices
in the native and wx toolbars.
Fix this by specially marking the already deleted but not yet removed tool and
ignoring it during the recalculations.
This makes the old, and only partially successful, attempt to work around this
bug in DoDeleteTool() unnecessary and so the code is actually simplified by
this change.
Closes#16095.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76189 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The width was calculated incorrectly in this case as we simply multiplied the
width of the widest column by their number in this case, but actually each of
them has its own width which needs to be calculated separately.
See #13579.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76109 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The item rectangle used wrong vertical coordinates which didn't matter (much?)
for the single row toolbars but was completely wrong for toolbars with more
than one row.
Don't always anchor the rectangle at the window top to avoid this.
See #13579.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76108 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Stretchable separators simply don't work correctly when the space they are
supposed to stretch onto is distributed across several different toolbar rows
or columns, so just disable them for multi-row (or column, for vertical
toolbars) case.
See #13579.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76107 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Not adding the controls to vertical toolbar is not enough, we also need to
hide them to prevent them from being shown as independent floating windows.
And we also need to add separators instead of the controls themselves to keep
the indices the same as in the horizontal case.
Closes#11821.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76099 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Replace the old implementation of stretchable spacers based on changing the
size of the separators used as spacers as the toolbar size itself changed with
a new one, simply replacing the old separator with the new one of the correct
size, as it also works for the vertical toolbars, unlike the old approach.
Closes#13673.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76092 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Correct the changes of the r76035 to avoid using separators when calculating
the fitting width of the vertical toolbars as this doesn't always work
correctly.
Closes#3788.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76080 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use the width of the largest toolbar item as the toolbar width, not the width
of the first one. The implicit assumption that all items had the same width
was wrong and resulted in items wider than the first one being truncated.
Closes#3788.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76035 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
There were several problems when the toolbar style was toggled to not show
icons, fix them by adding missing checks for wxTB_NOICONS style.
Closes#13578.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75846 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use alpha in the combined toolbar bitmap if any of its tools has a bitmap
using alpha. This greatly improves the appearance of the automatically
generated disabled images for the tools with bitmaps using alpha.
See #15876.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75650 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Recent changes broke the handling of tools with alpha bitmaps as drawing them
on the global toolbar bitmap changes its underlying HBITMAP now, but the code
in wxToolBar didn't expect this.
Fix it by updating the HBITMAP used after every DrawBitmap() call, just in
case it changed (it doesn't cost anything to reset it if it did not).
Closes#15876.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75649 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Typical wxScopedArray initialization uses "new T[n]" expression, allow to omit
most of it and specify just n, the number of elements to allocate.
Use the new shorter form in the places where wxScopedArray(new ...) was used
(which is in almost all of them)
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75504 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We need to handle WM_PRINTCLIENT in wxToolBar itself as the default handler
for this message forwards to WM_ERASEBKGND of the parent window and our
handler for that message only erases the client part of the window, in wx
sense, i.e. including a relatively big vertical offset accounting for the
toolbar. This means that when we get WM_PRINTCLIENT from the embedded control
drawing code, we don't erase anything at all as the control rectangle height
is smaller than the offset.
This fix is not perfect as ideally the existing MSWGetBgBrushForChild() should
be taken into account automatically by the default MSWPrintChild()
implementation but at least it fixes the ugly visual artefacts.
Closes#12307.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74757 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
