Object visibility in Vision Designer

As someone that comes from working with things like Visual Studio, FactoryTalk View, Panel Builder, and a host of other applications that deal with creating HMI's, one of the things I've found to be a stumbling block for me while working with the Ignition Designer is with how it handles object visibility.

In all of the other applications that I'm used to working with, I can always see an object in the designer, which means I can always see where it is located, how it is layered, how it is formatted, what the text says, etc. And if I want to see what happens when the visibility conditions are active, I can put it into a test mode (similar to Ignition's Preview Mode) and observe that.

This doesn't seem to be the case with the Ignition designer. If the live visibility conditions go false then the object doesn't show up in the designer, so it's very easy to miss that it is there in the first place. I've accidently messed up, or accidentally deleted objects that I didn't know were there many more times than I can count. It's a constant frustration.

So yes, maybe that's my fault for not understanding how Designer works. But this seems more difficult than it should be for someone who is used to working in these other popular environments.

I've looked at the 'Spot Light' feature and that doesn't really give me what I need - an outline just isn't enough. And the meta visibility feature really isn't very intuitive - I think I'm going to mess that up too frequently to really be able to depend on it, and I fear that someone else coming in the project after me wouldn't know to look for it.

So, is there something else that I'm missing?

If not, may I request that a view option be added that makes these objects plainly visible in the designer? That would make the transition from these other popular development systems a lot easier.

Thanks!

1 Like

A couple of thoughts;

Firstly, even if it is not visible, it will be in the root container of the Window.

Secondly, there is designer scope, perhaps you could write a script so that if you are in designer scope, its visibility is always true.

2 Likes

Could also do something in an expression like {someOtherCondition} || hasRole('Designer') if your roles are well defined.

Additionally would also let you log into the vision client run time as the designer user and see everything which may or may not be helpful in certain troubleshooting situations..

Don't hold your breath. Visibility is a bindable property, so applies to both design-view and preview. And it is a native java Swing component property, not something added by Ignition, so not really practical to change.

FWIW, I despise the everything-visible design environments--too cluttered for my taste, particularly when designing with overlapping areas (like with a tab control).

Get used to Ignition and you won't ever want to go back.

3 Likes

That happened to me 10 years ago...

1 Like

Personally i wouldn't change a thing about how visibility works, i absolutely hate the cluttered design where it's basically everything everywhere all at once, i usually separate window's elements in groups and containers and work with their visibility so i can focus on just what i want to modify/create at the moment and easily be able to hide it so i can focus on another part.
Maybe it's a personal taste thing and you'll always miss the way others do or maybe what you're missing is getting used to using more groups and rely more on the project browser to find what you need and embrace the way things currently are.
When i need to check if there's something hidden, other than pressing CTRL+A and switching the visible property to True on everything, i also select the components by left clicking then dragging the mouse to the left.
java_7TwvuiT2uI

These aren't "fixes" to what you want but are things that i use frequently that help me in that regard..

The hardest part of working with ignition is when you have to work with another SCADA afterwards.

3 Likes

Thanks everyone for taking the time to reply!

While I did see the other thread that related to this topic, it seemed dated - so I was hoping that there had been some progress on this front.

I have to confess to being disappointed. This seems like a strange thing to run into in such an advanced package.

As far as not wanting to go back after trying Ignition, I'm not there yet. But I've only been at this for about seven months compared to the years that I've put towards other packages. It might still happen.

Hmmm. I consider this to BE the proper behavior for an advanced package. Your expectations of "proper" may have been twisted beyond all recognition by over-exposure to lesser tools. :man_shrugging:

1 Like

I think making something invisible and then not being able to see it in the designer itself it's a common practice in a lot of design software.
And checking your elements in the layers is a good habit.

You can get the functionality you want by adding conditions for in designer and not testing to your visibility expression in addition to your usual visibility expressions:

3 Likes

In more than one other popular platform I've struggled and fought with this. I've had more than 10-20 displays all stacked on top of each other, and the only way to see and edit them is to move them. What a joke!

5 Likes

That's a little different from what I was expecting - but that's probably why I had to come here for an answer in the first place. It does the trick. Thanks!

2 Likes

You can also use the Enabled property instead of the Visible, that way the object will still be visible but grayed out and not accessible to interact with.

We use this expression in the visible property after the true (the last comma) you can add anything else you want to make it visible.

if( {[System]Client/System/SystemFlags} = 1, 1,

1 Like

fwiw, it's simpler just to use conditions without an if, like:

{[System]Client/System/SystemFlags} = 1 // In Designer
||
(
   {tag} = 'Manual'
   ...
(
1 Like

Just a word of caution, this will break if you have SSL enabled since the integer value would be 65 instead of 1 when running in the designer. This is because the SystemFlags tag is an integer representing a bit field. Instead, you should use bitwise operations to check that the Designer flag bit is set. Otherwise you're going to be scratching your head why it suddenly "stopped working" when you enable SSL or IA decides to add additional bits to the System Flags.

Something like:

getBit({[System]Client/System/SystemFlags}, 0)
4 Likes

Yes, @WillMT10 's version checks the bit appropriately like the code I linked above. Note all of the versions between my last post and this post will make everything visible in Designer even when in preview mode. This is generally not desirable. The version posted above only overrides visibility to on when in Designer and not in preview mode.

Just as a follow-up to this, I had a support ticket open for "missing buttons" on upgrade from 7.9.12 to 8.1.25

Call Notes:
• Customer had a Vision Window that would show all buttons in the Designer but hide some of those buttons when launched in a client
• The buttons that were being hidden all had component security applied to them
• They were being hidden but had an exempt role applied to them, but the customer was logged in as admin on both the client and Designer
• This is expected in order to allow users to see all buttons on a Window in the Designer, tested it on my end with a super simple button on 7.9.12, 7.9.21, and 8.1.25

So perhaps another strategy is to use security permissions, one for designer to "see all" but won't be present in client

I never touch the visibility binding in Ignition; I will only use the enabled binding if necessary.

It leads to very bad practices with new people. They will try to cram 8 screens worth of content onto a single screen and use visibility to show the various tools. You are also going to forget where you put the invisible component one day and have to debug it. Yes, you have the spot light tool but I find I can do everything without it and make future me very happy.

Just because you can doesn't mean you should.

1 Like