Created attachment 63408 [details]
Base illustrating the issue

confirm and reassign to the right developer. 

@fs: The macro is assign under TOOLS / CUSTOMIZE / EVENTS and not in the
properties of the form.

Currently there are two different events one can assign to macros that may make
sense here.

1 - From Tools>Customize. Instead of selecting the events for the individual
form if you select the events for the ODB file you find "Closed a
sub-component". An embedded form is a sub-compoenet in this context and the
macro will be called when any form is closed. (or Query, Dataview, Report
designer, etc)

2 - The dataform control also has two events than can be assigned to macros via
the property editor. "When unloading" and "Before unloading" and a macro
assigned to either will be called when the form is closed.

So my question would be: Should the form also expose the "Close event" when
embedded in an ODB file? If not then I would suggest to change this Issue to ask
for the event entries to be removed from the Customize dialog when displayed for
an embedded form.

sorry - added self to CC

fs->mav: In SfxObjectShell::PrepareClose, the SFX_EVENT_PREPARECLOSEDOC event is
not fired for embedded documents. It would be easy to change this, however, I do
not know whether this is a good idea, so I'd be interested in your opinion.

We could either say that this event is not supported for embedded documents (and
thus database forms), in which case I should remove it from the Tools/Cusotmize UI.

Alternatively, we could fix PrepareClose to fire the event earlier. I would
prefer this approach, since it would add consistency: All other events (e.g.
OnUnload, OnPrepareViewClosing, OnViewClosed) are also fired for embedded
documents, so I do not see a reason why this shouldn't be the case for
OnPrepareUnload.

Please advice.

Argh! The "Document closing" event does not work for "ordinary" text documents,
too :(

Some terminology, as this is something which confused and mislead me, too:

"Document closed" is the event which is fired when the document *is about to be
closed*.

"Document is closing" is the event which is fired when the document *has been
closed*.

(That's nothing the online help will tell you, sadly. And the wording, IMO, is
most misleading here.)

As a consequence, offering the "Document is closing" event in Tools/Customize,
for a concrete given document, is questionable: When this event is fired, then
the document is already dead, so you cannot call any macro code in this
document, anymore. This is the reason why assigning a document-local macro to
this event does not work at all.

A second consequence is that in the attached database document, the macro needs
to be assigned to the "Document closed" event in Tools/Customize.

Sadly, this alone isn't enough to make it work, there's still the problem I
mentioned above (internally the event is not fired at the moment, at least not
for database forms).


So, my suggestion here is:
1. Find a volunteer for submitting an issue requesting those event names
   being improved
2. Find a volunteer for submitting an issue requesting that the user is
   warned when she assigns a document-local macro to the "Document is
   closing" event, as this will never be executed.
   (Or prevent assigning document-local macros here at all, while global
   macros probably should still be allowed.)
3. Fix the issue that the "Close document" event is not fired for database
   forms (@mav: See my suggestion above, moving the notification of
   SFX_EVENT_PREPARECLOSEDOC up a few lines is sufficient here)

I'd take 3. anybody for 1./2.? (Or anybody arguing that this is nonsense?)

I must confess I am also quite confused by events names now.

Anyway I have nothing against activation of this event for embedded objects as
well. We should only be sure that the applications do not do unnecessary actions
in case of embedded object when the message has been sent. In other words the
implementation should be carefully tested for all the kinds of embedded objects
after the change is done.

> We should only be sure that the applications do not do unnecessary actions
> in case of embedded object when the message has been sent. In other words
> the implementation should be carefully tested for all the kinds of embedded
> objects after the change is done.

Sorry, I am a little bit lost here: Wwhat kind of testing do you mean here? In
which circumstances does our application react on document events?

Grokking for SFX_EVENT_PREPARECLOSEDOC gives one occurrence, namely
SwXAutoTextEntry::Notify, which looks as if it would be a good idea to fire this
event for embedded documents (else SwXAutoTextEntry instances, if ever existent
for such docs, might miss something). All other occurrences are trivial.

Do you know of places in the OOo code which listen to the UNO events, instead of
the SFX events?

Exactly, I have meant the implementations like the one in writer. I am not aware
about an implementation that would catch the event in UNO format.
Anyway, I would test the handling of the embedded objects during CWS testing, at
least the related automated tests. Code review is good, but the review with
testing is better. :)

okay, I committed the patch for objxtor.cxx (for notifying the event somewhat
earlier) to CWS dba32f, and will ask QA to run automated tests regarding
embedded objects.

targeting to 3.2, since the fix is part of a CWS aiming for this release

fs->msc: please verify in CWS dba32f

fs->msc: As said above -in the bug doc, a macro is assigned to the "Document is
closing" event, which is wrong - it must be assigned to "Document closed".
Before the fix, this wasn't called, now it is.

fs->thierrym: Offering the "Document is closing" event (which has a wrong name,
see above) for the document itself is nonsense, strictly, there is no
possibility that this is ever called, since by definition the document is
already dead when it would need to be fired. However, "Document closed" works now.

Thanks for your works and thoughts.
The names of the events (as you said above) seems to be the problem.
For me (a french people who speaks with some difficulty in english), "Document
closed" means that the form is already closed so launching an embedded macro is
a nonsense and "Document is closing" means the document is about to be closed so
an embedded macro can be called.
So in my humble opinion, perhaps the names should be reversed.

if you submit an issue requesting this reversal, I'm the first one to implement
it :)

thierrym->fs : So I submitted this issue to reverse the events names : issue
104364. Thank you.

verified in CWS dba32f

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba32f