Hi Drew, > Second - The Developers Guide states that thisComponent when used in > application wide Basic is equivalent to StarDesktop.CurrentComponent.
Good point, thanks for pointing out. Seems that CurrentComponent actually is the same thing as what I so far call (technical working title only :) InvocationContext: The document, or the controller if there is no such document, in the currently active frame. > [CurrentComponent tests] > ... > But now - open an embedded form, switch back to the Base document and > call it: > SwXTextDocument That's surprising, and sounds like a bug. (update after digging some code: Argh, that's another incarnation of "the application framework doesn't care for database documents". CurrentComponent is finally fed by the desktop's active frame, which is set by the application framework - whenever a "standard" app's document window gets activated. Base is no "standard" app. Sigh.) > This is the current problem, IMO, however with the Basic in the Base > file and the current definition of thisComponenet used, then you see why > I say it is a plus. Now the macro developer has a workable way to get > what they really want. As said - it would be easy to add some new global DatabaseDocument variable to the macros originating in a database document, so there would be a way in any case. (At this point, I wonder whether you consider it unfair that I first asked for your feedback, and then argue constantly against it. I hope you don't. It's because 1) Objection is a hobby of mine :) 2) I just try to wage different solutions for the same problem(s), depending on the chosen way, and this I need to point them out.) > So, when I look at that I wonder do we really need to change how > thisComponent is defined and do we really need a new psuedo variable even? There's two headaches I would have without the new variable: First, CurrentComponent is a global state. Global states are Evil (TM). That's a mere religion :), backed up by long-year experience. State held in some global place tends to break, or lead to hacks. (Part of the application framework work I'm doing in the course of this whole project is to get rid of global states, since they don't scale anymore, and replace them with context-dependent states.) (And let's not talk about the fact that CurrentComponent seems to depend on focus. Focus behavior on different platforms, especially on different flavors of Unix window managers, is all but a reliable and predictable beast.) Second, CurrentComponent refers to the top level component. What if we have a frame in a frame (say, the data source browser in a text document, or the query preview in the query designer), and configured a document macro into the toolbar of that sub frame? I don't think there are actual use cases for that (in the DSB, you cannot configure document macros, as it displays more than one database document, and in the query designer, there is probably no real need to customize the preview's toolbar). However, I think there *could* be a use case in the future - in this case I don't like to touch the complete thing, again. So, I think some kind of "This is the document/controller in the frame from which the macro was invoked"-variable is desirable. It might not be strictly needed in a first step, but I would like to do it right now, not later. > One last thing - I took some time and went back to OOoForum That's what I usually hope for when asking an audience which includes you :) Thanks. > and did a > search for the use of thisComponent in posts - both questions and > responses and code snippets. Interestingly one can find, none scientific > of exhaustive, that it seems to be used much less frequently on the Base > forum then on the others ( Calc, Writer, Macro ) - It is not uncommon in > the Base forum posts to see the use of the Event Structure. Interesting to know. Thanks & Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
