[api-dev] Overwrite property when exporting to HTML partly ignored?
Hi together, I am exporting e.g. a presentation document to HTML via API. I set the Overwrite property. The HTML export consists of several files. The main file (presentation.html) is really overwritten while other files (text0.html and img0.jpg) are not overwritten. Instead a message appears that asks me to overwrite. Well, if I set the Overwrite option, I really want to overwrite and I don't want to be asked again. Is this a bug or a feature? Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Netbeans OOo Plugin 2.0: How to add custom files for an option dialog to an add-on project?
Hi, Christian Lins wrote: On 12/11/08 11:43, Benjamin Vollmer wrote: - Jürgen said it make sense to use a folder structure like /registry/data/org/openoffice/Office/ for the data-configuration files. But my experience is that for the OptionsDialog.xcu this doesn't work. The refered .xdl Dialog will only be displayed when the OptionsDialog.xcu is in the root folder of the extension. Probably a referencing problem. Did you use %origin% to specify the location of the xdl file? Please note that %origin% is relative to the referencing xcu file! Ok, let us take my example. OptionsDialog.xcu is stored under /registry/data/org/openoffice/Office/ and the option dialog file is stored under /dialogs/. How should my entry look like? prop oor:name=OptionsPage value../../../../../../%origin%/dialogs/Leaf.xdl/value /prop (This didn't work for me.) I'm currently working on a sample extension for Jürgen that shows how to add an Option page and extension help. I'll need some days to finally polish it, but if it helps I can provide a work-in-progress project earlier... :-) Thanks but at the the moment I don't need more input. All my problems with the options are solved. I have now other questions on my list. ;-) regards Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Netbeans OOo Plugin 2.0: How to add custom files for an option dialog to an add-on project?
Hello, this works for me: prop oor:name=OptionsPage value%origin%/../../../../../dialogs/Leaf.xdl/value /prop Regards, Steffen Benjamin Vollmer wrote: Hi, Ok, let us take my example. OptionsDialog.xcu is stored under /registry/data/org/openoffice/Office/ and the option dialog file is stored under /dialogs/. How should my entry look like? prop oor:name=OptionsPage value../../../../../../%origin%/dialogs/Leaf.xdl/value /prop (This didn't work for me.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Netbeans OOo Plugin 2.0: How to add custom files for an option dialog to an add-on project?
Benjamin Vollmer wrote: Hello, Ariel Constenla-Haile wrote: I send a NB project to your mail (you may have to correct the library dependency, as I'm working on a OOo 3.1). Thanks Ariel. I finally get it to work. My Conclusion: Only with the informations from dev guide it is impossible to implement an extension with an option dialog. I had several problems, here is the short summarize for the list: - I didn't understand that the main class from the nb addon project must implement the XContainerWindowEventHandler interface. I used a seperate class for this because in the dev guide it seems to be also a standalone class, but this class was never instantiated. mmh, seems that we can improve it. The problem is that the example in the Devguide uses an addon to make use of the own configuration entries. This of course is not necessary. Improtant is that you need an own implementation (service UNO oject) that implements XContainerWindowEventHandler. This of course can be created by the plugin with the new file type wizard for UNO objects ... I will publish a complete lab with 5 detailed examples realted to extension development in Java with NetBeans next week. It's my lab from the OOCon this year and i will do one last review before i will publish it. - The dev guide has an advice to use own package names and not org.openoffice.Office but obviously some xcu and xcs files must have this package name (e.g. the OptionsDialog.xcu where the path to the .xdl is defined). mmh, i think you simply have misunderstand it. You use an already defined configuration schema to hook your options page into the office. That of course is org.openoffice.Office.OptionsDialog. You can't change this. The DevGuide means that you should define your own schema with your own package name for your own configuration entries. - Jürgen said it make sense to use a folder structure like /registry/data/org/openoffice/Office/ for the data-configuration files. But my experience is that for the OptionsDialog.xcu this doesn't work. The refered .xdl Dialog will only be displayed when the OptionsDialog.xcu is in the root folder of the extension. sorry, my mistake i forgot to explain this little detail around %origin% ;-) But Steffen and Christian have already explained it. We should introduce a further variable %oxtroot% or something like that expands to the package root directory ... Juergen regards Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[api-dev] Usage of UNO_QUERY_THROW
Hi, does the following snippet throw an exception? uno::Reference XSomething xS1; uno::Reference XSomething xS2( xS1, uno::UNO_QUERY_THROW ); Here, xS2 querries the same interface type from xS1. The intention is to check that xS1 is not null. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Usage of UNO_QUERY_THROW
Daniel Rentz schrieb: Hi, does the following snippet throw an exception? uno::Reference XSomething xS1; uno::Reference XSomething xS2( xS1, uno::UNO_QUERY_THROW ); Here, xS2 querries the same interface type from xS1. The intention is to check that xS1 is not null. Ah, by studying the sources, I learned that it should be uno::Reference XSomething xS2( xS1, uno::UNO_SET_THROW ); Right? Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Usage of UNO_QUERY_THROW
Hi Daniel, Ah, by studying the sources, I learned that it should be uno::Reference XSomething xS2( xS1, uno::UNO_SET_THROW ); Right? Right. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
