Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||XCloseable interface vs the Dispatch Call to using .uno:closeDoc|
|Product:||Writer||Reporter:||Andrew Waller <andrew.waller>|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||andrew.waller, elish, issues, oldspiceap, oliver.brinzing|
|Issue Type:||DEFECT||Latest Confirmation in:||4.1.0-dev|
Description Andrew Waller 2013-10-10 21:37:17 UTC
Created attachment 81744 [details] simple macro which helps to demonstrate the issue. There seems to be a difference in the EventListener between when you call the XCloseable close(true) functionality to when you go to the open office File -> Close option. If I use the XCloseable close(true) the event for "document is closing" does not seem to fire however the "document closed" event does fire. If I use the Open office file menu and choose File -> Close, I see both the events for "document is closing" and "document closed" The attached Macro module is a simple module that I used to help show the problem. If you install this module and then go to Tools -> Customize, and from there to the Events tab. If you change the events to the global OpenOffice.org Listing. Then set the events for "document is closing" and "document closed" to the Module6.xba's functions(closing/closed). Then on the toolbars tab of the Customize screen add the macro closeDoc or just run the macro through the normal macro run functionality. You will see that the behaviour between using the macro which calls the XCloseable behaves differently to if the dispatch call is used from the File -> Close.
Comment 1 Oliver Brinzing 2013-10-11 04:53:57 UTC
Comment 3 Oliver Brinzing 2014-04-17 16:17:38 UTC
this will add an close listener to a document: Sub Start() addCloseListener(ThisComponent) End Sub Sub addCloseListener(oDoc as Object) xListener = createUnoListener("close_", "com.sun.star.util.XCloseListener") oDoc.addCloseListener(xListener) End Sub Sub close_queryClosing(evt as Object, bOwnership as Boolean) MsgBox "queryclosing" End Sub Sub close_notifyClosing(evt as Object) MsgBox "notifyClosing" End Sub Sub close_disposing(evt as Object) MsgBox "disposing" End Sub result: query -> notify -> dispose if i add macro sub's to events from tool - customize - events menu - as described above -, i get only an event for "document is closing"
Comment 4 Edwin Sharp 2014-04-17 16:28:48 UTC
Thank you Oliver Only "notifyClosing" window is shown when closing document. AOO420m1(Build:9800) - Rev. 1586681 Rev.1586681 Win 7 PS macro close_notifyClosing assigned to event "Document is going to be closed".
Comment 5 Brant Watson 2014-04-17 16:34:51 UTC
@brinzing That still doesn't really explain the behavioural differences. In one scenario two events get fired, but in another, only one event gets fired. While sure one could do some magic to add a listener to coerce the other into firing, that kind of is silly (not to mention it might not get fired when it really should). In any case, this is more about a behavioural differentiation between what should not be dissimilar actions. It may be a simple call has been left out but I haven't been through any of that code in ages. Either way I can also confirm this is an issue, and has been for some time.
Comment 6 Oliver Brinzing 2014-04-18 06:25:28 UTC
@Brant Watson you are right, my macro shows, the XCloseListener works in general. someone should check the source code, seem the trigger from tool menu is broken.
Comment 7 Brant Watson 2014-04-24 14:38:25 UTC
@brinzing - I think it might actually be the other way around. It seems to me that the "document is closing" and "document closed" events are both important (the distinction is there for a reason anyway), and anytime a document is closed one would expect to see both events fired. It probably makes more sense to figure out why XClosable doesn't trigger both events as opposed to checking the menu code to figure out why its firing both. There are probably two seperate codepaths for closing a document happening, otherwise there wouldn't be a behaviour descrepancy. Whatever the reason though, I think the correct fix would be to make sure that XClosable properly fires the "document is closing" event.