Apache OpenOffice (AOO) Bugzilla – Issue 14585
Basic IDE checks code when switching to dialog and locks
Last modified: 2003-09-15 09:16:36 UTC
When you have an invalid code line and you switch to the dialog page, the IDE keeps popping up a syntax error dialog, but won't let you correct the error. You have to shoot the application to get rid of the problem, on reopening the problem starts again. Create new sub Create new dialog Enter incomplete line like i = Switch to dialog Behold! An eternal message loop.
TM->JSK: Please have a look ! Thanks !
checked in 644m11 (8591) - cannot reproduce
Created attachment 6468 [details] Test case: endless loop when listener is active
Reopen, testcase attached
Ah, yes. Better this time. I'm not able to reproduce the issue with the dialog only, but with the open application window ... jsk->mba: i think this is one for you.
BasicIDE is not my playground. :-)
set target to OOo 2.0
I confirm the issue. The Eventlistener remains running while there is a BASIC runtime error and thus blocks the IDE - the EventListener is called on each mouseclick event. When a runtime error occurs, execution of the macro should be stopped, eventlisteners should be stopped. jsk->tbe: I think we should be able to handle it. You certainly have a point that this is a "unusual" way of programming but i can easily imagine how this happened.
When a runtime error occurs, the execution of the macro is stopped. The problem is, that the macro is assigned to a document listener and whenever a document gets the focus, the macro starts execution. One problem here is that in our office the Basic IDE is also treated as a document. But even if the Basic IDE would not be treated as a document, one can find scenarios where an erroneous macro is executed again and again. I think if a macro is assigned to such delicate things as focus events, it is the responsibility of the macro programmer to handle this. I think it is not the responsibility of the Basic IDE to remove all event listeners in the case of a runtime error, especially not in the case as shown in the bug doc. As the macro programmer registers the event listeners in the Init method, he can also write an error handler, where he removes the event listeners in the case of an error. Example code: REM ***** BASIC ***** Dim oListener As Object Sub Init oListener = CreateUnoListener( "DocumentListener_","com.sun.star.document.XEventListener" ) ThisComponent.com_sun_star_document_XEventBroadcaster_addEventListener( oListener ) End Sub Sub DocumentListener_notifyEvent( event as object ) On Error Goto ErrorHandler print event.EventName if event.EventName = "OnPrepareUnload" then print event.Source.URL endif Exit Sub ErrorHandler: ThisComponent.com_sun_star_document_XEventBroadcaster_removeEventListener( oListener ) End Sub Sub DocumentListener_disposing() End Sub
Hi Dietrich, congratulations, you have found one quite nasty flaw in our implementation of event-listeners. ;) After lengthy discussions we have found that fixing it is not possible at this point - it would require a major redesign of our BASIC-API. All we can do for now is asking you to be extremely careful with focus events. They usually are quite tricky (no matter which programming language used). I'm setting the state to "WONTFIX"
Closing