We reuse the toolbox overflow menu for toolbarmanager's context
menu -- toolbarmanger previously added its menu listener to the
toolboxes menu permanently, meaning that it would try to handle
overflow menu items (in addition to the context menu items which
it should handle), instead we should only add the listener when
we are actually using the menu as a context menu.
Perhaps it would be better in the long run to actually use fully separate
menus instead, and ask toolbox to specifically add its items to that
rather than trying to hack the context menu on top of the overflow menu?
Change-Id: Iecface2c6eae9ab79dbcdb25ffdbaf446e2885ea
A simplified version of the semantic match that finds this problem is
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r1@
statement S;
position p,p1;
@@
S@p1;@p
@script:python r2@
p << r1.p;
p1 << r1.p1;
@@
if p[0].line != p1[0].line_end:
cocci.include_match(False)
@@
position r1.p;
@@
-;@p
// </smpl>
Change-Id: Ib9708d37fbb4c6060f88d5dae3814a2d37b2091e
Reviewed-on: https://gerrit.libreoffice.org/9493
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
A regression from c2c530da69152ff9192b9726aa95961803ce9b29 I think. Rework
this to follow the same ctor + init pattern as the others
move the fillCache out of the ctor to acquire the obj first, then
call the extra init before returning it
Change-Id: Ia0dc878654780294a4935f07ac70c4358ca51dfc
Now that we have default values for Exception constructor params,
remove lots of boilerplate code.
Change-Id: I620bd641eecfed38e6123873b3b94aaf47922e74
There is no need for this function, merge it into createUIElement.
This really helps when I'm looking at a backtrace in gdb.
Change-Id: I005b5161eb2cc8acf509ae7ba4e41186969904d1
Reviewed-on: https://gerrit.libreoffice.org/9309
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
This function is not necessary. I have merged it into createToolbar().
There are just too many function calls when I try to get a backtrace.
Change-Id: I3b1c08b97e24ba18a268f105b00670ed2799f60a
Reviewed-on: https://gerrit.libreoffice.org/9308
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
...as most parts of VCL. Ran across at least one case where a remote call to
framework::CloseDispatcher::release -> ~CloseDispatcher -> ~EventPoster ->
Application::RemoveUserEvent caused a crash. As always with SolarMutex, keep
fingers crossed that this is about the right level to acquire it.
Change-Id: I8f4be7329adbf72355774fa5d3c472270da3ddd2
