Hi Paolo, > The problem is that forms and report definitions are not documents. > I know, actually they are documents, but this should be an > implementation detail and I hope that in future they will be replaced > from something more suitable than documents.
Call them with another word, if you want :) The problem persists: Imagine an extension which adds a menu item which should, say, just display the name of the document-or-how-you-call-it which lives in the frame to which the menu belongs to. In the current situation, this extension's code can rely on ThisComponent being the, well, component in the frame to which the menu belongs. So, whatever it wants to do with the component, it can use ThisComponent. If we had ThisComponent point to the database document, then such code would be more complex, to distinguish between "sub components" and "top level components". The basic problem here is that in the past, "ThisComponent" was effectively used for two different purposes: For a Basic macro which is embedded in a document, it *always* refers to this document. For a Basic macro located elsewhere, it *always* refers to the *currently active* document. (where the problem that "currently active" is not really a well-defined term across different platforms and window managers shall be ignored for the moment). With putting macros into database documents, but allowed to run the macros from the sub components of the document, this was not possible anymore, since now you suddenly can invoke, from within one component, a macro which is embedded into another component. So, we *needed* to separate those two meanings, the question was just which meaning of ThisComponent should be preserved. I still think that defining ThisComponent as "the component from which the macro was invoked" (as opposed to "the component which the macro is embedded into") was the better choice, and causes less hassle. Finally, this means that only newly written code needs to care for the new concept. If we had changed ThisComponent otherwise, then every existing code (implementing such a functionality as sketched above) would have needed to be rewritten. 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
