Changing buttons background loses buttons visual effect

I’m trying this in v8.0.9 and is still the same…
When you change the button’s background to anything else than default color (250,250,251), the button loses the visual effect of the button and doesn’t look like the button anymore.

For something basic like the button, I think this is going for too long. Why?

Give the background color some transparency/alpha.

Due to the way the new look and feel works, buttons with vibrant background colors were appearing ‘muted’ upon upgrade, which led to complaints on the forum. So we (essentially) hardcoded thing so that a button set to a different background color with no alpha will render with just that color. As soon as you give the background color some alpha, we’ll go back to using the new look-and-feel’s rendering code, which does preserve the mouseover effects.

OK then. I tried this in v8.0.9:

It really doesn’t work until you give around 50% alpha.
And then the background color is not the color you choose but something… ‘muted’…
There are many situations where you need different background colors on the buttons and this is not a viable solution.
Are you (IA) plan to do something about it or are we stuck with this?

We (not me :slight_smile: ) are looking into whether this can be improved; we’ll check back with this thread once a decision has been made.


I discovered the same issue after migrating from 7.9.13. This is a bug in my opinion that needs to be fixed. PGriffith, you mentioned that development was looking into this. Any idea on when there will be a solution?

Has there been any progress on the 3D button issue on 8.0.x? I just migrated from 7.9.13 to 8.0.9 and the bug still exists. There is no 3d border and no color change on hover. This needs to be fixed.

A temporary solution would be for someone to add a 3D button to the symbol factory that works properly. There are two buttons in the items list but they don’t work the same. Anyway, who maintains the symbol factory items? I haven’t seen anything new in there since I started using ignition.

No, no timeline.

Not us :slight_smile: Symbol Factory is an off-the-shelf product that we essentially just drop directly into Ignition to make available. There are some new things coming to Perspective re: symbology “soon”, but they probably won’t come directly to Vision.

“No. no timeline” isn’t a very good answer. Are the developers working on it?

You upgraded from a long-term-supported version to a not-long-term-supported version. A version with huge architectural changes, and other big changes due to upstream Java clashing with the legacy Swing Look-n-Feel used in v7.9.x. Changes with consequences detailed ad nauseam on this forum. An upgrade you apparently did not test.

Do you think this might not be entirely on IA?

I understand your frustration, but I literally can’t provide a more specific timeline than that. I can’t even guarantee changes will be made at all. I can tell you it’s been assigned to a particular developer for investigation. That doesn’t mean they’re actively working on it, or when they will. Hence, no timeline.

Also, I’d argue that an honest response from a developer within a day is a pretty good answer.

1 Like

You could also make your own button, template. It’s not hard to do and only takes a few minutes. Then you can make it just the way you want. You are the developer and you can yell at yourself.

1 Like

I could do that but why should I have to create a workaround to fix a development tool bug? Fix the root cause has always been my motto.

I tried it again in v8.0.13 RC1 and it’s exactly the same like in v8.0.9… :roll_eyes:

This is a known issue which has been confirmed by IA support and according to them development is “supposedly” going to fix it. I have an open ticket with support regarding this issue to remind them. I think more people should complain about this so maybe it will get fixed :roll_eyes:

Like zxcslo said earlier in this thread the workaround PGriffith suggested doesn’t work either. I tried that too.
However I came up with a better workaround. Try this… (Note: this example is using my button named OverView which has a blue background)
Add a background color change script to the mousePressed and mouseReleased events for the button. For the Pressed choose a darker or lighter color. For the Released put the color back to the original background color. This is the script

event.source.parent.getComponent(‘OverView’).buttonBG = system.gui.color(0,0,128)

Screenshot of the events you need to add.

The cool thing about my workaround is that you can pick a completely different color when you press the button which really pops!

1 Like

Same in v8.0.15 RC1…
It seems that the Button component is not so important … users rarely use it and change the background of the button even less often …

Yes, but as you said earlier…

I really don’t understand, why this ‘issue’ is not resolved yet…
Button is THE essential component in every GUI…

1 Like

Tried today in new 8.0.16 and still the same… :confused: :roll_eyes: :rage:
Changing the buttons’ background loses the buttons’ visual effect.

FYI, each version has release notes that you can browse through to see what is included. No need to install a new version just to see if they fixed a bug.

But, I feel your frustration… I’ve been waiting since January on what I felt were simple fixes.

For this specific case, you could try making your own buttons. On mousePressed:

if event.source.componentEnabled:
	color = event.source.buttonBG
	r = color.getRed()
	g =  color.getGreen()
	b = color.getBlue()
	event.source.buttonBG = system.gui.color(r,g,b,120)

on mouseReleased:

color = event.source.buttonBG
r = color.getRed()
g =  color.getGreen()
b = color.getBlue()
event.source.buttonBG = system.gui.color(r,g,b,255)

You could also do a border instead of color. On mousePressed:

if event.source.componentEnabled:
	import sys

	from javax.swing.border import Border
	from com.inductiveautomation.ignition.common import TypeUtilities

	myBorder = TypeUtilities.coerce('bevel;1', Border)
	event.source.innerBorder = myBorder

on mouseReleased:

event.source.innerBorder = None

Yes, I know all that, but like @r.popeszku said:

And he ended up doing something similar. You really have two choices, wait, or do a workaround on your own.