DataGridView.Visible property stays false

[Gerald Christian]

In this mature C# project the DataGridView.Visible property of a certain grid view remains false at all times.

This is true even immediately after attempting to programmatically set the value to "true".

DataGridView.Visible property is set initially "true" in Designer, and nothing in the program sets it to "false"

The non-working grid view was recently added to the project, modeled on a number of working grid views. The grid views all differ mainly in the columns and data sources.

I have also set a VisibleChange event as a test, and it is triggered on the first setting of the property to "true". Again the property value remains "false" both before and after the attempt to set the property "true".

Perhaps some clues are in the following properties captured at runtime, which are different from a those of a working grid view.

CanFocus false
CanSelect false
ContainsFocus false
Created false
Focused false
Visible false

In the working grid view these properties are all "true".

I think most of these are a side effect rather than a cause of the non-working grid view.

The interesting one is the "Created" property.

I have single-stepped the invocation code for the grid view and it all executes with no exceptions.

Any ideas on this are appreciated. In particular I am curious about the "Created" property.

Thanks,
Gerald Christian

p.s.

I have heard the operation of the Visible control can be dependent on the parent object Visible property.
However the parent object is a TabPage, which does not have a .Visible property, at least not one exposed in Designer.
In any case all grid views have a TabPage parent.

 

[jmcilhinney]

The fact that it's on a TabPage is the clue. The TabControl is designed such that the controls on a TabPage don't get created until that TabPage is selected. The controls on the first TabPage will be created as normal with the rest of the form but controls on other TabPages won't be created until you select those pages. This is specifically so that forms with lots of controls in tabs don't lag when loading. Ideally, don't try to access any controls until their tab has been selected. If you need to do so, you can add some code in the Shown event handler to select each TabPage in turn. I've done some tests to try to find an alternative way to force controls to be created but haven't found one. I feel sure that there must be one but haven't had the time to really test thoroughly.

 

[Skydiver]

Moving to WinForms...

 

[Gerald Christian]

j. hi and thanks!

After reading your reply my solution, applied in the code where I invoke the grid view, was to set SelectedIndex of the TabControl to the appropriate tab index.

G.

 

[Skydiver]

And now someone else has discovered the nightmare that is the WinForms TabControl. The WinForms TabControl was a poorly engineered wrapper around the Win95 tab control in the Win32 Common Control. It'll do about 80% of the things right, but there are some holes. The other part of the problem is that the DataGridView was written from the ground up as a modern .NET Framework WinForms control. And so having it "living" inside a native Win32 Common Control whose WinForms wrapper doesn't completely act like a true WinForms control causes issues.

I spent a good 3 months fighting with it back in the .NET Framework 2.0 days trying to customize it to work for our tab based UI -- many of the tabs contained DataGridViews. In my experience, I didn't have issues with visibility, but rather painting and redraws. I found that Spy++ was a very useful tool to try sort things out.