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

Lionel

Thanks for the reply. My responses are inline.

Iain

On Thursday 04 Apr 2013 12:03:59 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.

What I've seen is that your description happens when assigning a Macro using

Tools -> Customise -> Events

The issue I'm investigating is when a Macro is assigned whilst editing a form 

Form Navigator -> MainForm ->  Properties ->  Events Tab

The Loading/Unloading events DO get called when toggling the "Design Mode 
On/Off" Icon.

Only the Loading event gets called when the form gets loaded.

The unloading event never gets called when the form is disposed, even though I 
can, using gdb, see it pass over the same piece of code.


> 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.


The above seems to be a neat trick. I've been using break points in the Macro 
to halt the code. Never thought of CTRL-C in gdb whilst the application is 
waiting for user input.


Anyway, this is what I see 


Irrespective of whether toggling the "Design Mode 
On/Off" icon in Edit Mode or closing the form after it has been opened the 
method "SAL_CALL ODatabaseForm::unload" in 
forms/source/component/DatabaseForm.cxx gets called. This method triggers the 
events  -

m_aLoadListeners.notifyEach( &XLoadListener::unloading, aEvt );
and
m_aLoadListeners.notifyEach( &XLoadListener::unloaded, aEvt );


If running in Edit Mode these events cause the control to be handed to the 
appropriate macros as assigned for unloading. Whereas, though I can see, in 
gdb, the events being triggered control DOESN'T get passed to the macros. 

My assumption at the moment is that in disposing the form something has been 
switched off.

I've been looking backwards from the triggers thus far to as far as -

    58              while(!aLocalVOCList.empty())
    59              {
    60                  ViewObjectContact* pCandidate = aLocalVOCList.back();
    61                  aLocalVOCList.pop_back();
    62                  DBG_ASSERT(pCandidate, "Corrupted 
ViewObjectContactList (!)");
    63
    64                  // ViewObjectContacts only make sense with View and 
Object contacts.
    65                  // When the contact to the SdrObject is deleted like 
in this case,
    66                  // all ViewObjectContacts can be deleted, too.
    67                  delete pCandidate;
    68              }

which is in svx/source/sdr/contact/objectcontact.cxx this seems to loops 
around all the controls on the form disposing of them in turn these controls 
may be buttons, sub forms or indeed anything else.


For forms the end of the line is ODatabaseForm::disposing in 
cppuhelper/source/component.cxx which calls the unload method mentioned above. 
When the unload method completes  the m_aLoadListeners are disposed off by a 
call to 

  1324      m_aLoadListeners.disposeAndClear(aEvt);


My next move is to move forwards in Edit Mode toggling the "Design Mode 
On/Off" icon  to get an understanding of what's happening so as I can compare 
against what's not happening in Open Mode.

One question is there any event diagrams or documentation that explains the 
life history of a form - This is what I've got so far 

svx/source/sdr/contact/objectcontact.cxx:67
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx:1720
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx:1001
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx:987
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx:384
cppuhelper/source/component.cxx:178
forms/source/component/FormsCollection.cxx:153
forms/source/component/DatabaseForm.cxx:1307
forms/source/component/DatabaseForm.cxx:2925
forms/source/component/DatabaseForm.cxx:2958



Iain