I'm inheriting a winGrid, binding to BindingSource, using LinqToSQL and EntityFramework. Works GREAT, a boon to production.
In design, I setup my display of bands/columns either the the designer or thru InitializeLayout and all is fine.
If I later update my linq dbml file with new properties (columns in grid) and/or associations (bands in grid), I DON'T want those new columns/tables to change the structure of my grid automatically. So I've set the NewBandLoadStyle and NewColumnLoadStyle to HIDE in my INHERITED control's NEW constructor.
But I really don't want it on NEW, because I'd like to see all of the columns/bands in the designer when I design the grid. And if later, after I've already done my design work on the grid, I alter the dbml file, I don't want those changes to add it's new columns/bands to the grid.
The question is... on what grid event should I set NewBandLoadStyle and NewColumnLoadStye to HIDE? I only want this these two properties to kick in on subsequent design of the grid (after a dbml object was altered), wherein I would manually show the new columns/bands as appropriate.
Hi,
I don't think this is possible. If you change the grid's structure at design-time, then the run-time layout will be changed. So setting NewColumnLoadStyle at some later point would be too late - the columns would already be int he grid and are therefore no longer "new".
What I recommend is that you save the grid's Layout into a file or into the Layouts collection of the grid. You can do this at design-time, using the layout wizard (it's on the menu when you right click on the grid in the designer). Then you can load that layout into he grid at run-time. This way, when you add a column or alter your data structure, the grid will still display correctly at run-time (assuming that the structure matches up enough to load the layout at all).
The other option would be to simply do everything in the InitializeLayout event and that way it will only affect the run-time display of the grid. Personally, this is the way I would do it. It's a bit more work up front, but I think it will save you from some of the quirkiness of the form designer in the long run.
Mike,
I was afraid you'd say that. For years I've only used the InitializeLayout event, hiding all bands & columns, then discretely showing only those I wanted at runtime. (Those years have made me very facile with the object model, but I'm often surprised that there is always something more to learn.) For complex grids (various buttons, bands, grouping, editors, colors, etc) the designer is great for seeing what you are doing, making design MUCH easier.
What I really trying to do is prevent minor changes in the LinqToSQL dbml. like adding a field needed by some other function not relevant to a particular grid. from affecting that grid's runtime layout. My WinForms application is pretty large, and the UltraGrid is used everywhere (over 100 instances in over 50 forms), often looking at the same dbml class. When a customer requests some custom function requiring a new field, it is not a joy to locate all of the grids referencing that modified table/dbml object, and hiding the new field. Setting the NewColumnLoadStyle seemed to work, but because I'm inheriting the UltraGrid into my own class, the timing of when it is invoked becomes the problem. Some of the dbml class associations are nested very deeply, and I have to be carefull to set MaxBandDepth (I have some classes that can create over 100 bands!). Also, the performance hit of saving/loading layout XML from file or db, particularly for deep band structures, doesn't make it a viable solution.
Thanks for reviewing this. You, and Infragistics, are providing a truely valuable support resource. I usually find everything I need in the knowledge base and forums. This is the first time in over 10 years using Infragistics products that I needed to post a question... a GREAT feather in your cap.