Hello Carsten,
Le 8 déc. 09 à 09:23, Carsten Driesner a écrit :
eric b wrote:
Hello,
As proof of concept, I'd like to add new toolbars (first in
Writer, later in other applications). The problem is, I'm not sure
to do that the right way. Of course, this can seriously be
improved, but what I need is a proof of concept, not a final
product for the moment
Hi Eric,
First, I created e.g. writercycle2.xml, writercycle3.xml, two
custom toolbars. Putting those .xml file in sw/uiconfig/swriter/
toolbar, they are correctly packaged, and bundled. No problem with
that.
That's correct.
Ok. I'll rename the toolbar, following Cedric Bosdonnat suggestion.
*Question 1* : shall I register those new toolbar. e.g. in
framework/collector/cmduicollector.cxx or somewhere else ?
(currently : I didn't register them, since they are automagically
packaged in postprocess, but maybe this is not sufficient)
No. cmduicollector.cxx was used to migrate toolbar, statusbar and
menu resources to xml files. Currently it's not used for anything.
Ah, ok :) But at least, the content is very usefull, to understand
how the migration was done.
For Writer, the choice was to modify WriterWindowState.xcu ,
located in org/openoffice/Office/UI path
The idea is to display only one between 3 toolbars :
- writercycle2.xml for the Beginner level
- writercycle3.xml for the Average level
- standardbar.xml (already existing), for the Expert level
.. means have only the "Visible" property == true, in same time
for one toolbar only, while the other have false (e.g.
writercycle2 and writercycle3 have Visible=false, standardbar has
visible == true, when the "Expert" level is checked).
Please don't use the WindowState.xcu files to control the
visibility for context dependent toolbars.
Noticed.
You have to use the layout manager to control the creation by your
implementation. The "Visible" property must by default set to true
for all your toolbars. Your implementation calls
LayoutManager->requestElement("private:resource/toolbar/
writercycle") to make it visible.
LayoutManager->destroyElement("private:resource/toolbar/
writercycle") to hide it.
And it works very well !! Thank you very much :-)
These calls are used by the sfx2 based shell manager to make
context dependent toolbars visible/invisible. The layout manager is
responsible to update the state of the WindowState.xcu files.
Here is what I did in the setter :
static short setToolbarState( const OUString sSetAToolbarTypeName,
bool isTrue )
{
try
{
Reference< XPropertySet > xPropSet( SfxViewFrame::Current()-
>GetFrame()->GetFrameInterface(), UNO_QUERY );
Reference< XLayoutManager > xLayoutManager;
if ( xPropSet.is() )
{
Any aValue = xPropSet->getPropertyValue
( aLayoutManagerPropName );
aValue >>= xLayoutManager;
}
if ( !xLayoutManager.is() )
return -1;
else
{
if ( isTrue )
xLayoutManager->requestElement( sSetAToolbarTypeName );
else
xLayoutManager->destroyElement( sSetAToolbarTypeName );
}
}
catch( Exception& )
{
}
return 0;
}
I hope that's better than the first proposal, but please, tell me
whether :)
Now, I have to think twice, because I still have a refresh issue :
until the options dialog box is closed, the toolbars appear
superposed, of badly drawn. Nevertheless, the current state is
extremely encouraging.
Please don't write to the WindowState.xcu file by yourself. This
breaks the whole framework implementation and is the wrong way to
solve your problems.
That's exactly why I asked there : I thought I did something wrongly,
and better ask.
Thansk again,
Eric
--
qɔᴉɹə
