Hello people, in the following address
http://www.ArielConstenlaHaile.com.ar/ooo/temp/HelloODB.zip you can find a Scripting Framework example using a Java "macro" to test in DatabaseDocument/s. You have to unzip and store the folder inside your OOo user dir. user/Scripts/java and restart OOo to deploy it. Inside this folder you will also find an ODB with the JAR embedded. To debug the example you can create a NB project out of it. How to do this in a "simple" way, is explained in a "tutorial" at http://www.arielconstenlahaile.com.ar/ooo/tut/NB_IDE_Scripting_Project_TUTORIAL In short, I recreated Frank's OOo Basic test in Java , into a version to store in the user's dir (user/Scripts/java/HelloODB) and a version embedded in an ODB. Some comments: * in the program there is a main method: you can run the program from the NB IDE to test it, it will bootstrap the office (in order to bootstrap the right version you must set the right JARs!). As a client application it will get the XDesktop and then get the current frame... yes, I know that it is no good, but it's the only way for a client app. that does not load the document first in order to get an XComponent reference directly. * the whole program relies on Frank's dialog('s design) in the user's Standard library: the dialog's URL, the dialog's name, the control names, all are used as constant literals; so if you changed something, it won't work (a better idea would have been to create my own dialog or clone Frank's, but ...) * how I implemented the whole thing will require a complex explanation (you will find it better in the Dev's Guide 19. Scripting Framework); in short I used the Scripting Framework API, and tried to work ONLY from XScriptContext.getDocument(). XScriptContext has also a method getDesktop(), but I assume it is intended to load components in an easy way, and not to use getter methods like getCurrentXxx() [although undocumented, these are OS-dependent and thus unpredictable, at least this is what I read/heard :-( ] Before testing the code, I thought that XScriptContext.getDocument() (which returns an XModel reference) will return null when invoked from a db module that has no XModel (like the DataSourceBrowser, the QueryDesigner). But in fact, some examples show a different behavior if you invoke a method embedded in the ODB or in the user's dir: DataSourceBrowser: 1. open the table "names" 2. from it, open the dialog Tools - Macros - Run macro - Macro selector 3.1. if you run the Java method globalHello in user's Script/java/HelloODB XScriptContext.getDocument() returns NULL, so I use XScriptContext.getDesktop().getCurrentFrame() to identify the module, and the result is css.sdb.DataSourceBrowser 3.2. if you run the Java method localHello embedded in the ODB XScriptContext.getDocument() returns an XModel reference to the css.sdb.OfficeDatabaseDocument (the dialog will be executed with the app. main container window as parent because the XModel is not null and so I instantiate the DialogProvider with it as argument -- I could avoid this, but I wanted to stress how the Scripting Framework's XScriptContext.getDocument() works like ThisDatabaseDocument even if invoked from the DSBrowser) FormDesign: here this begin to get more complicated, and it makes really a difference the OS, and if you are debugging or just running the Java macro. For example, I left an exception I got only on Windows without debugging, to see if other's can reproduce it. Anyway exceptions are caught an the stack trace printed on a JPanel. I still didn't have the time to test it deeply, but at first sight some thing seems issues (for example, invoking from toolbars is impossible). A very premature conclusion seems to be that here to a second method besides XScriptContext.getDocument() is needed: getDocument() returns an XModel, and certain db-related modules have no model; and getting a reference using XDesktop.getCurrentXxxx() is completely discouraged: you can read as@ comment in http://www.openoffice.org/issues/show_bug.cgi?id=84767 Using of any API related to the focus (getActiveFrame(), getCurrentComponent() etc) should be supressed. It works sometimes ... but not always and even not on all platforms in the same way. Its always better to make thinks more explicit. You can travel the frames hierarchie .. analyzing controlls/models to find the right (in your example forms) component - and it will work always. and the very hidden comment in Dev's Guide 20. GUI http://api.openoffice.org/docs/DevelopersGuide/GUI/GUI.xhtml#1_5_3_The_Toolkit_Service There are several ways to retrieve a frame. The easiest way to retrieve a frame is to query the frame that has the focus: [...] XDesktop.getCurrentFrame() [...] This should only be used for debugging purposes. The method getCurrentFrame is based on the implementation of the window handler of the operating system and you cannot be sure that the returned frame is always the desired one on all supported platforms, or that a valid frame is returned at all. It looks like there should be a way in the Scripting Framework to get the controller or the frame of the DSBrowser, for example, without using XScriptContext.getDesktop().getCurrent... Regards Ariel -- Ariel Constenla-Haile La Plata, Argentina [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.ArielConstenlaHaile.com.ar/ooo/ "Aus der Kriegsschule des Lebens - Was mich nicht umbringt, macht mich härter." Nietzsche Götzendämmerung, Sprüche und Pfeile, 8. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
