Re: Bug 42796 - Macro assigned to dataform Before Unload or While Unloading events are not called when form container is closed

On 04/04/13 11:03, Lionel Elie Mamane wrote:
> On Thu, Apr 04, 2013 at 11:08:54AM +0200, Jan Holesovsky wrote:
> > mcmurchy1917-libreoffice@yahoo.co.uk píše v St 27. 03. 2013 v 09:46
> > +0000:
> > > I've fallen foul of this bug in recent days so have decided to have a
> > > look at it to see if I can provide a patch.
> > Thank you for the offer of help! :-) (...) I'm CCing Noel and Lionel
> > - macros are Noel's area, and databases Lionel's; (...)
> > > In the bug report it was confirmed that a macro assigned to either the
> > > Before Unloading or When Unloading events of a dataform are not called
> > > when the form document is closed.
> > > However, when editing a form and the "Design Mode" option is
> > > toggled the events are called. Also the events when the form is
> > > loaded are called under all circumstances.
> I don't have a code pointer ready to give you, but:
>
> 1) I've indeed noticed that when opening a form in design mode (that
>     is, "edit" instead of "open"), the "open" event is called; I've
>     always found that rather curious, but have never gone through the
>     time to make a complete bug report of it.
>
>     Since you are going to touch that area anyway, it may make sense to
>     conditionalise these events to "non-design mode". Actually, my
>     first thought is that *all* events should be disabled in design
>     mode, but I'm willing to listen to arguments otherwise.
>
> 2) Since you say that in design mode the events fire, my expectation /
>     hope would be that somewhere there is code that does:
>
>     if (isInDesignMode)
>         fireCloseEvent();
>
>     Possibly that is just a "forgotten" negation there; it would make
>     sense to see the git history that put that condition to see its
>     rationale, and if it turns out it is as I think, just add the
>     negation.
>
>     (Or maybe the code is something like:
>
>     if (!isInDesignMode)
>         return false;
>
>     fireCloseEvent();
>
>     and then we have to *remove* the negation)
>
>     Too see where that code is, I'd suggest to run libreoffice in gdb,
>     break on the event being called and then look at the backtrace. To
>     break on the event, you can bind a macro that does:
>      MessageBosx "Even Called!"
>     cause the event to be fired (in design mode, thus) and when you get
>     the dialog, just press CTRL-C in gdb.
well the advice was good ( I was doing it but not looking at my mail to 
see this was answered ) anyway some extra info
First the triggering when in designmode isn't unfortunately that helpful 
( although it does identify relevant code ) because there appears to be 
specific handling for the designmode e.g. see

FmFormView::ChangeDesignMode

 258     // --- 4. load resp. unload the forms
 259     FmFormPage*  pCurPage = GetCurPage();
 260     if ( pCurPage )
 261     {
 262         if ( pFormShell && pFormShell->GetImpl() )
 263             pFormShell->GetImpl()->loadForms( pCurPage, ( bDesign 
? FORMS_UNLOAD : FORMS_LOAD ) );
 264     }

In the normal case of editing the forms ( which presumably that is the 
workflow to normally trigger the event ? ) sorry I am not very db forms 
enabled but I notice that we don't seem even to hit 
ODatabaseForm::load() or ODatabaseForm::unload() ( 
forms/source/component/DatabaseForm.cxx ) Hopefully the code pointers 
above might be useful places to start looking

Noel