After updating to a new nightly (on b2019030102 now), I tried opening some of our default screens/templates. When opening our navigation template, it apparently crashed on a binding, and now the designer is stuck.
I can’t close the error popup, and I can’t interact with the designer anymore.
Did you update your designer also? Any time you do a daily update you also want to reinstall the designer.
I did download a new designer from the gateway page, let it install and opened the project from there.
Is there a way I can confirm the version of the designer?
This is not true, actually. The ‘designer launcher’ and ‘client launcher’ applications are separately versioned from the gateway itself. You can check what version of those applications you have in the ‘about’ window in the designer launcher, but they will always download and launch an up to date version of your designer/clients from the gateway.
As for the underlying error here - I assume these templates are present in the .gwbk you sent me earlier? I’ll try opening them and see if I can get a stack trace out.
Yes, it’s still the same project. It’s a good stress test IMO, as it’s an addition to an older project (7.8) we’re currently developing. So it’s a bit messy in parts (as the PLC code also evolved, and now uses different structs compared to a few years ago, which has an effect on everything else).
But if it’s possible to get this working, we can be pretty confident about 8.0.
Any updates on this? Were you able to find something? Should I try to narrow it down?
I did investigate this a bit further, and was able to see this error in the console.
I couldn’t scroll inside the console as the designer was stuck.
However, given the script mentioned, I do get an idea why it’s happening.
That script uses a dataset client tag to draw the buttons. The client tag itself is actually a reference to a gateway tag (via an expression). It just gets cached locally that way.
But when I open the global project, I don’t see a “tags” folder as with the child project. So I guess the tag somehow errors out on its binding, and the designer spits errors at a rate that completely locks it up.
EDIT:
This is the script, so it crashes indeed on getting some data from a tag that doesn’t exist.
Next question, what’s the new proposed way to work with tags and multiple projects. Especially coming from the global and child projects?
You're close - I was actually able to open this in a designer and stay usable (albeit, things were flooding the logs at a fairly ridiculous rate). You should have better luck if you open SharedTemplates/10_Navigation/tmpButtonNavigation instead of SharedTemplates/10_Navigation/tmpNavGrid - since the latter contains many instances of the former.
The root cause of your problem is related to the tags, but is actually caused by your new 'global' project not containing any client tags - since they reside in the project before it was upgraded. Unfortunately, I'm not sure whether that's something we can "fix" without introducing other issues - if we copied your client tags into the global project on upgrade, you would end up with duplicated client tags. I suppose if we find more users running into issues like this, we may need to do something like that.
I actually ran into this issue when upgrading our 7.9 project and put a duplicated version of the client tags in my global project and haven’t seen anything odd. It doesn’t look to me like the client tags are inherited between projects (or if they are supposed to it is not happening). To test this I put a test folder and a test tag in my client tags for my global project and when I re-opened/updated my project that inherits from the global I don’t see the client tags being inherited.
I really think you should allow these in parent projects. Name collisions have to be handled on other resources -- I don't think that's a good reason to leave them out.
If client tags aren’t inheriting, I would definitely say that’s a bug. I just opened a ticket this morning to add a client tag node to the project browser (since, misleadingly, client tags are a resource, not actually tags), and if we do go down that road we’ll definitely look at whether inheritance is working properly.
If you’re actually asking for something else, please clarify - I feel like I may be missing something.
I guess my main issue here was lack of diagnostic tools (or any tools I knew were getting non-responsive). Perhaps there is a way to keep the designer responsive in such cases by disabling the bindings after X retries?
Then at least we can investigate the first errors, and see why it's bugging out, and whether it needs to be fixed.
So there is definitely something going on that is buggy (or at least acts differently than the other inherited resources) with the inheriting of vision client tags. I created a new test project with my global as the parent and that project inherited all the client tags, however if I go to my parent project and add new client tags I don’t see the updates propagate the way I would expect. So it would appear that the client tags are only inherited during the creation of a new project, but not when you edit the parent project.
Additionally all of the other inherited resources appear as a light grey, but the client tags are the same dark black font as all other items that are not inherited.
