Sorry the solution is in your documentation ;-)

The visible-property is not supported by TabPageControl, please use the TabControl to set visible property...

The last version don't throw an error, but the new one does. Never mind! I delete the visible set out of the constructor and use the tabcontrols-property like you advice...

Not sure if I'm having the same problem or not.  And, the solution in this thread is not clear to me either.

I''m evaluating the following:

    OriginalFilename: Infragistics2.Win.UltraWinTree.v8.2.dll
    ProductVersion:   8.2.20082.1000

The "Ribbon at Runtime CS" solution.  It runs fine, but when I imitate setting up the ribbon like this solution, I get an Access Violation on the following stack:

OS Thread Id: 0xc58 (0)
ESP       EIP    
0012eb10 03cb16f9 Infragistics.Win.UltraWinTabControl.UltraTabPageControl.set_Visible(Boolean)
0012eb40 03cb1629 Infragistics.Win.UltraWinTabControl.UltraTabControlBase.PerformDelayedInitialize()
0012eb70 03cb1517 Infragistics.Win.UltraWinTabControl.UltraTabControlBase.OnCreateControl()
0012eb8c 7b06d922 System.Windows.Forms.Control.CreateControl(Boolean)
0012ebc8 7b06d8db System.Windows.Forms.Control.CreateControl(Boolean)
0012ec04 7b06d8db System.Windows.Forms.Control.CreateControl(Boolean)
0012ec40 7b06d747 System.Windows.Forms.Control.CreateControl()
0012ec50 7b07b072 System.Windows.Forms.Control.WmShowWindow(System.Windows.Forms.Message ByRef)
0012ec8c 7b07040d System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)
0012ec90 7b079ed5 [InlinedCallFrame: 0012ec90]
0012ed70 7b0706cc System.Windows.Forms.NativeWindow.DefWndProc(System.Windows.Forms.Message ByRef)
0012ed80 7b0e7a75 [InlinedCallFrame: 0012ed80]

UltraTabPageControl.set_Visible assumes there's a value for TabControl (this.TabControl):

public void set_Visible(bool value)
{
    bool flag = false;
    try
    {
        if ((this.TabControl.DelayedInitializePerformed && base.Enabled) && (this.Visible && !value))
        {
            base.Enabled = false;
            flag = true;
        }
        base.Visible = value;
    }
    finally
    {
        if (flag)
        {
            base.Enabled = true;
        }
    }
}

but, this.TabControl is NULL:

Name: Infragistics.Win.UltraWinTabControl.UltraTabPageControl
...

01279e04  400028e       bc ...traTabControlBase  0 instance 00000000 tabControl

there's only a getter on this value:

public UltraTabControlBase TabControl
{
    get
    {
        return this.tabControl;
    }
}
 

Digging into it, I found it basically comes down to the SharedControlsPage property on the ultra tab control.  But,

 (a) I've got to dig and dig to figure out how to *fix* the problem.

(b) the above shows the TabControl property is getting set via internal Infragistics logic, and I can't do anything about it if a getter only (short of overriding the getter via Reflection).

My code does exactly what "Ribbon at Runtime CS" does with one caveat, I'm using visual drag-n-drop as much as I can vs. in-code instantation/initialization of the controls.  ("Ribbon at Runtime CS" should have a *visual* way of creating it, not just in-code...

NOTE: kind of defeats the purpose of WYSIWYG GUI building?)

So,

1. I'm not clear if this is the same problem.

2. What is the solution in this thread really saying?

3. How do I fix this?

The problem turns out to be an UltraTabControl's .Controls and .Tabs collections are mutually dependent upon each other.  And, in addition, there's something to-be-determined about the *initialization order* affecting the internal state of those controls.

Referencing the "Ribbon at Runtime CS" demo: six UltrTab's are added to ultraTabControl1.Tabs (ultraTab1...6).  And, six UltraTabPageControl's are added to ultraTabControl1.Controls (ultraTabPageControl1...6).

Doing the same thing in a mock-up application, if any 1 or the above 12 is omitted, the NullReferenceException is thrown.  For example, I can comment out the Add'ing of ultraTab1, or ultraTabPageControl1) and get the exception.

But, doing the same in the demo, does not produce the exception.

Carefully walking through the steps to construct a ribbon like "Ribbon at Runtime CS", there are some differences, but only the order, they are the same steps.  Looking at the code of the controls, there's dependencies on e.g. .TabControl already being set (then don't set it), etc.

Either way, the .Tabs and .Controls collections should not be dependent upon manual initialization to avoid an exception.   One would expect rapid prototyping of UIs to not throw exceptions, including/excluding tabs/tab pages via commenting them out.

I think the differences might be occurring because in the Ribbon at Runtime sample, the tabs and tab pages are being added between calls to BeginInit and EndInit. The UltraTabControl could be doing null checks in the area where the exceptions are occurring, but only when the tab control is initializing. If you are trying to add tabs outside of the intialization code, it would be better to create the UltraTab and add it to the tab control. Then the TabPage of the UltraTab will automatically be created and added to the Controls collection of the UltraTabControl.