Apache OpenOffice (AOO) Bugzilla – Issue 14703
(form) control event behaviour changed
Last modified: 2003-07-25 09:39:47 UTC
between 1.0 and 1.1 Beta (2), the conditions how events are fired by form controls (I strongly suspect that it also affects basic controls) has changed. Specifically, it seems that nowadays listeners are called when the data of a control is changed by using the UNO API. E.g., the "textChanged" listener of an edit control is called when the text is changed from within a Basic script. Similarily, the itemStateChanged listener for list boxes as well as radio buttons is called when the state is changed from within a Basic script. I bet something similar holds for checkboxes, combo boxes, etc (didn't try everything). All of this wasn't the case in 1.0.x. This is potentially (extremly) bad for existing solutions based on the old behaviour. Finally, we are destabilizing our API with this. If people can't rely on our UNO API being stable, they won't accept it. I'll attach a bugdoc showing the changed behaviour.
Created attachment 6316 [details] bugdoc showing changed behaviour of radio buttons, list boxes, and text fields
Targeting. I know that "OOo 1.1 RC" sounds hard, but I strictly believe that our UNO API should be stable (even if we talk about deprecated interfaces and services). I heard about customers (small companies) where people created applications based on forms, written in Basic, with 2000+ lines of code. This is a huge amount of work invested, and such customers will definately not be happy if we tell them that they have to change their implementations, again.
Please have a look at internal ID #109809# this is definitly a must for RC. Frank
Created attachment 6317 [details] new bugdoc, including check boxes now, and with improved logging of the events
Events are also coming in 6.0 when using awt functions. Only difference now is that events are also triggered when changing properties in the model, I think this is the only thing we should change. To do this, I suggest the following: When a property changed, the peers are only updated via VCLXWindowPeer::setProperty(). Only in this case we shouldn't fire awt events. Use a counter at start/end of setProperty() for bBlockAWTEvents. I think it's OK to block all events in IMPL_LINK( VCLXWindow, WindowEventListener, VclSimpleEvent*, pEvent ) , but only these should be the important events: VCLEVENT_RADIOBUTTON_TOGGLE VCLEVENT_CHECKBOX_TOGGLE VCLEVENT_LISTBOX_SELECT VCLEVENT_EDIT_MODIFY
MT->FS: You offered to do that :)
accepting
some comments on the bugdoc (the second version I attached) and what I think needs to be changed. There are 4 control sections in the bug doc, which all demonstrate differences between events in 1.0 and events in 1.1. radio buttons ============= in the first section, there are three radio buttons forming a group. For every radio button, the "item state changed" event is knitted to the "radioClicked" function. When the third button is selected, this is rejected, and the selection is moved back to th first button. 1.0: In 1.0, selecting a single button results in _1_ call to the macro (as you can see in the tracing window). When the basic macro selects the first radio (because the user selected the third one which is forbidden), this did _not_ trigger the macro, again. 1.1: Selecting a button results in two calls: one for the radio being deselected, and one for the radio being selected. Selecting the third button (prohibited) resulted in the 2 calls mentioned, and in two additional calls when the macro resets the selection to the first radio. text field ========== In the second section, there is a text field. a macro is bound to the "text changed" event. The field allows inputs with up to 5 characters - if a sixth character is entered, then the macro resets the text of the field to the last known valid text. (I know that this particular scenario - input length restriction via macro - is rather senseless, because the same can be reached with the integrated "max text length" property of the field. But you could imagine more sophisticated checks of the input, realized via macro) 1.0: Entering one character calls the listener once. Entering the sixth character also calls the listener exactly once. Resetting the text from within the macro does _not_ call the listener. 1.1: Nearly the same, except that resetting the text from within the macro _does_ call the listener. listbox ======= In the third section, there is a listbox, containing 5 entries, an "separator entry" (consisting of "-"'s only), and another entry (5+1+1, alltogether :). A macro is bound to the "item status changed" event of the list box. It checks if the separator entry has been chosen by the user, and if so, it resets the selection to the last valid selection. 1.0: In 1.0, selecting an entry (either by mouse or by keyboard) triggers the macro exactly once. Resetting the entry from within the macro does _not_ trigger the macro. 1.1: Nearly the same, except that resetting the entry from within the macro _does_ trigger the macro. checkbox ======== In the forth section, there is a checkbox, whichs item state changed method is bound to a macro which simply traces that it has been called. Additionally, there is a button, which, when clicked, switches the state of the checkbox. 1.0: Only the explicit user interactions on the checkbox call the macro 1.1: When clicking the button, and thus changing the checkbox state from within Basic, this also results in the checkbox-macro being called.
I think all of the 4 scenarios above describe valid situations, where we can expect macros which use them to exist. Thus, we should restored the situation from 1.0, even if this means more unlogical or inconsistent to other APIs or whatever - I think consistence with the 1.0 behaviour counts more here.
*** Issue 14565 has been marked as a duplicate of this issue. ***
fs->bc: I did a fix in the toolkit project, and built a new installation set for the CWS dba07. Please adjust your auto pilots, and remove the hacks you had to do when the original behaviour change was introduced.
I adapted the form autopilot and report autopilot accordingly. The other autopilots (web-, euro autopilot and document converter) work fine as before.
verified in dba07
BC: verified in the master->bug closed