[Bug-13050]After installing latest build, buttons, numeric entry fields etc are overriding styles with blue

After installing the latest build (b2019031702), all of my buttons, numeric entry fields etc are blue, with no apparent way to change this. The styles were previously working, but seem to be overridden, and even explicitly adding a different background colour doesn’t change anything. I have uninstalled and reinstalled, and the results are the same.

(Update: it looks like this was merged today, so look for the fix to be in place in tomorrow morning’s build.)

We’re aware of the “issue” which was a result of our attempt to give all buttons a uniform look by applying a backgroundImage(among others properties) to all of the Buttons (Button, One-Shot Button, Multi-State Button).

We’re actively undoing this, but in the meantime, if you click the “palette” for an individual button’s style property, you can set backgroundImage to “None”, and you should then be able to style the button with colors as before.

1 Like

This issue was fixed in the build that was uploaded today (3/19).
Please let us know if you continue to see this behavior after upgrading.

I have uninstalled and reinstalled the latest build and I am still seeing the issue


Can you show me an example of how you are trying to override the default styles?

If you haven’t already, try following the steps outlined in this post:


Thanks, deleting those files fixed the issue.

1 Like

Correction: partially fixed the issue. My buttons still highlight blue when I hover the mouse over them, or when they’re disabled. On an iPad, this is more noticeable because once you click a button, the “mouse” stays there, so you click a button and it becomes blue until you click another button.

Any chance you could send or post the View with the offending button? Without any additional styling, my Buttons do not behave in this manner.

It’s happening on all of my views, I’ll put a simple one together shortly (most of my views have lots of embedded views, meaning I’d have to send half the project to make it work properly) and upload it. After some initial experimentation, it seems to be restricted to buttons that have my default button style class assigned. And again, only when hovering the mouse over them - they display correctly when the mouse isn’t nearby.

I tried re-deleting those files and re-starting the gateway, and now the web browser is fine, but the iPad still does the same thing.

The iPad probably has the files cached. @mrojas?

It’s just started happening again on the browser. Looks like deleting the style files works for a time but something keeps putting it back to how it was

Troubleshooting this is going to be tricky since there are several pieces in play (View component styles, css theme files, browser caches). Why don’t you post your View here (or send it privately) and I’ll look at it in my environment to see what it looks like. If you could provide screenshots of just the button (not the whole screen) while it is in the following states:

  1. unclicked - unhovered
  2. unclicked - hovered
  3. clicked - hovered
  4. clicked -unhovered

that would be useful.

Screenshots and view attached. I didn’t take a screenshot of #4 as once I unhover, the button goes back to the same state as #1. Except on the iPad, but that’s just because the virtual cursor remains hovered over the button until I click a different one to move it. If I click a different button, it goes back to #1 on the iPad as well. The enabled=false button does not change in any of the four scenarios.

As well as the view, I’ve uploaded the style class that’s assigned to the button.

From top to bottom: clicked, hovered, unhovered.

Clicked Unclicked%20Hovered Unclicked%20Unhovered V1_Bio_2019-03-29_1628.zip (7.2 KB)

Ah, I see what’s going on.

