Tobias Krais wrote:
Hi Matthias,
Menu commands are command strings that are handed over to the so called
Dispatch Framework. You can place "internal" commands there and then
some OOo code will be called or (if an "interceptor" is placed into OOo)
also some "external" code. You can also place "external" commands there
that can trigger code you provide in your component.
To make OOo call such "external" code you have to use commands with your
own naming scheme and implement and install a so called "protocol
handler" that handles commands using the scheme. All this is described
in the Developers Guide in the chapters about Dispatching and Add-Ons.
Up to now I read a lot in the Dev-Guide. Please let me ask you some
further questions whether I understood the Dev-Guide right and my
concept is OK.
What I want to do after starting OO from a Java application:
1. adding a menu and toolbar item with the commandURL
"vnd.twc.oo.oocom:SaveACopy" (I did this already and the menu item is
grey - it is not known up to now).
The menu item is gray, because there is no code bound to this command.
You have to register a ProtocolHandler or establish an Interceptor
for this URL.
But an Interceptor is normaly designed to intercept (and overwrite)
existing functionality ... not to bring in new functions.
So the ProtocolHandler mechanism is the best way doing this.
2. after clicking on the menu item, I want start external code that pops
up a window with a selection menu. After selecting and clicking OK, the
selection is printed on System.out.println(). After closing OO the
command URL should be no more available for OO.
Showing the UI is no problem. System.out.println() can be a problem (at
least on windows). Because there OOo supress all command line activity.
You wont see anything .-) But for me it seams that this println()
statmenet is temp. solution only ... isnt it ?
Complete removing of this command after OOo was restarted can be reached
only by patching the configuration of the office during runtime. Because
a ProtocolHandler can be registered inside our configuration only. And
then it exists after an office restart too ...
So you have to deregister it manually. Our dispatch framework should be
ready for that. Because such "live-deployment" of ProtocolHandler
objects will be supported. The only thing which can happen is that the
current view wont be updated immediatly. May be only new views will
reflect the changed menu.
Solution possiblity for 2.:
As far as I read, using Jobs as described in 4.7.2 is not a good
solution, because I can't display a user interface from synchronous job.
You can do that ... but if such UI is e.g. written in JAVA and not using
e.g. basic dialogs you will hinder the office on repainting itself .-)
A asynchronous job has problems with model interfaces so I shouldn't use it.
Which problems do you mean ?
It can happen that a Job does not get a model reference ... but that
depends from the fact, that jobs can be bound to events, which are not
bound to models in general. So the job get it's context as set of
parameters. And one of these parameters can be the model .. or the frame
... or any other resource.
Solution possiblity for 2.:
Other solution is to use protocol handlers. But if I understood right, I
have to install them and they will be available after closing OO.
If there is no other solution, I have to check at startup whether the
commandURL is availible. If not, can I install a protocol handler during
runtime from my java application? (In this case I have to accept that
the commandURL will be available after closing OO.)
I'm not sure how do you whish to "establish" all your features inside
OOo. As an AddOn ... or using basic ... or JAVA-remote ?
a) If you use an AdddOn, you are right. Such Protocolhandler will live
as long as the AddOn-installation for this component exists.
b) But if use JAVA-remote you can add/remove such ProtocolHandler during
an instance of OOo runs. But believe me: patching of the ProtocolHandler
configuration is an easy task (and will work of course) ... but
registration of an UNO component at runtime isnt so easy .-)
And I know - removing of such component at runtime isnt realy possible
in general. Because you cant be sure that such ProtocolHandler instance
is not cached (e.g. by the toolbar implementation) !
Are there other solutions?
I dont see a realy good solution. Sorry.
On the other side: is it realy needed to make such "transient changes"
on a running OOo instance ? Or wouldnt be better to install an AddOn and
enable/disabe the corresponding menu entries on demand ?
Currently I dont see any use case, which would require such feature.
Greetings, Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Regards
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
