Hello,
I am trying to find out why column settings are not persisting. I have a Dataset with a single table which has 40+ columns.
The form has a single grid on it which has its datasource set in designer mode. Most columns have editor controls, heading captions changed, etc. The designer opens correctly in visual studio.
During runtime (no code is running other than initializecompent (designer stuff), the form opens and the grid looks as if i just changed that datasource, all columns are visible and no settings which are visible in the designer are shown.
How does the ultragrid know that the datasource that is set in the initializecomponent is different, why would it act as if its different? Does it store some metadata somewhere?
Thank you,B
I am going to require more information regarding your application.
1. What seems to trigger this issue? 2. Can this issue be reproduced? How? Please provide steps. 3. What does your application consist of besides an UltraWinGrid? Provide screenshots compressed.
In order to properly assist you I require an isolated sample that demonstrates the issue. From there I can take a look at your application and try and reproduce the behavior on my end.
This scenario is to hard to create a example.
I bind the grid to a dataset in the designer and at runtime all my configurations to the grid are wiped out. The grid is acting like it was bound to a completely different datasource when it was not. I know this because there is NO code on this form other than the auto generated designer code.
Basically i want to know how the datasource determines to now used the configured designer code and cause a complete rebind.
You are correct mike, no code and everything is setup on the designer. I am using a complex dataset with 1 table. The designer looks good everytime i open it, during runtime the layout gets wiped out.
This is why i asked how the grid decides to rebind? I wasn't sure if there was something in the dataset or assembly version that would be different. The dataset itself is in a different project in the same solution, which isn't a problem. This particular solution has 300 + grids with each binding to datasets and we haven't had this problem in 6 years.
We are on version - 12.1.20121.2054
I took a video of the designer design UI, runtime UI and generated designer code. http://screencast.com/t/OrRdBCALlm7e
I attached the dataset xsd.
Well, it certainly looks like you are losing your layout at run-time.
Just as a test... what if you put a new grid control on the form and bind it to the same data source. Change something in the designer, like the width of a column. Then run it and see if the column width you set it lost.
If the new grid works, then we know there's a problem with one of the settings or properties on the original grid. If the new grid fails to maintain the design-time settings, then we know the problem is specific to the data source.
In the latter case, my best guess is that your data source is sending a Reset notification after the grid is bound to it. Although I can't see why that would be the case unless there's some sort of operation being performed on the DataSet at regular intervals (on a timer, for example) or on a delay after the first time it's accessed.
I put a new grid on the page and bound it to the same dataset. I then changed the first column header in the designer from SpecimenKey to SpecimenKeyChanged and ran. The original grid layout was reset and the new grid layout wasn't. Very wierd..
I attached the designer code with the grid. Hopefully it will help figure out what is going on.
http://screencast.com/t/lXNo0dbOk
Thanks for all your help...
Hi,
That's interesting. The deserialization code looks okay and it looks basically the same for both grids. So my best guess is that something is accessing the grid at some point after the form has deserialized and is causing the grid to lose it's layout. But that's pretty much what I figured must be happening all along.
Is there any way you can duplicate the problem in a small sample project? If you could do that, we might be able to debug it. Otherwise, it's going to be extremely difficult to track down what's causing this.
I have a few other things you can test:
You could try handling the InitializeLayout event of the grid and examining the columns to see of the column header captions are correctly set when that event fires.
Also, see if the event is firing more than once.
Also, you could try saving the grid layout at design-time by right-clicking on the grid and selecting the Layout Wizard. Then try loading that same layout at run-time, like in the Form_Load event. I'd be interested to see if the layout is, in fact, applied. If it fails to apply, then it might mean that the layout design-time layout is incompatible with the run-time layout. If it does apply, then it confirms that something is blowing away the layout at run-time.
But I expect the results of those tests will be of limited use without the ability to Debug inside the grid code.
InitalizeLayout only fires once. I wrote a loop going through the header captions and they are all different which means layout is reset prior to this event being fired.
I then saved a layout file to disk for all categories.
In the form_load i loaded the layout for all categories and the grid was correctly setup. So loading the layout file worked, which i didn't expect.
Is the InitializeLayout event suppose to fire before the Page_Load event?
Also what is wierd, the initialize layout fires and the layout is not right, page load then fires and i load the layout. After this i expected the initializelayout to fire again, but it didn't.
Hi Brandon,
I can only guess, but my theory is that the grid was getting added to the form (or it's parent control) after the DataSource was already set. So what that means is that the grid had no parent control at the time the DataSoure property was set. Since there is no parent control, there is no BindingContext and the grid would be unable to get the data. Then... when you add the grid to it's parent, it suddenly gets a BindingContext. The grid watches for when the BindingContext changes are re-binds. But since the grid was already bound once with no data, the layout was already lost.
Hello Brandon,
May I ask if you solved the answer to your question? Let us know if you have any additional questions. Thanks in advance.
Mike,
I figured out the problem, but can't tell you why it was happening. In the designer the grid itself wasn't being added to the form traditionally. EX, me.Controls.add(grid)
Instead we had another control that was on the form and the grid was assigned to that control. For whatever reason this caused the layouts to reset. I added the grid using me.controls and during load I assign the grid to our control and everythign worked.
Any ideas why that would reset the layout? You can check out the designer in a previous post.
Thank you,
Brandon
Well, at least you have a workaround for now.
If you want to continue to try to track down why this is happening, then you could try hooking into the data source notifications and see if you are getting a Reset notification form the Data Source. But it will be tricky because the problem has already occurred when Form_Load fires. So that means you need to use the form's constructor to hook the notifications. And getting the same data object the grid is using is not trivial. It would be a lot easier if you could reproduce the issue in a sample project and post it here so I could debug it. But I understand that might not be possible, since I probably can't access your data source.
The form's constructor by default handles all the designer properties, data-binds, and event hooks. Therefore, if you have any logic in the Form Load event at runtime; this won't execute until the designer code, constructor logic has been completed. It depends on when you bind your grid too. In other words the initialize layout event will execute every time you bind your grid before the form load event executes. (Ex. Bind your data in the designer or in the constructor)
Have you solved your issue? Let me know if you have any additional questions.