Yes - just not expected by me.  I lean against setting the appearance in code, as it often creates unexpected behavior.  If you attempt to trace the generated code, the chosen naming convention is not intuitive and setting object properties can become misleading.  Also, developers may use the designer only to find later that their settings are ignored, or duplicated. Depending on timing, adverse affects may occur.  Certainly, I do configure at runtime, but I try to use the designer first - which funny enough, is the exact opposite of my web experience.

As alternative, I refactored my user controls as follows.  I added a base user control with a grid property, to which I wired all of my grid events and actions.  In the derived user controls, I actually draw the grid and its respective ultradatasource.  During initialization, I wire the derived class's grid to the base control.  This allows me to implement multiple data source shapes, using common funcitonality from the base.  The trick of course is that all of the common functionality must consider that bands, columns, etc may or may not exist at runtime.  But, with a flexible base, I was able to share the base code with minimal changes.  I spent much, much more time trying to make a single data source work than I did in this refactor. 

Thanks for all of your help.

Ah, I see what you mean now.

This behavior is expected.  When you bind the grid to a new data source, it compares the existing bands and columns to the bands and columns that it would need to create.  Any existing bands and columns that wouldn't exist under the new data source are discarded, along with their appearances.  Bands and columns that didn't previously exist are created, with default appearances.  Any bands and columns that are held in common by both data sources remain, and thus retain their appearances.

Because of this, when you bind the grid to a null data source, all the existing bands and columns are discarded.

The easiest way to deal with this is to style your grid in code, ideally in the InitializeLayout event.  If you're comfortable with navigating the Windows Forms Designer Generated Code section, you can likely copy some of this code and put it (with some modifications) into your InitializeLayout event handler to duplicate your styling.  You'll need to use conditional statements to ensure that the bands and columns you want to style actually exist before you try to set their properties.

When I set the datamember, the grid loses all of its appearance settings.  For instance, the row shading, and the column header visiblity all resets as if it were not set in the designer.  If I create a container shape, using the exact same data structure, I am able to easily switch the datamember between null and the child collection.  With null, the grid looks correct.  When set to a child collection, all appearance sets to default settings.

GridPlan.SetDataBinding(null, null)  This also resets the appearance.

I'm not sure what you mean.  The parent band and child band should each have their own set of columns.

That's interesting.  It works for the most part.  However, it appears to bind the child collection to the parent band's column collection, so only matching columns display.  Am I missing something here?  If this is the case, then it is no different than having set the datasource equal to the child collection of the record that I desire.  This is not 100% what I want, but I can make it work.