#onChangeSelection()

1 messages · Page 1 of 1 (latest)

vocal beacon
#

More to confirm understanding and how this should work.
This seems to fire on a mouseDown and a mouseUp event?
Is that right or is it "me" ?
This is the test I'm using and if I do NOT have a token selected, it fires on a mouseDown and mouseUp.
If I have a token selected, it fires on a mouseUp only


[h: timeNow = json.get(getInfo("server"),"timeInMs")]
[h: deferlink=macroLinkText("onChangeSelection@"+this,"none",json.set("{}","timeThen",timeNow),"")]
    [h: formHTML = "<link rel='onChangeSelection' type='macro' href='"+deferlink+"'>"]    
    [overlay("ActionPads oCS", "zorder=4;"): { 
        [r: formHTML] 
    }]
[h: broadcast("aPoCS time : " + json.get(getInfo("server"),"timeInMs")+" "+macro.args)]
[h: abort(0)]```
compact tinsel
#

oCS is known for many excessive firings, have you tested marquee selection? I recall people setting a flag and testing for duplicates before forwarding the event.

vocal beacon
#

"marquee" selection, I'm not sure I know of this . . .

#

I'm using a time check but I don't feel that's reliable in regards to "too many fires".

#

My other stop-gap is writing to a property on entry but since it can exit twice (if not already selected it fires on a mouseDown and Up, if selected it fires on a mouseUp, resulting in over-firing if not previously selected) and not finding a good way to get in front of one of the mouse events if not already selected.

vocal beacon
#

It's not a mouseUp . . . any mouse action will fire it a second time (if not previously selected).

compact tinsel
#

Marquee = drawing a box.

#

Selection change occurs on mouse down (deselect previous), mouse move potentially (as the box expands to cover more tokens), and mouse up (selection is final). Not sure which of these actually include an event firing but down and up would be the minimum I expect.

vocal beacon
#

I think there is a little bug of sorts where if the first mouseDown is not a token, then fire on a mouseUp,
OR, it should only fire on a mouseUp (I don't like that option tho).

#

Ah, there is a little bug,

With nothing selected, if you do not click the token but use the selection box, it only fires once regardless of subsequent mouse events on selected token.

With nothing selected, If you then select the token it fires on a mouseDown, AND any other subsequent mouse event.

These two tests should not behave differently . . .

#

Would that be correct?

#

This would seem like an easy fix, just check if the first mouseDown is a selectable object vs drawing the selection box (of course that's easy for me to say).
OR the inverse of that, if the selection box is NOT drawn don't fire on subsequent mouse events.

compact tinsel
#

The mouse coordinates of a mouse up are nearly always different from the mouse down. Thus in nearly every case (technically) there is a box. Not sure if the thresholds are set by devs or system or elsewhere.

vocal beacon
#

There's still some sort of buggyness with this, maybe my logic approach is wrong but the behavior should be the same in this example.

#

it knows to not draw the selection box, so there could be a wedge put in.

compact tinsel
#

Now your developing you can go into the code and find out how it works :)

vocal beacon