jacob barton (for whatever reason I can’t link him) discovered this bug with my beta apk of animations.
jacob barton (for whatever reason I can’t link him) discovered this bug with my beta apk of animations.
Scenario:
– any script (even an empty one) set in positionchanged event
– double tap to zoom out
– double tap to zoom in
– force close
However this happens only in a container where my script was running previsiously.
]]>« In Tasker (Previous Post)
(Next Post) I have 2 desktops 1 which is my Normal everyday Home screen/Desktop and the other Desktop is used for my Lock screen… »
D5 Creation
< ![CDATA[
Trying to figure out if it’s my scripts fault…
]]>
< ![CDATA[
Hmm… Ignore this for a while. I am not able to reproduce it myself. weird thing, but I don’t hav e enough time to debug ATM
]]>
< ![CDATA[
I have another phone I can get up and going and install LLX on it and try to recreate. See if maybe it’s my ROM on my Note 3 or what. The other phone is rooted as well but it will at least have no other apps but LLX and stock stuff.
]]>
< ![CDATA[
Also, the script was your In and Out transition apk. I installed it and added the script from the new feature that Pierre recently put in. It wasn’t something I added to the positionchanged event myself.
I will try to remember to get a video of the issue when I get home today as well for you.
]]>
< ![CDATA[
In any case, the app shouldn’t crash, whatever the script is, so there is definitely a bug somewhere in the launcher…
]]>
< ![CDATA[
Pierre Hébert It happens always when my script is active, and sometimes also afterwards. I can’t find malicious code which could cause this. Maybe you can have a look at it?
]]>
< ![CDATA[
Bam!
This is the culprit, just set it in the position change event and zoom
Pierre Hébert
var e=LL.getEvent();
var d=e.getContainer();
var dposx=d.getPositionX();
var dposy=d.getPositionY();
d.setPosition(dposx,dposy);
]]>
< ![CDATA[
Thanks, I confirm that the launcher becomes unresponsive. The issue is that setting a new position while the animation is running from A to B breaks this move.
I will do something to prevent this unresponsive behavior (stop the animation).
]]>
< ![CDATA[
In the past (I can’t remember when but first versions of v10) this didn’t happened. I remember using this code in some of my scripts (for testing/accident) and it just moved the desktop faster than it should. But no crash.
]]>
< ![CDATA[
That’s possible, I remember having changed the way the animation was handled somewhere in the past, this might well be around version 10.
]]>