Using internally MenuBarManager to manage this kind of menus.
Implemented as a popup menu controller to be able to use in
menubar/toolbar, not only as a context menu.
Change-Id: I46719d66c569db83edd04faf977e0b2b3df0c5fa
...even if no correpsonding xPopupMenu proxy has been set up for some i (because
that sub-menu has never been opened by the user). Otherwise, the Menu that
m_pVCLMenu->pItemList->maItemList[i]->m_pSubMenu points to will be deleted
(during a recursive xSubMenuManager->dispose call), and when later for some
sub-menu j > i that /has/ been opened by the user SetPopupMenu is called, that
can lead to
> Menu::GetPopupMenu(unsigned short) const at vcl/source/window/menu.cxx:835
> Menu::GetAccessible() at vcl/source/window/menu.cxx:1400
> OAccessibleMenuItemComponent::getAccessibleParent() at accessibility/source/standard/accessiblemenuitemcomponent.cxx:339
> non-virtual thunk to OAccessibleMenuItemComponent::getAccessibleParent() at accessibility/source/standard/accessiblemenuitemcomponent.cxx:335
> atk_object_wrapper_new(com::sun:⭐:uno::Reference<com::sun:⭐:accessibility::XAccessible> const&, AtkObject*) at vcl/unx/gtk3/a11y/../../gtk/a11y/atkwrapper.cxx:839
> atk_object_wrapper_ref(com::sun:⭐:uno::Reference<com::sun:⭐:accessibility::XAccessible> const&, bool) at vcl/unx/gtk3/a11y/../../gtk/a11y/atkwrapper.cxx:795
> AtkListener::handleChildAdded(com::sun:⭐:uno::Reference<com::sun:⭐:accessibility::XAccessibleContext> const&, com::sun:⭐:uno::Reference<com::sun:⭐:accessibility::XAccessible> const&) at vcl/unx/gtk3/a11y/../../gtk/a11y/atklistener.cxx:157
> AtkListener::notifyEvent(com::sun:⭐:accessibility::AccessibleEventObject const&) at vcl/unx/gtk3/a11y/../../gtk/a11y/atklistener.cxx:296
> comphelper::AccessibleEventNotifier::addEvent(unsigned int, com::sun:⭐:accessibility::AccessibleEventObject const&) at comphelper/source/misc/accessibleeventnotifier.cxx:281
> comphelper::OAccessibleContextHelper::NotifyAccessibleEvent(short, com::sun:⭐:uno::Any const&, com::sun:⭐:uno::Any const&) at comphelper/source/misc/accessiblecontexthelper.cxx:188
> OAccessibleMenuBaseComponent::InsertChild(int) at accessibility/source/standard/accessiblemenubasecomponent.cxx:436
> OAccessibleMenuBaseComponent::ProcessMenuEvent(VclMenuEvent const&) at accessibility/source/standard/accessiblemenubasecomponent.cxx:624
> OAccessibleMenuBaseComponent::MenuEventListener(VclMenuEvent&) at accessibility/source/standard/accessiblemenubasecomponent.cxx:572
> OAccessibleMenuBaseComponent::LinkStubMenuEventListener(void*, VclMenuEvent&) at accessibility/source/standard/accessiblemenubasecomponent.cxx:569
> Link<VclMenuEvent&, void>::Call(VclMenuEvent&) const at include/tools/link.hxx:84
> Menu::ImplCallEventListeners(unsigned long, unsigned short) at vcl/source/window/menu.cxx:355
> Menu::SetPopupMenu(unsigned short, PopupMenu*) at vcl/source/window/menu.cxx:825
> framework::MenuBarManager::RemoveListener() at framework/source/uielement/menubarmanager.cxx:556
looking at the dangling pSubMenu pointer (and even if the dangling pointer is
never dereferenced, UBSan will try to determine whether the static_cast in
return static_cast<PopupMenu*>(pData->pSubMenu);
in Menu::GetPopupMenu, vcl/source/window/menu.cxx, is fine and cause a crash).
Change-Id: I5e5f6dba266580e3c2e7693877ea79a07d80bb74
- The method to fill the menu shouldn't override impl_setPopupMenu
from the base class, because we can't fill the menu before getting
some data through status updates.
- Use vcl::CommandInfoProvider to get menu labels.
Change-Id: Ieeeafb81921bc4786256aae4e26d87c6106e63da
Will use a different approach for NotebookBar.
Also this should not be in 5.1.
This reverts commit 8c1014021dbe9da2e18233d215b970f5359db67b.
Change-Id: Ic699723818a890bf4c3be3a2c045527148bd118b
Reviewed-on: https://gerrit.libreoffice.org/20075
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
This is the first step to decouple resolving of command names to
image (icon) names. This is necessary to make allow additional
processing of images before the image is passed on and better
decision which image source to take.
Change-Id: I129dc6a1ae812aaaca32696ef2a2749d5fa86a54
...to return an ANY containing a 64-bit HYPER instead of a 32-bit LONG for
SYSTEM_WIN32 (which covers both 32-bit and 64-bit versions of Windows), so that
the HMENU value (which is effectively a void*) is not truncated for the 64-bit
build.
This should effectively be URE ABI compatible for the 32-bit build, as there the
HYPER value will fit into 32 bits, so extracting a LONG from the ANY should
still work.
Change-Id: Ief3de5924f672e8f6bbe6df08c15439456ca036f
Reviewed-on: https://gerrit.libreoffice.org/20045
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...and of little use if all users of SystemMenuData agree on the definition in
vcl/sysdata.hxx
Change-Id: Id102a30074b611e3ad37ce69ce27c929f4505495
Reviewed-on: https://gerrit.libreoffice.org/20044
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
...with a long instead of a HMENU on WNT, so with a wrong size for 64-bit WNT.
(And just ignore the comment that TRIES TO SHOUT AT ME!!!!!!!!!!!!!!!)
Change-Id: Id02ef4d8a3818b58def067e8b52f29bac8676fe9
Reviewed-on: https://gerrit.libreoffice.org/20043
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The new GenericPopupToolbarController takes by default
the popup menu controller that registered for the same
.uno:Something command, and sets ToolBoxItemBits to
ToolBoxItemBits::DROPDOWNONLY. If a different command
specified using the "Value" property - takes the popup
menu controller that registered for this command, and
sets bits to ToolBoxItemBits::DROPDOWN.
Change-Id: I75c5300bd27fcc9f618f2ee0df2aa6aefd088239
Reviewed-on: https://gerrit.libreoffice.org/20040
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
The following properties have been removed:
toolbar:bitmap
toolbar:property
toolbar:width
toolbar:userdefined
This should have no impact on existing functionality or AddOns, since these properties were not in use.
Change-Id: I07574f8102648ee0713379be8cb0b605d2c76364
It was possible to set a tooltip for a certain toolbar entry.
However, this hasn't been used since that tooltip needed to be repeated for each occurence of the same command.
Instead, a TooltipLabel property has been introduced lately (see 9c2f197e8e945f584e718e889938c06fbf644897).
This doesn't affect extensions (They have their own format to specify toolbars).
Change-Id: I0f0fd05b310bb49dd5b4123e31d3e7fec997dd15
