https://bugs.freedesktop.org/show_bug.cgi?id=63398
--- Comment #8 from Lionel Elie Mamane <lio...@mamane.lu> --- (In reply to comment #7) > It is unclear to me > though why the decision whether to call listeners directly or to postpone > that via Application::PostUserEvent should be based on whether the listener > method is marked as "oneway." To me, it makes sense. If the listener method says "I can be called asynchronously" (that is, "I am a one-way method"), in particular it means "there can be an arbitrary delay between the moment my caller asks for me and the moment I actually execute; my caller is allowed to continue executing *before* I start/finish executing." So, svxform::FormScriptListener::firing tests if it is "known safe" to continue executing while the event listener method is "pending", and if it finds that it is, then do it. It is important that some events are postponed. For example, the "finished loaded" event of a control. Imagine it is bound to a macro that references *another* control in the same form. If the event is not postponed, the other control could not be initialised yet, and the reference wreaks havoc. If it is postponed to until *all* controls are initialised, then it is safer/simpler/... for the script author. But it is out of the question to postpone *all* events. For example, consider offapi/com/sun/star/form/XApproveActionListener.idl; the calling code *must* wait to see whether the action is vetoed or not! The same for property listeners and their vetos. Another possible heuristic would be to postpone events whose listener method returns void; but that smells "more unsafe" to me than using oneway... -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
