Issue 108859 - [From Symphony] Event Worksheet.SelectionChange is triggered, although the selection is not changed
Summary: [From Symphony] Event Worksheet.SelectionChange is triggered, although the se...
Status: CONFIRMED
Alias: None
Product: App Dev
Classification: Unclassified
Component: vba (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: All All
: P3 Trivial
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-03 02:40 UTC by lihuiibm
Modified: 2017-05-20 11:29 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Fix for this issue (24.50 KB, text/plain)
2010-02-03 02:40 UTC, lihuiibm
no flags Details
Patch for this issue (3.86 KB, text/plain)
2010-03-11 06:53 UTC, lihuiibm
no flags Details
Fix up the patch according Noel's comments. (3.56 KB, text/plain)
2010-03-11 13:51 UTC, lihuiibm
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description lihuiibm 2010-02-03 02:40:15 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.
Comment 1 lihuiibm 2010-02-03 02:40:47 UTC
Created attachment 67541 [details]
Fix for this issue
Comment 2 lihuiibm 2010-02-03 02:41:25 UTC
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.
Comment 3 noel.power 2010-03-09 11:32:18 UTC
you forgot to attach the patch :-) 
Comment 4 lihuiibm 2010-03-11 06:53:51 UTC
Created attachment 68282 [details]
Patch for this issue
Comment 5 noel.power 2010-03-11 10:35:43 UTC
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
Comment 6 lihuiibm 2010-03-11 13:51:45 UTC
Created attachment 68293 [details]
Fix up the patch according Noel's comments.
Comment 7 niklas.nebel 2010-03-23 14:49:47 UTC
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.
Comment 8 noel.power 2010-03-23 18:07:04 UTC
>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
Comment 9 Marcus 2017-05-20 11:29:49 UTC
Reset assigne to the default "issues@openoffice.apache.org".