We upgraded to 8.1.24 this morning and after doing so any animations we had using style classes are not longer working. The tags and bindings show good, but it is not animating with the style classes we have set with the our transforms. If we set the fill color manually, it will change. Anyone else experienced this?
1 Like
Are you using vision or perspective?
@andrews Style classes = perspective
I haven't has any issues and have two sites on 24
Might need more info on what you're animating, and does it work of you just set a static style class?
1 Like
This is a long shot, but are you changing style classes based on some variable or alarm? Do they sometimes not fill upon startup?
@nminchin If we set a static style class it still does not animate. If we set a static fill color, which is what our style class is bound to, it will change the color.
@Adriaan.leRoux We animate with a style class based off a state from our PLCs. Our components are assigned a state (number) and we use that assigned number and a transform to assign a style class for color animation.
What is really needed here is:
- An example of a component which uses this Style Class.
- An export of the Style Class.
- A screenshot of the binding which drives the style class value, and/or a code snippet of any script transform on the binding.
Also, what version did you upgrade from?
Good Morning! I was part of the "we" in the original post. Sorry for a delayed response but we did a training(shout out Bobby and JT) and catching up on projects. I believe Brian has had to revert to 8.1.20, the version we upgraded from, for other projects. I am still at 8.1.24 experiencing the same issues. Below are the above requests:
- We use the symbol factory's basic Conveyor, Belt, Arrow-No Crescent Arrow, and other basic shapes.
- The style class examples are attached but just basic fill color and stroke settings.
- attached screenshot of binding to symbol
StyleClassExamples.zip (3.3 KB)
Please let me know any other information we can provide! Thank you!!
1 Like
I tried to replicate your issue today and found that changing style classes of the Arrow drawing/svg at the specified location in the screenshot (props.elements[0].style.classes) does not change the appearance of the drawing in 8.1.24. I was ready to open a bug based on this, but I wanted to verify a change in behavior, so I tried to do the same thing in 8.1.20 with the same result - my setup didn't work in 8.1.20 either.
In order for me to act on this, I need to be able to verify a change in behavior from a known version. If you can provide similar screenshots to what you provided of the issue in a version where it is working, I can continue investigating and open a bug. If you're not able to provide the screenshots, you'll need to go through Support, as they're better equipped for longer investigations.
Here are some screenshots in a system that is live in production and working on 8.1.20. If best to open a ticket I can do that instead. I have gotten quite spoiled of all the great information and help in these forums!!
Those Map transforms (and even the symbol in use) do not match up with what you supplied previously.
Not that I expect different behavior, but when trying to replicate issues we need to know the exact scenario under which something was working before it broke. Even small changes can make a big difference.
My apologies, we changed the normal BOOL PE tag to a DINT to add a state for if it was jammed at that PE on this job. I can get a project that uses true/false BOOL like originally instead of 0-2. This project is also in production and running so I could use the same PE for the state this time! haha. In case that adds any more trust i am not making this up! It also shows the basic conveyors animating the fill color in the screenshot.
On this, and apologies in advance for the "inverted" rant, I recently did some work on another scada platform, and was having issues simply getting alarms to display in the clients. I trowelled the forum and their knowledge base and found nothing useful at all. I would have called support, but it was out of hours and the customer doesn't have a support contract, so they wouldn't have helped me anyway, despite having our own high level integrator support contract (this is only for help on new projects 
).
Back on topic.. The Ignition forum really is a stand out difference between other platforms, and its by no means a small difference. You can get support from experts including from the devs and support guys (case in point in this topic, and pretty much every other topic) who know the product inside out and are passionate about their craft. The forum is an absolute wealth of knowledge. The guys and gals at IA also listen to your ideas and suggestions (the ideas canny.io site is a testiment to that) about ways to improve the product, and some of these may actually make it into the product (I've personally had a few of my bigger suggestions come to fruition). I sent a list of 10+ suggestions 8 years ago to another SCADA platform contact, and absolutely nothing whatsoever came of it. If it's not obvious, I have a massive amount of respect for the guys/gals at IA 
16 Likes
Okay, I (we) found the issue. What you're actually encountering is we fixed a "broken" behavior which you had unknowingly been reliant on leading into 8.1.23.
Take a look at the props.elements[0].fill.paint property in both versions (8.1.20 and 8.1.23). Note that it's the same in both. No big deal, right? Wrong; in 8.1.20, that fill property was applied to the drawing/symbol/svg as an HTML attribute, as opposed to a CSS style property. This meant it didn't behave according to the expected CSS rules if inheritance and specificity and would always be overridden because it wasn't technically an inline style as far as the DOM was concerned.
Expected order:
Theme files > stylesheet.css resource > Perspective Style Class > Inline Style
We fixed this behavior, but since the "hard-coded" value is now in place as a proper CSS property it is overriding the Style Class value for fill (as it should).
If you set props.elements[0].fill.paint to an empty string for each of those drawings/symbols/svgs, your bindings will begin working as you expect.
Unfortunately, this empty string approach is not something we can put in place on our end, because to do so would mean that Symbol Factory svgs would render without any colors at all.
3 Likes
You should just be able to delete the fill key entirely. This is what I do.
(I need to learn more about all the components that make up the raw HTML... This would be handy for diagnosing issues looking at the source in the browser dev tools. I have a basic/moderate understanding, but it could use some more!)
3 Likes
This works! Off to the repetitious HMI work I live and breathe for! At least all the common svgs can be selected and edited together. Thank you all for the help!!
1 Like
This also works!! Thank you!
@cmallonee @nminchin Thank you guys for all of your help with this. I got sidetracked in some training after making initial contact. Luckily, Patrick was able to get you what you needed. Just wanted to pop back in and say thanks.
2 Likes
We really appreciate the kind words and your massive contribution to the Ignition community Nick!
1 Like
Oof... I have to go manually delete the values of every SVG element with a style binding. That sounds fun
My issue was actually different. Apparently session custom props get deleted when you upgrade versions. Took me way longer than I'd like to admit to figure out why the script was broken
1 Like