And give you more detail on the alternative solution I mentioned in first paragraph of Solution 1, how to develop UI techniques not relying upon the knowledge of such control states as visibility,
, label text, and the like.
To get the idea, I would suggest you learn and analyze applicability of the following architectural patterns
MVVM — Model View View Model,
MVC — Model-View-Controller,
MVA — Model-View-Adapter,
MVP — Model-View-Presenter,
Pay attention for the motivation of those architectures. If you understand it, you would be able to create better design ideas. At this moment, I'll try to explain why those and many other reasonable thinkable architectures (which could be much simpler for simple applications) would not require you to know and retrieve those control states from UI itself.
The idea is: this is because you have some more reliable and integral source of data: data model, view model and the like. This model serves as the source of knowledge on how the UI state should be changed, but not the other way around. You only need to "read" the UI state when you retrieve the values
entered by the user: text in text boxed, check states, selection in the lists and grids. You never "read" such things as visibility. Such data acquisition of control states is consistent, concentrated in one logical unit, often "hidden"/encapsulated behind binding, so it is good for maintenance. In contrast to this integral approach, direct manipulation with controls dissipated in code is nearly impossible to support smoothly. You need to understand that you should thoroughly isolate UI from all other aspects of application.
And, by the way, as you mentioned binding you were trying to use: it is not the magic wand. Without proper UI architecture, binding can turn programming into pure shamanism. Unfortunately, these days, it happens to many naive beginners all the time…