Thanks for the code. 

As I specified the DataBinding and DataMember at design time and subsequently made changes to the typed dataset I was binding to, I suspected the changes might be stale in the BindingSource. 

So, I set DataBinding to None, rebuilt, then deleted all occurrences of my BindingSource everywhere.  Next I reconnected to the BindingSource and now everything worked.  My suspicion is that the BindingSource does not properly update when I make changes to the typed dataset in V. Studio.  I have gone through this cycle twice to confirm that manually cleaning out the BindingSource and reconnecting is one way of fixing a stale reference after altering a typed dataset.  This strikes me as a specification bug unless there is an easier way. Is there something I should know about refreshing the BindingSource after I alter a typed dataset?  

Furthermore, if I hide all but one column for the first 3 nodes in the Custom Layout Designer snap-in but have two columns in the 4th node, and then run the application, the 4th node only shows one column (the primary key), and not the two columns I specified..  This strikes me as a fault unless I don't understand the rules.  Infragistics4 13.2

The Project Binding Sources are kept under Project Properties/Data Sources.  Though they are referred to as Data Sources, they are auto-named xxxxBindingSource.

Hi Mark, 

I'm having a very hard time following exactly what you are doing here, or even what behavior you want.

There wasn't anything in your original post that indicated that you are setting the tree's DataSource/DataMember and then changing one or both of those to something else. But you seem to be implying that you are doing that, or maybe changing the DataSource/DataMember of the BindingSource. Is that right? 

If you are making changes to the data structure at run-time, either by directly modifying the tables or the DataSet, or by changing the DataMember, then it seems to me that you would also need to modify the ColumnSets in the tree to account for those changes. I am assuming, since you mentioned that you set up the column sets in the designer, that you have set AutoGenerateColumnSets to false and that you are doing everything manually. So maybe it's not the BindingSource that is out of synch here, but rather the ColumnSets. 

I could be wrong. There are a tremendous number of variables here to consider, and as I said, it's really hard to follow what you are trying to do, how you are doing it, and what is wrong here without a sample that we can look at and debug. But you asked for other possible explanations, so the ColumnSets is something to consider. 

Hi Mike (and thank you for the innumerable excellent responses you've given over the years - you make Infragistics and keep me coming back)

I'm new to the UltraTree (I've used UltraGrid to do the same thing years ago). The only code in my application is that which fills the typed dataset below.  All the rest is done in the V.Studio designer (so far).

Using OutlookExpress ViewStyle, I set the DataSource/DataMember in the designer, binding to a V.Studio generated typed dataset (a slice of my database).  Later, I altered the typed dataset in the Visual Studio designer (and the code to retrieve it from the database) after which, I no longer saw the 3rd table in the TreeView when I ran the application.  After I removed all references to the typedDatasetBindingSource (approximate name) in the project, and rebound to the typed dataset in the V.Studio designer, the 3rd table re-appeared when I ran the application.  I've been through this cycle twice to confirm it is reproducible.

Frustrated with this, I turned to setting DataSource/Member in code, which means I have to handle the work done in the Custom Layout Designer snap-in manually; perhaps a good thing. 

I'd still think it might be useful to others to know what is the right approach to refreshing after changing a typed dataset?  I'm not clear why something goes stale like this.

Mark

Hi Mark, 

Now I'm really confused. You mentioned some "code below", but I don't see any code here. 
Also... OutlookExpress Viewstyle dislpays all nodes in the tree in a flat (non-hierarchical) display. So you can't possibly use that style to display 3 different tables. It's designed for recursive data. 

But in any case, if you set AutoGenerateColumnSets to false, that means the true will not automatically generate the ColumnSets based on the DataSource. If it were true (the default) and you change your data source in the designer, I am pretty sure the designer will prompt you to ask if you want to update the ColumnSets that are already generated to match the new data structure. But if you turned it off, it might not show you that prompt on the assumption that since you created the ColumnSets yourself, it's your responsibility to update them as needed. 

It's not clear to me if you did that or not, but there's some hints in your original post that seem to indicate that you created your own ColumnSets rather than letting the tree generate them. 

If you are creating your own ColumnSets then it's important to note that you have to create a Column that represents the child data and mark it as a ChapteredColumn = true. The existence of the chaptered column is what lets the tree know that the child band exists and should be treated as a child band rather than a column. 

