[Libreoffice-bugs] [Bug 63398] After Record Change event triggered too early in BASE
https://bugs.freedesktop.org/show_bug.cgi?id=63398 Julien Nabet serval2...@yahoo.fr changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=63695 -- 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
[Libreoffice-bugs] [Bug 63398] After Record Change event triggered too early in BASE
https://bugs.freedesktop.org/show_bug.cgi?id=63398 --- Comment #10 from Lionel Elie Mamane lio...@mamane.lu --- *** Bug 63291 has been marked as a duplicate of this bug. *** -- 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
[Libreoffice-bugs] [Bug 63398] After Record Change event triggered too early in BASE
https://bugs.freedesktop.org/show_bug.cgi?id=63398 --- Comment #9 from Stephan Bergmann sberg...@redhat.com --- (In reply to comment #8) (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. But that does not match the semantics of UNO oneway (where, rather, the emphasis is on the fact that the oneway method may run in parallel to the caller proceeding, not on a potential delay until the oneway method executes---the intent always was that the delay until the oneway method finishes is bounded by the next non-oneway method call made by the caller, even if the design was flawed; given the UNO oneway semantics, it would look more natural if FormScriptListener::firing would rather chose to not postpone listener invocation for the oneway listener case). To me, it looks like the heuristic of impl_allowAsynchronousCall_nothrow is just as bad as any other heuristic based on UNOIDL type information about the listener, but happened to work well for FormScriptListener::firing. -- 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
[Libreoffice-bugs] [Bug 63398] After Record Change event triggered too early in BASE
https://bugs.freedesktop.org/show_bug.cgi?id=63398 --- Comment #7 from Stephan Bergmann sberg...@redhat.com --- The UNO oneway call concept is documented at http://web.archive.org/web/20100711070220/http://udk.openoffice.org/common/man/execution.html UNO Execution Model (http://udk.openoffice.org/common/man/execution.html appears to have been lost inadvertently). It was only ever translated to asynchronous calls in the case of URP bridge implementations that did not override it to use synchronous calls, and this overriding has ubiquitously been done for ages, first explicitly when setting up bridges and then implicitly in the bridge code itself. That is why it was deemed OK to drop the oneway keyword from UNOIDL with http://cgit.freedesktop.org/libreoffice/core/commit/?id=90eac3e69749a9227c4b6902b1f3cef1e338c6d1 API CHANGE remove [oneway] method attributes. (And that in turn is the reason why the new TypeDescriptionManager implementation in cppuhelper/source/typemanager.cxx always returns false for isOneway.) What has apparently been overlooked by commit 90eac3e69749a9227c4b6902b1f3cef1e338c6d1 is that there were calls to isOneway that required adaptation and/or could be cleaned up. svxform::FormScriptListener::impl_allowAsynchonousCall_nothrow (svx/source/form/fmscriptingenv.cxx) apparently got added with http://cgit.freedesktop.org/libreoffice/core/commit/?id=eae0f62d3f3d1c7b8882b3da9fcfc1cdd094c40b INTEGRATION: CWS dba205a (1.1.2); FILE ADDED, presumably to fix https://issues.apache.org/ooo/show_bug.cgi?id=65420 OO crashes when 'revieve focus' event switches on the Filter Mode. 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. I have an idea, but the fix is risky, and checks need to be made whether existing macros are affected, so this will be for 2.0.5 only in https://issues.apache.org/ooo/show_bug.cgi?id=65420#c10 might be a hint that this was done in an attempt to reduce the risk for regressions. -- 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
[Libreoffice-bugs] [Bug 63398] After Record Change event triggered too early in BASE
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
[Libreoffice-bugs] [Bug 63398] After Record Change event triggered too early in BASE
https://bugs.freedesktop.org/show_bug.cgi?id=63398
Lionel Elie Mamane lio...@mamane.lu changed:
What|Removed |Added
CC||sberg...@redhat.com,
||tbehr...@suse.com
--- Comment #6 from Lionel Elie Mamane lio...@mamane.lu ---
Thorsten? This bug originates from this commit:
commit 90eac3e69749a9227c4b6902b1f3cef1e338c6d1
Author: Thorsten Behrens tbehr...@suse.com
Date: Thu Nov 29 21:27:57 2012 +0100
API CHANGE remove [oneway] method attributes
I don't know what oneway was supposed to achieve, but it had at least one
working effect, that is that the
com.sun.star.reflection.theTypeDescriptionManager service gave a type
description whose isOneway() member returned true.
This in turn is used by
svxform::FormScriptListener::impl_allowAsynchonousCall_nothrow in file
svx/source/form/fmscriptingenv.cxx to return true. What is the link between
oneway and allow asynchronous call? You tell me, I don't know.
This brings us to this bug, namely that the event fires too soon. That's
because of this code in svxform::FormScriptListener::firing:
if ( !impl_allowAsynchronousCall_nothrow( _rEvent.ListenerType.getTypeName(),
_rEvent.MethodName ) )
{
impl_doFireScriptEvent_nothrow( aGuard, _rEvent, NULL );
return;
}
acquire();
Application::PostUserEvent( LINK( this, FormScriptListener,
OnAsyncScriptEvent ), new ScriptEvent( _rEvent ) );
So, in 3.x, this was taking the Application::PostUserEvent route, which means
the event triggered after (about 20 frames up in the stacktrace)
frm::ODatabaseForm::load is finished, and in particular the controls of the
form are fully initialised.
But in 4.0, this takes the impl_doFireScriptEvent_nothrow route and the
controls are not fully initialised yet.
We went even further down this road in master (4.1 alpha)... Since commit by
Stephan, a *different* object is returned by
::comphelper::getProcessServiceFactory().getSingleton(
com.sun.star.reflection.theTypeDescriptionManager )
namely a cppuhelper::TypeManager and not anymore a stoc_tdmgr::ManagerImpl.
Its getByHierarchicalName method returns a (anonymous
namespace)::MethodDescription, whose isOneway() method just harcodes return
false...
FYI, in this specific case:
_rListenerType == com.sun.star.sdbc.XRowSetListener
_rMethodName == cursorMoved
--
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
[Libreoffice-bugs] [Bug 63398] After Record Change event triggered too early in BASE
https://bugs.freedesktop.org/show_bug.cgi?id=63398 --- Comment #5 from t...@tim-passingham.co.uk --- I'm just wondering whether this fault and #63291 are likely to get fixed over the next few months. I want to work out my plan for upgrading to LO 4, or not, as the case may be. The latest Ubuntu ships with LO 4 and I don't want to have to downgrade it if I can help it. -- 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
[Libreoffice-bugs] [Bug 63398] After Record Change event triggered too early in BASE
https://bugs.freedesktop.org/show_bug.cgi?id=63398 rob...@familiegrosskopf.de changed: What|Removed |Added CC||rob...@familiegrosskopf.de See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=63291 -- 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
[Libreoffice-bugs] [Bug 63398] After Record Change event triggered too early in BASE
https://bugs.freedesktop.org/show_bug.cgi?id=63398 rob...@familiegrosskopf.de changed: What|Removed |Added Attachment #8|text/plain |application/vnd.oasis.opend mime type||ocument.base -- 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
[Libreoffice-bugs] [Bug 63398] After Record Change event triggered too early in BASE
https://bugs.freedesktop.org/show_bug.cgi?id=63398 rob...@familiegrosskopf.de changed: What|Removed |Added Hardware|x86-64 (AMD64) |All OS|Linux (All) |All Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from rob...@familiegrosskopf.de --- Have tested the database. Could be the same bug as https://bugs.freedesktop.org/show_bug.cgi?id=63291 . There is something broken with the events, not only after record change, also when loading. There seem to be no fields of the table of the HSQLDB been bounded to the form-fields, when the macro is running. I change the status to New, because it is another event, that doesn't work with LO 4.* Also changed the platform, because the other bug is first reported on a windows-platform. -- 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
[Libreoffice-bugs] [Bug 63398] After Record Change event triggered too early in BASE
https://bugs.freedesktop.org/show_bug.cgi?id=63398 t...@tim-passingham.co.uk changed: What|Removed |Added CC||t...@tim-passingham.co.uk --- Comment #3 from t...@tim-passingham.co.uk --- I agree that this is similar to the problem in #63291. I would not be surprised if it is the same fault, albeit for a different event. I had tried many solutions, and 'Before Loading' was an event I tried to resolve my problem with 'After Change', without success. I also suspected that there were problems with other events. It's a bit more than annoying for me. It makes LO 4 unusable for my purposes. -- 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
[Libreoffice-bugs] [Bug 63398] After Record Change event triggered too early in BASE
https://bugs.freedesktop.org/show_bug.cgi?id=63398 --- Comment #4 from t...@tim-passingham.co.uk --- Sorry - I meant 'When Loading', not 'Before Loading'. -- 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
[Libreoffice-bugs] [Bug 63398] After Record Change event triggered too early in BASE
https://bugs.freedesktop.org/show_bug.cgi?id=63398 Joel Madero jmadero@gmail.com changed: What|Removed |Added CC||jmadero@gmail.com, ||lio...@mamane.lu --- Comment #1 from Joel Madero jmadero@gmail.com --- @Lionel - you mind trying to confirm this one? I try on these database ones but they are often tricky :) -- 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
