<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'Sans Serif'; font-size:9pt; font-weight:400; font-style:normal;"> 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 </body></html>