No way, this was an immediate great thing I noticed when I first started Ignition compared to other packages. Sometimes you have to sandwich things on top of each other with visibility (although I haven't in years), and in Ignition this is completely manageable. In other packages that keep everything visible, it's impossible to mange... I remember in another package having to move the stacked component I wanted to edit to the side so I could actually see it, edit it, then try to get it back to the same spot... worst experience.
The live designer also helps enormously with other parts of developing the GUI as well as it allows you to test while you're developing, rather than having to (compile,) launch the client, and test there.
Layers on the other hand, would be a huge improvement, along with the ability to lock components (looking at you, Perspective).
The Perspective coordinate container grouping experience is very average, so much so that I don't often group things in coord containers; it's just too much hassle. Copying and pasting components into embedded percent coord containers is just horrible since the sizes relate to the coord container you're pasting it into, which are likely wildly different to the one you copied from. I do tend to design using fixed mode though, but having multiple embedded coord containers is a horrible experience as I would want to set these to fixed too, and then you need to remember to set the emdebbed coords and the view coord back to percent once done
Having a what you see is what you get designer is so much better than legacy development environments.
As other have mentioned I have also used an expression to make the items visible in the designer and putting it into "play" mode will make it look just like it would in the vision client. Best of both worlds.
I would hate forced visibility. I usually put an expression binding on my overlays to hide them in the design environment when I'm not in preview mode, so they're never in the way.
I'm not sure about creating bindings for development time; I'd be concerned it would limit scalability. Maybe less of a concern for vision, but for I wouldn't do this for perspective given all sessions are managed by the gateway
I am talking about Vision, so I'm not sure what this means. I simply don't allow an overlay to be visible unless the system flag is greater than one. Otherwise, in Vision, the overlay blocks access to the components in the container.
I prefer knowing where everything is all of the time and I refuse to 'stack' a lot of things in the same spot - because that's the way I've done it for nearly 40 years and I rarely had a problem with that method. I guess it's hard to teach an old dog new tricks.
With that said, things like this make it difficult to look at something that someone else developed. It's not efficient or practical to go through and manually edit the visibility of every object on a form just so you can know what space is available to use for something new or to modify something that already exists. And if I don't see it then I probably won't realize that there is something I need to go look for.
If I were doing Ignition design every day, all day, then I might feel differently. But at my current frequency of using it, these kinds things are a significant stumbling block that have a time cost.
There is an option in the designer to show where invisible objects are, you still have to find them in the tree to edit but you can at least see where things are at or if there are any hidden components on a window.
Also, in the designer you can just shift select all of the components and toggle the visibility to True to see everything if you want. If the visibility is controlled by a binding it won't change what happens in the client.
I also like to just click and drag the mouse from the left to the right, this will highlight and select any component that your box "touches". This, the component highlight when you select it from the project browser with the possibility of multi-selection straight from there (Which, for some insane reason, is something not to take for granted in SCADA software) and the possibility to just CTRL+A to select everything and set it all to visible.
These options makes me wonder why is this even an argument when the solution is just one step away with all of the added flexibility of having a unpolluted designer that actually reflects what you'll see in the client.
Good use of grouping, containers, and especially good naming not only fixes this, but to me, it makes things much clearer. Just reading the component names and icons gives you a good idea of where they're supposed to be and when they should be visible. Sure, a lot of times, you'll find a complete mess left behind by someone else, but that also happens with other software and is arguably worse. I think bad use of software shouldn't be used as an argument against it unless it's obnoxiously difficult to figure out the correct way to use it.
psst, its actually right to left for that selection method, left to right selects only that which completely falls in your selection.
I have some rsview32 projects that ive inherited and not yet converted, and I cant express how much I hate the stacking of objects and groups with visibility and color animations all over the place.
)!