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.
Don't recognize the "path" following the port number without a slash as
a path, this is invalid according to the RFC.
Also require two leading slashes for URIs without the authority part.
This allows the subsequent tests to still run even if one of the tests
fails, which is more useful in this test than CPPUNIT_ASSERT_EQUAL(),
which maps to REQUIRE() and so stops the test execution as soon as any
check fails, because the tests are independent.
Show that these events can be vetoed, which prevents the control value
from changing, and also that veto doesn't apply if the event handler
skips the event.
See https://github.com/wxWidgets/wxWidgets/pull/1232
Select first page if an invalid one was restored which may happen if the
build of the library has changed (e.g. some previously disabled
wxUSE_XXX became enabled etc).
Closes https://github.com/wxWidgets/wxWidgets/pull/1235
Qt requires a toolbar area to be specified or the toolbar is not added
to the window, so ensure that is no toolbar flag is given to the wxFrame
then wxTB_TOP is used.
Closes https://github.com/wxWidgets/wxWidgets/pull/1234
During the samples-wide removal of obsolete wxT macros in
f58ea62596, the macros were
accidentally removed also from the place where they were required
(string literal casted to void* and then retrieved as wxChar*). This led
to names for m_tab and m_enter controls displayed wrong when logging
text events.
Fix this by restoring wxS() in this particular place.
See https://github.com/wxWidgets/wxWidgets/pull/945
Closes https://github.com/wxWidgets/wxWidgets/pull/1226
It calls Append(void*), which calls the pure virtual CreateNode(), which will
crash, as the required override can't be called from the base class ctor.
Notify m_selection about the new item in all cases, not just when using
a virtual list model.
This was broken back in 36a5983f64 and
only fixed for virtual list controls, but not all the other ones, in
9f5af0a494.
