Apache OpenOffice (AOO) Bugzilla – Issue 108859
[From Symphony] Event Worksheet.SelectionChange is triggered, although the selection is not changed
Last modified: 2017-05-20 11:29:49 UTC
Steps: 1.Open the sample file in attachments with OOo. 2.Click Cell C1, SelectionChange event triggered 3.Click Cell C1 again, Defects: Selection is not change, but SelectionChange event also triggered.
Created attachment 67541 [details] Fix for this issue
1. Root Cause: Although selection is not change, but SelectionChange event still triggered. 2. Resolution: Check if the selection is change or not, if it is not changed, do not trigger the selection change event.
you forgot to attach the patch :-)
Created attachment 68282 [details] Patch for this issue
thanks for the patch, wouldn't ScVbaEventsHelper::compareSelection be better to use ScCellRangesBase* pNewCellRanges = ScCellRangesBase::getImplementation( uno::Reference< XInterface >( oldSelection, uno::UNO_QUERY ) ); ScCellRangesBase* pOldCellRanges = ScCellRangesBase::getImplementation( uno::Reference< XInterface >( newSelection, uno::UNO_QUERY ) ); instead of duplicating the XTunnel code already done by ScCellRangesBase::getImplementation ? other than that, seems reasonable, please fix up the patch and commit
Created attachment 68293 [details] Fix up the patch according Noel's comments.
What's the general direction of this? We have event configuration infrastructure (Customize dialog, XEventsSupplier interface) which calls individual macros. Are you creating a second, parallel infrastructure? I'm not sure if that would be a good idea.
>What's the general direction of this? a centralised implementation for faking and firing events associated with the event handlers of vba object ( specifically Worksheet & Workbook ) >We have event configuration infrastructure (Customize dialog, XEventsSupplier >interface) which calls individual macros. This is true, but.. a) doesn't offer a rich enough set of events b) vba event handlers are dynamic, e.g. if you have the handler present defined in the code e.g. Private Sub Worksheet_SelectionChange(ByVal Target As Range) end sub it will get called c) iirc XEventThingymebob doesn't handling multiple event bindings, one binding per event, we are faking events here so often I want to fake other events from one source event, and like I said, we don't want hard bindings because they are dynamic. Ok I know you are going to say but you know what macros you have when you import them. That's true but macro code ofter copies sheets, copy the sheet, you copy the macros ( and event handlers ) and really I don't want to get into tracking all of that... believe me it's easier this way d) the XEventSupplier doesnt allow you to pass parameters ( kindof a disadvantage right? ) e) the event infrastructure is intrinsically asynchronous, doesn't allow for any 'Veto' type operations ( e.g. canceling a close event ) I could go on and on with at least another 20 reasons :-/ >Are you creating a second, parallel >infrastructure? I'm not sure if that would be a good idea. well, its not really parallel, its quite a different concept but... in vbaeventhelper we do hook into whatever uno event thingies that are available and are useful ( e.g various WindowListeners, XChangesListener etc. also we hook into SfxHints ) All these mechanisms are combined and handled in one central place ( rather than have it scattered in many places ) I hear you ask what is the plan?, are you going to upstream it? will you like it? let me answer those questions Q. I hear you ask what is the plan ? A. No real plan besides continuing to make it work better Q. Are you going to upstream it ? A. Absolutely, we have no plans ( and never did ) for this ( or any vba bits ) to be private, the only problem is time, effort, dependencies on other bits yet to be upstreamed etc. Of course if you are interested in the functionality and want to take advantage of it ( and are willing to help upstreaming it ) then you are welcome and you will get 100% co-operation from me. btw. this stuff depends on npower13_objectmodules so... until that gets in there is little point yet. If you are really interested we can try and get this into the next cws. Q. Will you like it ? A. probably not, but this is no public api ( and never will be ). if and when alternative event implementations become available that can replace parts of this hackfest then of course they can be replaced. anyway, if you have more questions etc. I'm sure you know where to find me
Reset assigne to the default "issues@openoffice.apache.org".