I suppose it's also possible that since you are using a BindingSource (I think) that when you changed your DataSet, the DataSet notifies the BindingSource and the tree doesn't get the property notification form the BindingSource so it doesn't know that the data structure changed and maybe that's why you didn't get the prompt. I can't say for sure exactly what notification the tree designer is looking for or whether that notification bubbles up from the DataSet to the BindingSource to the tree. I would think it does, but maybe there's some weirdness there. 

Mark Bean said:

I'd still think it might be useful to others to know what is the right approach to refreshing after changing a typed dataset?  I'm not clear why something goes stale like this.

I think I sort've answered this above, but just to be clear, if you have AutoGenerateColumnSets set to true, the tree should respond to any changes you make in the data source at design-time with a prompt. It asks you if you want to re-generate the column sets, which would lose any changes you made to them manually. 

If AutoGenerateColumnSets is false, then I suspect the tree does nothing and expects you to update the ColumnSets yourself. 

Hi Mike

"code below" was not mentioned in my replies.  I did mention in the first post a reference to "which fills the typed dataset below" (no code, just a description of the dataset).  As mentioned, my app so far has no code whatsoever other than database retrieval to fill the dataset

I believe OutlookExpress Viewstyle sets up a hierarchical view - might you be mistaken?

I let the ultraTree autogenerate the columnsets but when the 3rd table was missing in the run application, I generated them by hand.  That did not make the 3rd table appear.  When I deleted all references to the bindingSource and rebound in the Designer, then the 3rd table appeared.  This is reproducible.  I am willing to let this go, but I do think it might be a flaw.

ultraTree1.ColumnSettings.AutoGenerateColumnSets is set to true by default, so yes, it was thus set (again, I have no code at all modifying the UltraTree).  I did get the prompt but it did not propagate to the application when run.

Is it possible I need a newer version of Infragistics (13.2).  I have expected you to suggest this :-)

Mark

Mark Bean said:

"code below" was not mentioned in my replies.  I did mention in the first post a reference to "which fills the typed dataset below" (no code, just a description of the dataset).  As mentioned, my app so far has no code whatsoever other than database retrieval to fill the dataset

Oh, I misunderstood what you meant.

Mark Bean said:

I believe OutlookExpress Viewstyle sets up a hierarchical view - might you be mistaken?

OutlookExpress does show hierarchical data, but the columns at every level are the same so it looks flat-ish. Your original post made it sound like you were showing 3 separate tables from a dataset. But I guess I am confused about the structure of your data. 

What, exactly, do you mean by "the third table?" Do you mean the grandchild table? 

Parent

     Child

          GrandChild <-- is this the third table? 

So you were seeing the first two levels and not the third? 

I'm still leaning toward my initial assessment, which is that when you made the change(s) to your data source, the ColumnSets didn't get updated for some reason. And so the child data didn't show up in the tree because the Chaptered column was not defined in the ColumnSet. Which may or may not be a bug in the tree designer, depending on what kinds of notifications we get from the BindingSource. 

But without a detailed understanding of exactly what the data structure was to start with and exactly what changed, it's hard to test it and find out for sure. 

Oh, and regarding the version you are using - I suppose it's POSSIBLE that there's some bug in the version you are using that is failing to prompt you or update the column sets. But frankly, I doubt it. We haven't updated the ColumnSets or the tree designer in quite a while. And the prompt I am referring to was added back in 2009. Well before the version you are using. 

Yes, you are understanding me now.  Data structure was 3 hierarchical tables linked by foreign keys/relations. At first, the grandchild table didn't appear in the Custom Layout Designer, but later, it did, but wouldn't appear in the running application.  When I deleted all references to the bindingSource, and went through data binding again, everything worked.  To me, this was evidence that ultraTree does not look for changes to the typed dataset column definitions before it runs or perhaps even during compilation.  I can send you an XML typed dataset and single line of code to play with if you wish.  The typed dataset xml is longer than I'd care to post here. Or we can skip this as taking too much of your time.  You've been very generous.

If you can save your original DataSet structure to XML, zip it up, and attach it here, I could load it into a DataSet in the designer and bind a tree to it. Presumably, you are using a BindingSource, so we could try that, too. 

Then I just need to know exactly what changes to make to the DataSet to make the problem (where the third level disappears) happen. 

I would be happy to try that out if you want. If there is a problem with the notifications, I'd certainly like to find it and get it fixed, if possible. 

But I understand that you have basically worked around the problem, now. So it's really up to you whether you want to continue to pursue it. :)