It’s not a bug in the purest sense, as it’s doing exactly what we expect; if you look at the light.css file, you should examine the .button-primary:hover section:

  .button-primary:hover, .button-primary:active {
    cursor: pointer; }
  .button-primary:hover {
    background-color: #47A9E5; 
    box-shadow: 0 2px 4px 0 rgba(34,34,34,0.4); }
  .button-primary:active {
    background-color: #3987B7; 
    box-shadow: inset 0 0 8px 4px rgba(34,34,34,0.4); }
  .button-primary:disabled {
    pointer-events: none;
    background-color: #4188B4; }

SO unless you override the hover property in your Style Class, then the button will continue to switch to #47A9E5, and - as you said - remain that color on iPad until somewhere else is clicked.

Your options are to either directly modify the .css files (which would apply the setting to ALL Perspective projects for all time until you delete/replace/modify the file), or you could do the following within the Perspective Style class:

  1. Double-click the Style i the Designer to open it.
  2. Click the “+” icon to the right of “Base Style”.
  3. Select “Element State”.
  4. In the “Element State” dropdown, select “hover”.
  5. Apply the style settings you would like to apply when a button is hovered over.
1 Like

Thanks, I’ll have a look at this when I’m back in the office. Is this the sort of thing that’s simple to fix and will likely be resolved in an upcoming build? Just trying to prioritise the things I need to put in workarounds for, vs the things that will be fixed before I need them and not need a workaround :slight_smile:

This is the intended color scheme moving forward, and is not a “bug” to be fixed. A decision was made that the grey we were using initially did not fulfill our requirements to have Perspective be the modern solution going forward, in part because mobile applications retained their Java Swing-ish feel. The color scheme you see now was meant to provide that modern feel, especially on mobile devices.


Gotcha, that makes sense. I guess the “problem” in my particular case is that I never defined a hover colour in my style class, but when the default was grey, it was close enough to my specified colour that I didn’t notice. Once it changed to blue, it was much more noticeable.

I’ve just gone through and done this, and it’s worked, but has raised a couple more questions for me.

  1. I wasn’t aware of the different element states (e.g. hovered, disabled) and was previously relying on seperate style classes for normal vs disabled, with an expression binding on the style class to switch styles depending on whether the button was enabled or not. So that’s a useful trick to have learned, and I’ve tidied up a few things that way! I also currently use an expression binding to highlight a button by selecting a separate “highlighted” style class, and am now wondering if I can likewise simplify that. The tag that determines whether the button is highlighted is not necessarily the same as the one the button is writing to, so I’d still need to be able to define a “highlighted” property of sorts. Is there any sort of element state I can use for this? e.g. can I set the highlighted state up in the “active” element state, and then have my button determine an “active” state based on a tag binding?

  2. When I hover, a small box appears around the button over which I’m hovering. This is only noticeable because my buttons have a radius on the corners, and the box that appears is square. On the web browser, it’s not a big drama, but on the iPad it’ll be really noticeable because - as before - the “mouse” remains hovering over whichever button you pressed last, until you press another one. It just looks slightly off. Is there a property I can hide this box with (or give it the same radius as the button, so that it can’t be seen?)

1a: using tags is dangerous, unless you only ever expect one user in the Project. Tags are shared across Perspective Sessions and are persistent (their values don’t change from Session to Session unless you change them), whereas Session properties are unique to a Session and are reset/re-initialized between Sessions.
1b: I’m assuming you mean “focused” when you say “highlighted”, so use the same steps as you did for “hover”, but use “focus” instead. If that’s not what you’re looking for, message me, because I’m a little confused as t what you’re trying to accomplish.

2: Nope, as of right now, that box is there and you have no control over it. We ARE looking into providing customization options for it, but it’s a low priority right now. With the mobile application, there’s nothing you can do about it, but if you’re using a browser try Firefox or Edge - there should be no box at all.

In my case, this is actually the desired behaviour. The main place I’m using this is on my Auto/Off/Manual buttons. I’m not using the inbuilt multistage button, because the PLC code behind it doesn’t support that method. I have several “universal” add-on instructions, which are designed to be as flexible as possible and be able to work with any HMI/SCADA package (or even without one). So when selecting a mode, you don’t write to the actual mode - you write a “set to [mode]” tag to 1, and the PLC resets it once it’s taken the action. Then I want to monitor the actual mode and highlight the respective button to show which mode is selected. I’ve actually taken things a step further with Ignition and implemented a “ModeStatus” memory tag in the Ignition UDT which leverages change scripts and optimistic tag writes, to immediately update the displayed mode rather than waiting the half second or second for the tags to refresh, just so that it looks super responsive. It all works really well, but the only way I’ve found to make the highlighting work is to do an expression binding on that ModeStatus memory tag. No matter which session you open, the device should always display in the same mode, so the tl;dr for your first point is yes, that’s what I need here.

Hopefully the above clears it up a bit. How does the button determine when it’s focused? Can I tell it when it’s focused based on an expression binding? Given my explanation above, is there a straightforward way to use the one style class to do what I’m trying to do, or am I stuck with my current method?

Using firefox, there is still a slight box - or it might be a shadow, it’s hard to tell. It only seems to appear at the bottom corners. It’s the same on the iPad app.