[quote user="[Infragistics] Mike Saltzman"]The problem is, what happens if you specify that the grid should use the existing layout and the layout doesn't actually match exactly[/quote]
If the layout at run time isn't matching what I designed against I've got bigger problems than the grid raising an error, I've got a delta between my user interface and my business objects interfaces.  This will likely create unpredictable results across various portions of the application. 

[quote user="[Infragistics] Mike Saltzman"]I think you might not be using the right terminology here. It sounds to me like you have 5 bands, not 14[/quote]
The bands are listed in the designer as an array.  The last band listed in the designer is Band[140].  Unless I am missing something, that means there are 140 bands.

[quote user="[Infragistics] Mike Saltzman"]

How long is the delay, exactly?

[/quote]
The delay is about 15 – 30 seconds.

[quote user="[Infragistics] Mike Saltzman"]

What kind of data source are you using for the grid?

[/quote]
I am using a business entity object generated with .Net tiers.

I'm not sure how you would use the UltraDataSource as an intermediary.  What I ended up doing was basically abandoning the designer (it seemed to have lots of problems after the second level anyway) and wrote code to create the five levels of bands myself in the control constructor.  This resolved the delay.  Apparently creating all the bands I wasn't using was what was causing the delay.

[quote user="[Infragistics] Mike Saltzman"]When you assign the DataSource to the grid, it doesn't neccessarily know that it's the same one you assigned at Design-time. In fact, it's not the same instance, so it has to get the structure again.[/quote]
Then why bother looping through the data source and adding code for the structure if its just going to be ignored at run time?  Also, since I do know that the structure will be the same, shouldn't it be possible to turn this functionality off and tell the grid to assume the structure matches?

[quote user="[Infragistics] Mike Saltzman"]But I have never seen this cause any significant performance issue when MaxBandDepth is set to a reasonable number, and 5 is certainly reasonable. [/quote]
Again, this represents a project plan task list.  The tasks has a collection of parent tasks, predecessor tasks, and user resources assigned (which each have their collection of tasks).  The grid steps through each one up to five levels deep creating more than 140 bands.  Only the task collections would be populated and viewed through the grid, the rest are set to not be visible (although they would be populated and used elsewhere).

[quote user="[Infragistics] Mike Saltzman"]It's hard to guess without knowing more about your application. But I can tell you that the grid will not load child rows by default, so only the root-level rows of the grid should be created initially[/quote] 
The delay is happening without any data loaded in the collection.  When debugging, the code appears to be pulling property names and metadata.  I have to get past this performance bottleneck before I can even start working with the actual data.

 

I have a similar issue in that the grid appears to loop through all the columns and bands at design time.  I have a grid that represents the tasks in a project plan.  The max band depth is set to 5 to prevent the grid from looping through 100X itterations through the recursive table.

The grid is painfully slow to work with at design time, but I am okay with that since it has added code to create all the fields and band objects.  But since this code is already there, and the behavior for both new bands and new columns is set to hide, why does it loop through again at run time?  This causes an unacceptable delay when loading the grid even with an empty task collection.

I'm hoping for my sake that there is a way to turn off this behavior or I'm going to have to redo this using something else.

I'm using Infragistics 2009 volume 1 which I believe is the latest, although the original install on this workstation was 2008 v1 so the preset location could be based on that version.

You can put your presets into any folder you wish, but when you create the preset you have to be running as administrator or the designer crashes.  I'm using Vista SP1 and Visual Studio 2008 sp1.

That was exactly what I was looking for.  It would be nice if the presets weren't in the program files directory so that I didn't have to launch as administrator in Vista to edit them (it crashes the designer if VS isn't launched as admin), but once set it does exactly what I needed.

Thanks!

[quote user="[Infragistics] Mike Saltzman"]set MaxBandDepth to a more reasonable number. Very few users will find it useful to drill down into the data 100 levels deep[/quote]

I agree this is an unreasonable number.  In fact, I have had more lockups in Visual Studio from this setting than anything else.  Its okay if you catch it, but if you modify your business entities after the fact you may find yourself unable to open your form in the designer.

Since this is such an unreasonable number, is there any way the default can be changed to 5 in a future release?