Hi Andreas, >> 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 ? :-) Indeed, it is! Later I want to use it for two purposes: 1. Starting a function like ".uno:SaveAs" but saving the document and return to the original. 2. Starting a function that allows the user to select wheter the first page of his printout should be printed on special paper in a special printer tray. > 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 .-) I would like to use OO dialogs but want to call them from Java. The dialog will be synchronous and there is no use to use OO meanwhile. I think repainting is not needed. I do not know yet whether OO has his own components to create modal dialogs (I have to go on with the Dev-Guide for that). >> A asynchronous job has problems with model interfaces so I shouldn't >> use it. > Which problems do you mean ? The problems described in 4.7.2 of the Dev-Guide (repainting problems). > 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 ? 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) ! You explanation helps me. I will "patch" the ProtocolHandler config. >> 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. OK. The changes do really not need to be transient (this is a nice to have). My use case is following. We have an application for lawyers. Out of this application you can open text documents. The office app is OpenOffice. We developers (esp. I) don't want to take care for the OO installation of our customers. So our application should be able to use every OO > 2 and if possible not change a thing. For the next steps I have following questions: 1. If I register a Protocol Handler via Java-remote the handler remains registered, right? But what happens when my application is missing next time OO is started? Won't OO complain about the missing protocol handler? 2. To register a Java-remote protocol handler I will follow chapter 4.7.1. Or did you mean an other starting point with "patching of the ProtocolHandler configuration". I will also have a look at the examples here: http://kingyo.tutms.tut.ac.jp/~toshi/StarSuite/Chap4/EX4710/ Thanks for your help. Greetings, Tobias --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
