I have removed a column from my datasource. But the users have the column saved in their previous old layout preferences files which they saved earlier. As suggested in other posts I have loaded a new UltraGridLayout object with that file. I now want to remove the specific column from that layout by doing
layout.Bands[0].Columns.Remove(column);
But it is returning an error for can't change/remove bound column. The layout object is still not bound or loaded to any grid. How can I remove that specific column from the layout so that when I load it to the grid then it does not return a error?
Hi,
I think you probably have to load the layout into the grid first and then remove the column. At that point, the grid will know that there is no datasource column mapped to the column and it will treat it like an unbound column. I think that will work, although I haven't tried it out. If it doesn't work, please let me know and we will look into it further.
Also I noticed that the grid does not throw any exception for the old xml. Does the grid handle this by itself the different column names or can it throw some exception in some other case.
hi Mike, i've run into a similar problem. i have a displayout that doesn't work with users' existing saved layouts. merging them looks like a mess. i would be fine with them keeping their layouts as they are. let their layouts override my changes (it's up to them if they want to discard their own layouts) i just don't want to break their layouts from loading.
if i were to assert that columns are never removed or changed (name) is there a way to do this? some users have several custom layouts and this would be really rough for all of us. loading the new and old displaylayouts into memory and copying sounds like an idea.
thanks for any info.
AL
Hi Al,
An older layout file should be able to load into the newer version of the grid. The only time the layout will fail is when the grid can't match up the structure in the layout with the structure of the grid. For example, if the band s have changed (name or number) or the columns have changed (name, datatype).
There's no way to get involved in the process of loading a layout. If the grid won't load it, there's no way to make it work. You could load the layout into a Layout variable (instead of directly into the grid) and then try to manually copy everything in that layout into the grid's DisplayLayout, but it's essentially all or nothing.
If your columns and bands have not changed and the layout is not loading correctly, then something may be wrong there. I'd have to see an example of exactly what's happening in order to say more.
understood. my strategy for layouts in my application may be a little far fetched. meaning, i create one default layout by allowing the user to re-arrange columns , formats, groups one time. I put a shortcut key for the user to save that layout as a default (to xml). then i take that file and deploy it with the application. (all categories). unfortunately i think this method is flawed because i make runtime changes to the layout after i call loadfromxml() for certain things. so it becomes more of a base layout than default.
And to make it worse, i allow all users to make changes to their own changes and automatically save the layouts to their personal drives when they close the app(on formclose()).
i've been finding problems with this tiered layout approach. especially when adding new fields to my DTO. BUT FOR THE MOST PART FIELDS ARE NEVER CHANGED OR REMOVED.
not sure where to take it from here. if i change any layouts in this tiered approach, the layouts are affected or unaffected downstream.
Yeah, I'm having some trouble understanding how that tiered approach would work.
I mean, if the end-user has a save layout then loading that should be sufficient and you wouldn't even need any of your base layout or other changes, because they would already be included in the saved layout. That shouldn't cause a problem, but it's also redundant.
The approach I've taken in some applications is to store the layout along with a version number. Basically instead of saving the layout directly to a file, you save it to a stream and you preface the stream with some other data, like a version number.
When the application loads, you load the stream and look at the version number. If it's the same, no problem, go ahead and load the layout. If it's different than the application version, then you know something in the application has changed, and it might be a good idea to revert to the default layout and don't try to load the end-users customizations. This is not ideal, of course, since the end-user loses their changes. But you only bump the version number when know the old layouts aren't go to work, like when you added or removed a column. And they only have to recreate their layouts when they install a new version with a new version number.
This is, in fact, the approach we use with our own AppStylist.
ok thank you Mike.