Perspective style override

I’m attempting to create an alarm priority/severity border, which is a view made up of an indicator (see first photo - priority 1-4) and a border.

2

This is what I have so far:

1

I want to flash/animate when the alarm in unacknowledged and be static for acknowledged. So, I thought it would be best to use one style for both indicator and border. The indicator is a fill and the border is a stroke. If I use one style then the border will fill in. Is there a way to override or prevent a style from working on a property? Or is there a better way to do this? I don’t like using separate styles as there is a potential for the animation(s) to be out of sync.

Suggestions?

can you show the styles you made? (formated with </>)

Sure, right now I have separate styles for fill and static…

3

Fill style

{
  "base": {
    "animation": {
      "direction": "normal",
      "timingFunction": "cubic-bezier(0.68, -0.55, 0.265, 1.55)",
      "keyframes": {
        "0%": {
          "fill": "#FF0000"
        },
        "100%": {
          "fill": "#808080"
        }
      }
    }
  }
}

Stroke style

{
  "base": {
    "animation": {
      "direction": "normal",
      "timingFunction": "cubic-bezier(0.68, -0.55, 0.265, 1.55)",
      "keyframes": {
        "0%": {
          "stroke": "#FF0000"
        },
        "100%": {
          "stroke": "#808080"
        }
      }
    }
  }
}

Not relevant to the question you’re directly asking, but this is something we’re planning to add as a first-party feature (eventually):

@PGriffith Can you give me a date on a release?

No. We don’t ‘waterfall’ features into particular releases. We work on things as they come up, and they go into the next release when it’s ready. (Outside of a few major things that have to go into the next major version for compatibility reasons).

Something like this ‘alarm priority container’ could happen in basically any release. As of right now, it’s not going to happen anytime soon (I wouldn’t rely on it coming out within six months) but that’s just a general estimate.

Can you not just manually override the fill attribute within the border object’s view and set it to transparent, or is there something more complex here I am not quite grasping?

image

That doesn’t work, at least for me. The style seems to have priority over the property. Which I would assume is by design.

Strange, my own test on an 8.1.9 gateway seems to allow properties defined in the style object within the view to override the properties from the style class.

What about creating a separate style class that only has its fill property set to whichever value you’d like? That way you could assign your alarm style class and the extra fill style class both to your border object. Depending on which version of Ignition you’re using, you may need to play around with the naming of this style class. I believe older versions of Ignition 8 would load style classes in the order of their paths, alphabetically, rather than in the order in which they are listed in the style.classes property.

My classes are bound, perhaps that is the difference. I will play around with this more. Thanks for the help.

adding !important after a style makes it overrule anything
"fill": "#FF0000 !important"

idk if that is of any use here tho,
the styleclasses dont show me enough, could you also show me where you use them?
an empty view with the component and styles attached would be ideal

1 Like

I know it's been awhile, but I did finally get some more details on why I wasn't able to get an override to work. Attached is a simple example, two styles and one view. The view has two labels, both look at the different styles. One style uses animation. It appears that when using animation in a style, it no longer honors overrides. The label that looks at the style without animation allows the override. Using !important doesn't seem to make a difference.

Two questions, is this considered a bug or normal and if normal are there any workarounds?

I'm on 8.1.25.
OverrideTest.zip (5.4 KB)

I submitted a ticket, 74073. The initial response from IA is as follows:

I did identify why the animation background is overriding the individual style class. This occurs because animation in CSS is it's own class and not a direct style change style. this means that it is running the background color and the animation colors at the same time, and the animation ends up displaying on top. I am currently following up with my team to see if there is anything we can do on our end to get around this.

My question, has anyone found a responsible workaround, other than creating a bunch of separate classes?

IA responded that style overrides are not possible when using animation and that this behavior will not change. I will mark this as a solution.