Howdy,
[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.)
So - I should open an issue?
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.
Yeah right... I never disagree with anyone, on anything. Besides I don't
mind the role of foil or comic relief even.
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.
I belong to the same religion - but sometimes you just have to sin.
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.
Ok but did you just expand the scope of this new variable. It is not
just for Base documents but for any frame?
Drew
