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-libreoff...@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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
