Hi Drew, > The first question I have is regarding the proposed change to > thisComponent behavior. Why?
For consistency reasons, I'd say. However, thinking about it, it of course depends on the definition of ThisComponent, and I fear there is none. We'll enter virgin soil in this respect. > The simple case in point - menu handlers as sub procedures - since these > receive no event structure they need to rely on thiscomponent to get a > reference to the embedded form that the menu is currently displayed on. Uh - this (not getting a context) is a bug in the menu handlers, IMO. Though this opinion doesn't help here :). Can you provide a sample document? I don't have a clear opinion about this before knowing exactly what we're talking about. > The one problem that does need to be addressed with thisComponent ( and > maybe this is what you meant ) is that currently DatabaseDocuments do > not work with that variable, so you can not use it if that is the > current component on the desktop. This wasn't on my list, yet. It's no, though I don't have an answer at this point. In general, I am reluctant (which doesn't mean it's impossible) to let database documents participate in the global "ThisComponent" thing, the reason being that this kind of global state usually proves to be error-prone. However, if you say there's a class of use cases which needs this ... As sad, a sample document would help sharpening my opinion :) 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]
