I have a user who has somehow docked one pane into another pane. We have a "Report" pane which shows reports and an "Information" pane which shows meta data. She has somehow docked the information pane inside the report pane (it looks funky). Now she can not not use either one. We have Save Settings on in our application so the dock panes have persisted themselves wrong. When you tried to click one of our custom 'views' which hides and shows various layouts it results in an error. Hiding or showing either pane manually also causes fetal errors to occur in the Infragistics libraries and the application shuts down.
I tried looking in the {Assembly}.eve.config file to remove the <base64Binary> data (which is where I thought these controls were being persisted), but those values are all blank. How can I reset her persisted values? This is an enterprise application so incrementing the version and republishing is not possible.
Thanks in advance.
Also, I thought they were being persisted in the app.config files, but they are not. I have no idea where they are being persisted.
I don't know where the persisted values are saved to remove them. I persist all kinds of infragistics tools and they OFTEN get out of sync. I have not found a good way to fix this.
I hope someone who has come accross this before happens to run accross this.
Is it possible the persisted state is being saved in isolated storage? If so, you should be able to purge the item so the dock manager will fail to find it and therefore recreate its default state.
Another approach is to fix the docking structure dynamically. At some convenient point in your app, such as on AfterDockChange or AfterToggleDockState, you can validate the docking structure and fix up any anomalies. This is quick and easy if your allowed arrangements are simple.
An even better approach would be to configure the dock manager to prevent any unwanted docking structures from forming. Do you really need to user to be able to drag windows to different dock locations?
Anyone have any ideas? Surly this isn't the first time there has been a need to reset a persisted control without incrementing the version and redeploying the enterprise.