Issue 103371 - The event when you close a form doesn't launch an assigned macro
Summary: The event when you close a form doesn't launch an assigned macro
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: OOO310m11
Hardware: Unknown All
: P3 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: marc.neumann
QA Contact: issues@dba
Depends on:
Reported: 2009-07-06 23:07 UTC by thierrym
Modified: 2017-05-20 10:29 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Base illustrating the issue (11.03 KB, application/vnd.sun.xml.base)
2009-07-06 23:09 UTC, thierrym
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description thierrym 2009-07-06 23:07:44 UTC
See my attachment :
When you close this form, the macro "ShowMessage" should be launched (a message
should appear). This macro is associated with the event "onClose" ("Fermeture du
document" in french).
Even if i associate this macro with an other event like "onDeactivate"
("Désactivation du document" in french), nothing happens.
Comment 1 thierrym 2009-07-06 23:09:17 UTC
Created attachment 63408 [details]
Base illustrating the issue
Comment 2 marc.neumann 2009-07-07 07:56:54 UTC
confirm and reassign to the right developer. 

@fs: The macro is assign under TOOLS / CUSTOMIZE / EVENTS and not in the
properties of the form.
Comment 3 drewjensen.inbox 2009-07-11 03:49:51 UTC
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.
Comment 4 drewjensen.inbox 2009-07-11 03:50:17 UTC
sorry - added self to CC
Comment 5 Frank Schönheit 2009-08-13 10:02:28 UTC
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

Please advice.
Comment 6 Frank Schönheit 2009-08-13 10:21:17 UTC
Argh! The "Document closing" event does not work for "ordinary" text documents,
too :(
Comment 7 Frank Schönheit 2009-08-13 10:47:11 UTC
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

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

(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?)
Comment 8 mikhail.voytenko 2009-08-13 11:07:58 UTC
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.

Comment 9 Frank Schönheit 2009-08-13 11:33:35 UTC
> 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?
Comment 10 Frank Schönheit 2009-08-13 11:40:49 UTC
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?
Comment 11 mikhail.voytenko 2009-08-13 12:21:08 UTC
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. :)
Comment 12 Frank Schönheit 2009-08-17 14:44:46 UTC
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.
Comment 13 Frank Schönheit 2009-08-19 10:44:52 UTC
targeting to 3.2, since the fix is part of a CWS aiming for this release
Comment 14 Frank Schönheit 2009-08-20 08:04:27 UTC
fs->msc: please verify in CWS dba32f
Comment 15 Frank Schönheit 2009-08-20 08:07:00 UTC
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.
Comment 16 thierrym 2009-08-20 10:13:56 UTC
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.
Comment 17 Frank Schönheit 2009-08-20 10:55:33 UTC
if you submit an issue requesting this reversal, I'm the first one to implement
it :)
Comment 18 thierrym 2009-08-20 14:41:43 UTC
thierrym->fs : So I submitted this issue to reverse the events names : issue
104364. Thank you.
Comment 19 marc.neumann 2009-08-24 13:41:50 UTC
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: