Hi, I updated to 12.6 of a few days ago and I’m getting really weird behaviour:
1: Each time I edit some property of a desktop via scripting the resumed event of that desktop doesn’t fire anymore. A restart fixes the event, but the same keeps happening after editing any desktop property.
2: this may not be only in this version, but if I have an item of which the touch event is set to run this script:
var x = event.getX();
var y = event.getY();
item.setLabel(x+”, “+y);
item.getParent().setPosition(x,y);
When you touch the item you get a sort of planning effect: dragging to the left of the items xposition, the desktop moves to the left too. (This works for all 4 directions btw) But if you either set the display of the label of the item to false, or you comment out the line: “item.setLabel(x+”, “+y);”, it gets really laggy and slow.
I’m hoping this is reproducable, because it would really suck if it can’t be fixed.
Thanks for reading 🙂
Colin
]]>
D5 Creation
< ![CDATA[
About 2: changing the label of a item is a ‘hard’ task (although not really sure why) so changing it on the touch event, or even in the position changed event, lags a lot as you already noticed.
]]>
< ![CDATA[
No it’s exactly the opposite: if the label is shown and continuously edited by the script there is no lag, but when the label isn’t shown or the script doesn’t try to edit the items label it gets laggy.
]]>
< ![CDATA[
Really? Oh, so…less idea than before O.o
]]>
< ![CDATA[
Try to use setPosition(x,y,1,false);
Do you want an explanation why it is laggy? I can give one, but it might be lengthy.
]]>
< ![CDATA[
That solved it! It does work a little different now but that’s not really a problem. I would really like an explanation if you want to give one 🙂
]]>
< ![CDATA[
I know that if you don’t specify the false parameter, the scrolling is animated and triggering even more events in the meantime (or something like that)
But why changing the label fixes this?
Maybe because that operation reduces those extra added events?
I would like a explanation too 🙂
]]>
< ![CDATA[
The first thing is, as TrianguloY said, the animations are responsible for the lags. It’s not that they trigger more events in this case, because the positionchanged event isn’t used inm this case. Instead there are multiple animations running at the same time (setPosition without false is handled asyncronous). To my understanding setting a label invalidates the desktop, which seems to clear all previous animations.
However I’m not 100% sure about this. I would need Lightnings sources to be that, which I don’t have for obvious reasons.
]]>
< ![CDATA[
Thanks for the explanation Lukas Morawietz :). No one able to reproduce the first bug though?
]]>
< ![CDATA[
Little update on the the first bug: item resumed events also don’t work anymore and I noticed in testing that the desktop resumed event normally is also fired after committing an edit, but this doesn’t happen anymore too. I’ve downgraded to 12.5 now and things work again. Hope a future update magically fixes it though, because no one else seems to have the problem
]]>
< ![CDATA[
Regarding 1 pause/resume events can occur when the container is reloaded, and a container can be reloaded when some properties are changed and need a total refresh. The issue is the resume event not firing later could possibly come from the context in which the container is reloaded. In which event is the script running, and which property are you modifying ?
For 2, I think there is something wrong in your script: changing the position of the container will change the relative position of the touched item, and as a consequence the next x/y position of the touch event will be modified according to the container move. Since things are done asynchronously this may result in differences between the current container position and the x/y values in the event. More generally this is not predictable. I am not sure, but I suspect that changing the label triggers a layout pass and changes the behavior of this feedback loop.
Instead, try to use absolute coordinates using Container.translateIntoScreenCoordX(float), so that the delta position is not affected by the container move.
]]>
< ![CDATA[
Thanks for your detailed reply Pierre Hébert!
Regarding 1: I’ve tried different things now and it doesn’t matter if the script that edits the desktop is ran from the app menu or an item tap for example. Also what property I modify doesn’t matter, but with properties.edit().commit() it doesn’t bug out.
I kinda gave up on what I wanted to do with 2. Thanks for the explanation though!
]]>
< ![CDATA[
So after I updated to 12.7b2 the problem om 1 seemed to be fixed, but is has come back. I decided to record some catlogs: one where the resumed events fires normally, one where I run a simple script that breaks the resumed event, one where I open ll, but the resumed event doesn’t work anymore and one where I run the script that breaks the resumed event in 12.5.1, but the resumed event keeps working. The catlog app recorded everything (so min priority verbose), but I filtered on logs coming from ll.
This is the script that breaks the resumed event:
LL.getEvent().getContainer().getProperties().edit().setEventHandler(“bgTap”, EventHandler.EDIT_LAYOUT, null).commit();
You can find the logs here: http://1drv.ms/1RtOZ2R
Pierre Hébert If you have the time please look at them. If there is anybody who can figure out what is going wrong it is you 🙂
Thanks in advance
]]>
< ![CDATA[
Found an interesting workaround: the resumed event if everything in the container that is edited breaks, but if the breaking script is ran in a panel and not in a desktop, only the resumed event of everything in the panel and of the panel itself breaks. I was already testing my scripts on a separate dekstop, but now the testing is really well contained xD
]]>
< ![CDATA[
Sorry if i’m making you read way to much, but I also got the idea to delete ll’s app data and try in a freshly installed version if the bug still persists and it does. I thought maybe there is something wrong with my setup or I did something that broke it but it really seems to be the combination of 12.6+ and my phone 🙁
]]>
< ![CDATA[
I finally fixed the pause/resume event bug, thanks for all your hints!
]]>
< ![CDATA[
Omg thx so much :D. I thought I was gonna be stuck with this bug forever! (Or maybe until I’d get a new phone, but that is still gonna be a while anyway).
Thank you!
]]>