# [.net] Control.Visible (but not parent)

This topic is 4859 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I have come across the most frustrating problem using the C# Control class. I cannot determine if the control in question is locally visible. The default implementation for Control.Visible has it returning false if one of it's ancestors is not visible. That's fine, but I need to check it's local state for a problem I am solving. Specifically, I would like to use reflection to call GetVisibleCore, GetState, or check the field state, but these are all private or internal methods/fields in the Windows .dll. I thought reflection could bypass this, but I guess there are attributes you can set (which Microsoft has?) to disallow this. So, I am looking for an easy way to check the local state. I have already tried detaching the control from it's parent, checking Visible, and reattching it, but the docking was a little bit off afterwards. I could record ALL the docking information, etc, but this could be become a maintenance nightmare in the long run, so I'd like to avoid it. Any miraculous ideas?

##### Share on other sites
Unfortunately, your only surefire way to handle this that I know of is to recursively check if the parent control is visible until the parent is a form or some other limiting aspect that you search for.

Forgive me if the code doesn't work...I'm typing it here while I wait for a build to finish.
' VB.NET, conversion to C# is left as an exercise to the reader...Function IsReallyVisible(ctl As Control) As Boolean  If Not ctl.Visible Then Return False  If TypeOf ctl Is Form Then Return True  Return IsReallyVisible(ctl.Parent)End Function

EDIT: Erp. Ignore me. I missed your quagmire in my quick readthrough. I'll think about it for a bit and see if I can figure it out...

EDIT #2: You almost had the correct answer when you were removing the control from the parent, checking Visible, and then reattaching it. From my (admittedly quick) experimentation, you need to call .SuspendLayout on the parent prior to the control's removal, then call .ResumeLayout on the parent after the reinsertion.

If you still have problems, call .ResumeLayout(False). That should stop the container from laying out the controls again.

##### Share on other sites
Thanks for looking at it - I indeed was calling SuspendLayout and ResumeLayout(false), but somehow the control was being repositioned wrong. I admit this shouldn't happen, but somehow the default docking behavior or a side effect in my own code created a problem when I detached/reattached the control. Coupled with the fact that this will trigger potentially unwanted ControlAdded and ControlRemoved events, I was hoping there was a purer way of getting what I was looking for.

I don't know if Microsoft is updating their controls in .NET 2.0, but they should definitely add a simple accessor to get local visibility.

##### Share on other sites
Well the biggest problem is that when it does re-layout the controls, it lays them out in the order that they are in the collection.

Prior to removal, you might want to try figuring out what index in the collection the control is and try reinserting the control in the same location.

##### Share on other sites
Right again :) Unfortunately, I did this as well - saving the index pre-removal, and then setting it post-addition. Same bad side effects. In lieu of a good solution, I'm gonna have to track down the exact cause of the bad layout, but I really don't want to do it this way!

1. 1
2. 2
frob
12
3. 3
4. 4
5. 5
Rutin
10

• 13
• 14
• 65
• 14
• 15
• ### Forum Statistics

• Total Topics
632130
• Total Posts
3004283

×