With the new update 8.1.12 I was looking forward to the changes: 1518: Popup View params reset when popup is dragged
But it seems they break a bunch of stuff!
I have a binding on the viewparams and it keeps reverting to the inital values even without moving the popup, just trying to change the valeus isnt working.
I put a onchange script to log the origin and it seems the first time it goes right getting an origin from binding, but right after i get origin browser which sets it back to initial value...
This is quite the breaking bug, now they are instantly resetting instead of only when moved
It worked before the update => Confirmed by downgrading again to 8.1.11
Update it seems to be working with the base ignition components?
However the property that i binded too is from my custom model, it gets changed through a javascript, might this be the case? Does it think it being changed by javascript is the same as moving ? Altho that should been been fixed already, did you prevent changing by javascript? (which was the cause of the moving bug?)
It worked before the update => Confirmed by downgrading again to 8.1.11
I do not seem to be able to easily replicate it on a different view/project tho⌠weird
ill test some further after lunch.
Set it to 8.1.12 and it again was resetting because of a browser origin.
Sorry to hear about this. We canât help you unless you give us a little more insight into your setup. Describe the contents of the popup, the popup configuration, and how view parameters are configured. The only thing that was changed on our end was in the popup itself, with better tracking of outbound view parameter values. The fix didnât have anything directly to do with our components. So, Iâm curious why your custom component and model is the exception?
I dont have acces to the pc atm but iâll list what i remember now.
I dont know if its really related to my component. Im really not doing anything special or weird with those props. Just a PropertyTree.write(array of dicts). That i trigger when a row is clicked in my table .But i dont know what else could trigger a prop change with origin âbrowserâ as i do know the props from my component get changed through an origin âbrowserâ
The viewparams are supplied by the system.perspective.openpopup()
the view paramas is set to input/output <=> and one of them has a binding to my property.
It seems to happen on bi-direction and one way. The binding is confired on the viewparam.
The viewparam also has some onchange script on it.
the logs dont show anythign so maybe ill try and check with a wireshark to see where this 'browser" input comes from. The problem is it is on a gateway that is being used. And i wasnt able to replicate it on my local machine (yet)
binding and onchange script on a view param may not be ideal, but it works in 8.1.11 and even when i make a copy of the view (apart from the data) it seems to be working. And the data rly shouldnt affect this, it get changed back by the browser soâŚ
im not rly doing anything special in my module for this prop, just setting it to [] on startup so no rows are selectedâŚ
Nothing on my end should be able to change the viewParam with an origin on browser, so it gotta come from the component of igntion, If im understaning the originsâbrowserâ right.
The weirdest is that it doesnt seem to be replicatable in a different view it definitly happend again when turning to 8.1.12
In the copy which is working fine i made im getting onchange events from:
on startup of popup:
Project (passed down viewparams[dataArray]) => Binding(props(null)) => Browser(??its setting it back to viewparams[dataArray]??)
after changing something:
Binding (props)
I cant test on the other project atm, but it seems in this one it also gets set back to the default by browser, but only on startup. Could something have happend that causes it to sometimes keep triggering?
I added some breakpoints on my component in run time and it does seem like it only triggers the browser script after my component does something. But how can it change the viewparam while its not connected to itâŚ
Does the property binding refer to the script in my code instead of just the value?
(sorry if i referred to some unrelated staff, you 4 just seem to be the most active xd)
I have made a copy of your radComponent of github (might be an older version) and made a tiny adjusment to the image, just added in a tree.write which triggers on ever render that returns the date. Nothing special.
Then iâve made a view which opens a popup with the binding as i have setup.
Most of the time (not always it seems) it also triggers the browser revert at the start
Please take a look into this
ive proved an export of the 2 views and the adjusted module RadComponents-unsigned.modl (113.3 KB) testStorage_2021-11-23_0043.zip (5.8 KB)
In my other project it sometimes even triggers not on startup, but all the time. But its hard to replicate even with my own component⌠But it has to be related to this.
No itâs not, my component only writes at the start and on some client click events.
I just made this example as simple as possible xd As it seems i can only replicate it if it triggers very fast i figured the render would be the way.
In my project it also happends on the click events (so every write?), but i dont seem to be able to replicate that even if i copy the view.
I also was hoping one of these triggeres in the infinite loop would also get set back but seems that wasnt the case. I have no idea why i cant replicate what happens on the click events, but it gotta be related to this happening at the start too somehow. Some new write back in the main code somewhere?
Yes I encountered this as well. Whenever I would open up a popup it would reset the page params on the original view. Wound up recoding both views to only use params on startup.
Will you please explain to me how you have your popup configured. Iâm not sure what âoriginal viewâ means. Are you saying that your popup View is writing back to a property of the Page on startup? By âresetâ you mean writing the value of a persistent property? Is this happening occasionally or is it consistent and easily reproducible? Thanks.
Scratch that. Iâm able to reproduce the issue. Doing some investigating. Will respond with what I find. Thanks.
Itâs an incoming view property update that arrives after the popup is closed, gets stored (a mechanism of async view loading), and then applied once the popup opens again, but seemingly out of order. If you donât interrupt the property sync between the view and the gateway, i.e. not closing a popup abruptly mid sync, you shouldnât encounter this issue. Also, if itâs the first time opening the popup, you also shouldnât encounter this issue. Anyways, we already have a solution, currently awaiting review, that is meant to address this general behavior. Iâm glad you brought this up. We should have a fix up soon. Thanks again.
For me on one of my views it triggered on every tree.write(). but i wasnt able to reproduce it elsewhere. But i hope the fix on startup also fixes that one^^
Thanks for looking into it and finding a quick solution! Let me know if its in the nightly so i can test if it works
Hi, there will be something in the next nightly that should hopefully fix the issues you are seeing. At least, it does fix the initial write back from the browser, and we hope it fixes your other issue relating to clicking. Let us know. Thanks.
So i got the 8.1.15 nightly and im still seeing the initial write back.
Did i get the wrong version or has it been changed again?
Edit:
Hm no it does seem the banana gif isnt writing back anymore,
but my own component is...
sigh
anyways the click issue doesnt seem to happen again, but it was already hard to replicate so idk if that says anything right now xd
I must say the initial loading of my component isnt the cleanest, So it probably is interupting a bunch of things in itself, but i dont think that should trigger a de-sync on the popup level xd
it definitly happend again when turning to 8.1.12