This is the first of a list of Bug Report posts.
This is the first of a list of Bug Report posts.
In this way we can focus our attention and discuss them one by one.
Bindings are NOT updated in a “matryoshka” of containers
I saw that someone already report a similiar bug but with folders, maybe both are causes of the same thing…
For matryoshka of containers I mean many containers one inside the others (obviously).
For example, we suppose to be in this generic context:
Desktop (yes, it is also a container) -> container1 -> container2 -> item
Well, the bindings setted to that item (or container, dynamic text, customView..) will be not updated unless we restart LL.
This happen only when 3 or more cointainers are involved && every time LL is paused and then resumed.
The usual question
Someone has already addressed or can confirm this bug?
]]>« How can I eliminate those dots and dashes? (Previous Post)
(Next Post) kwest for Kustom LWP (& Lightning Launcher) »
D5 Creation
< ![CDATA[
(Sorry for the delay!) There was an issue with pause/resume management in a recent previous version that might be linked with this bug. That was tricky, maybe I didn’t solved it completely. I wonder why it would fail only starting at 3 nested containers though (probably a side effect). Would it be possible for you to extract a test case in an empty desktop and share it ?
]]>
< ![CDATA[
I think i am late too (i’m so busy because of university)…
Anyway, i had read your answear a couple of hours ago and till now i tried to reproduce the bug in a clean desktop… but with no success.
After some tests i understand that the bug was caused by a script that was launched at the paused event.
But how can a script that resets some positions gives this problem?(that’s what I asked myself)
I commented a few parts at a time and I discovered the root of the problem:
main.getProperties().edit().setString(“scrollingDirection”, “NONE”).commit();
where “main” is the “Container 1” in the generic context up there.
I already had a problem with this method that it would be discussed in the next post.
Pierre Hébert what do you think about it?
]]>
< ![CDATA[
When changing some properties, the container has to be reloaded so that changes are taken into account. There are side effects to this, for instance:
– if you have a reference to an item in this container before to call commit(), then this reference may become invalid after
– reloading may itself generate pause/resume events, and interfere with the current handling of the pause event
]]>
< ![CDATA[
Based on what you wrote I realized that almost all of the problems I faced in this last month were caused by this bug.
I do some practical examples that describe exactly the two side effects described in your comment:
I) The bug reported in this post –> a script setted at the paused event that resets some positions and sets the “no scrolling” in the container that cointains the items wich bindings are not updated.
II) A script that sets another script at the resumed event of the same item were the first script is launched; the second script, instead, does some actions and then unsets its self from the resumed event.
In theory it works and in fact it worked up to version 12.6 / 12.7, but later I started having problems…
After launching the first script, the second starts right after, because it immediately calls up the resumed event.
There are many other similar bug, but I would not want to waste your time.
However, as I said before, this kind of problems started after version 12.6 or 12.7 (I can’t remember exactly which one) if this can help you to find some solutions:
Do you think you can solve it quickly?
]]>
< ![CDATA[
To be honest: no, I won’t solve it quickly. I currently don’t have a lot of time to work on Lightning, I hope to find more time during April or May, but I have no certainty. There are a few things in the pipe that could be published as a beta and some bug fixes could find a place in it, but I have trouble to finish it. If you could isolate the bug in a desktop this would really help me in reproducing the issue.
]]>