I consider this a bug, but perhaps someone is using this ‘feature’ so fixing it could break some little scripts.
I consider this a bug, but perhaps someone is using this ‘feature’ so fixing it could break some little scripts.
When you run container.setPosition(X,Y,S, false) the container don’t stop scrolling.
This mean that if you scroll fast, even if you try to stop the scrolling with that command it will set the position but then it will start again to scroll. More technically the velocity of scrolling is not reset. Perhaps this also happen with true instead of false, I didn’t try.
Another suggestion could be a new function stopScrolling.
]]>« My newest project. It’s still a WIP. Let me guys know what you think. More info soon. (Previous Post)
(Next Post) App Drawer in any Container »
D5 Creation
< ![CDATA[
Hm. I am using that in my scripts, no problem at all, neither with false nor true. Any conditions for that scrolling to happen?
]]>
< ![CDATA[
Just tested with a newly created desktop, and still happen.
Be sure that snap to pages is disabled. Otherwise you can test this little script (it will move an item labeled ‘marker’)
You will see the item moving even after stop scrolling with the finger (the item just shows you the output of .getPositionXY() )
]]>
< ![CDATA[
var cont = LL.getEvent().getContainer();
var posX=cont.getPositionX();
var posY=cont.getPositionY();
cont.getItemByLabel(“marker”).setPosition(-posX+cont.getWidth()/2,-posY+cont.getHeight()/2);
cont.setPosition(0,0,1,false);
]]>
< ![CDATA[
I couldn’t reproduce it neither 🙁 What I have done is : create a new desktop, set snap to page to false and no scroll limit to true (so that scroll is not a problem), then added an item name “marker” and another one (pinned) that triggers the script. Then I initiate scrolling with the finger and immediately after I execute the script through the pinned item.
…While I was writing since, I think I know understand what happens: tapping on the screen to launch the script will stop the scroll, as it would for any other item. Hence I guess that the script is executed from another trigger (a stop point, a timer, or something else), isn’t it ?
]]>
< ![CDATA[
From the positionChange event.
So sorry I didn’t mention. My bad
]]>
< ![CDATA[
No problem, I forgot to say that this is a bug indeed and I don’t think this is something that existing scripts would like to use.
]]>
< ![CDATA[
I couldn’t reproduce it but since I think I understand the cause of the problem, I have applied a fix, let’s see on the next update how it goes on your setup.
]]>