Hello people, this message could have been named "Where is Base? (Part ...)":
http://wiki.services.openoffice.org/wiki/Framework/WorkInProgress/Addon_Menu_Toolbar_Merging does not even mention OOo Base in the possible modules to use as context for toolbar merging. But to be fair with Carsten Driesner (who is doing a great job at the Framework project), this Wiki page was a little old. So I added a link to the page I created yesterday: http://wiki.services.openoffice.org/wiki/Office_modules_since_OpenOffice.org_2.3 Most modules do not need any explanation, because their names are pretty obvious, but OOo Base modules may need some comments; so please feel free to check if what I wrote is right, and make your corrections. To check if things works (and what difference we find) I wrote an example: http://www.arielconstenlahaile.com.ar/ooo/temp/MenuToolbarMerging.oxt this example will *merge* menu items in every database related module (it is possible to *replace* existing items, but I didn't find it good for a demo extension). To test if it work, I try to add different items to different modules. The items are just for testing purposes, that means that: * they have no functionality at all (other than displaying some tech. info.), * item names are only for testing purposes: no future features are proposed or suggested ;-) * the place where the items are merged isn't meant to be the right one (for example, extensions should have their entry on Help menu with other extensions, but just to test it was possible, I merged the item right after OOo's .uno:About dialog. You can check the sources as a NetBeans IDE project at: http://www.arielconstenlahaile.com.ar/ooo/temp/MenuToolbarMerging.SRC.zip Feel free to make comments on that (please realize that I didn't clean them up, so may be there is some crap ;-) ). Some points are interesting: * the XServiceInfo.getSupportedServiceNames() is now quite useless, because if the doc. is a form or a wiz.-report, it will tell us that is a css.text.TextDocument. Now we must use instead XModuleManager.identify( XInterface aReference), this will give us the module identifier. * XModuleManager.identify() takes an XFrame/XModel/XController as arg., but we must be aware that some db modules have no model; so here is safer to use the XFrame we get when the ProtocolHandler is initialized * in the TableDesign and the RelationDesign modules, the first menu entry I added gets dispatched twice when I choose it (this tested only on Linux), you can try it: a MsgBox shows up, you click OK and another MsgBox shows up; is this a bug or a stupid thing I've done? * something I wonder: can we access form the dispatch framework (i.e. an extensions that works from the user interaction pressing a toolbar/menu item) the data in the module? I mean, for example, if a query/view/table is open by the user, can we get some info. about the query/view/table name, about it's state, etc? if we work with UI interaction via Dispatch Framework, we must work from the XFrame; can we access from there info. about what's happening in the modules TableDesign, RelationDesign, QueryDesign, DatasourceBrowser? With the DatabaseDocument and the other modules it's easy to get a refence to the DataSource, the table the form is based on, etc., but with these other modules? I will add some more things to the demo, and may be it will be a good idea to write something in the wiki in order to attract database related extensions developers, what do you think? Any idea is welcome. Bye and have fun with the demo, 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]
