-
Notifications
You must be signed in to change notification settings - Fork 324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NullReferenceException while restoring layout with not existing document #38
Comments
Hi, thanks for you detailled application but I am not sure about the problem you want to raise or whether this realy is an issue in AvalonDock. I have tried this workflow in my Edi application: Test Work Flow
and it worked without an exception. Normally, AvalonDock should not be able to differenciate between a document that exists or does not exist. It should be the viewmodel that ensures that non-existing documents are handled as such (non-existing documents should be closed in reload layout). I am using the args.Cancel = true mechanism you describe but maybe I am not using the right workflow to trigger the problem? Can you either give me a test workflow based on Edi or even better a test application (attach a zip file) and a test workflow to better understand what you are looking at? Thanks Dirk |
@Dirkster99 i will try to provide it ASAP |
@Dirkster99 so im not able to reproduce it on testapp/EDI yet, but i saw that you call layout deserialization in EDI in dispatcher with DispatcherPriority.Background and now it seems its okay (example below). I will test it more and let you know if i figure something else Thanks for your time
|
Hi, since a few people seem to run into trouble loading the Layout I am trying to come up with a solution that loads the layout async but ensures proper funtioning. So, I've created a branch with a drafted solution. Would you be able to test this solution (with you problem about the CallBack reported above)? https://github.com/Dirkster99/AvalonDock/tree/LoadLayoutAsync This solution loads the layout in a background task and loads the resulting string with What do you think about this? Does it work for you? |
@Dirkster99 thanks for attempt, but on first look its not working for me. But im trying to provide you some enviroment when you can see this issue on your own. But when i added fix #47 it seems fixed to me |
Hm, thats interesting. I wonder if there really is a condition where CloseInternal() can be called on a LayoutContent without a Root.Manager being available? I mean, if 2 people report the same solution on a similar case it does strongly suggest that the solution is useful. I just do not understand it, yet... So, just to be clear - you already stated that using It would be really helpful if I could look at a test sample to understand the problem? Is it possible to create a sample application to see if I can verify the same problem using my PC? |
Hi, I found a major bug in the implementation of the branch. To understand the bug you must understand that the application saves and reloads its layout in the bin folder at application start-up/end (eg. bin\Debug\AvalonDock.Layout.config). The bug was that the AvalonDockContainer is invisible at start-up because I noticed that it loads a lot faster without all the redraws being rendered visibly. But the application has mad the Avalondock container visible only if it actally loaded a layout from file. So, in the default case, where you download the branch, build it for the first time, and start the app, you do not get any visible docking manager content :-( ... but for me, it was difficult to understand this from a feedback like 'on first look its not working for me' because my folder still had the layout file (even after Clean Solution) - so, I only ran into this condition when I changed branches... So, to make this more deterministic, could you please download the branch one more time and follow the test steps below to see wether this works for you or not? If, not please tell me where you fail and show some evidence like stacktrace and so forth (I'll be happy to explain the solution next) Download Branch LoadLayoutAsync
|
I've also tested the test branch without the additional UI thread synchronization. Just comment out these 2 lines: Application.Current.Dispatcher.Invoke(() => { What about you? Does this work for you? The surprissing find I now have is that AvalonDock does not seem to require UI thread synchronization for deserialization even if the document loading has to be canceled with the |
Version 3.5.10 and later will include the suggested solution |
Hi, im using your fork of AD with restore layout as described in this article
While restoring layout, there is possibility that XML layout will contains reference to document which isnt open (while restoring) and in previous version AD ignored it and opened rest of layout.
But in 3.5.6 version it throws NullReferenceException (shown below).
In LayoutContent.cs when it comes to restore not existing document Root.Manager is null (as shown on screenshot)
Is there a possibility how to skip restoring documents which are not opened? For restoring layout im using code you wrote on codeproject.com (link in top of issue). Full code example described bellow. I thought, that when i set e.Cancel to true in LayoutSerializationCallback, then layout restoring for this document will be canceled. Or am i missing something?
The text was updated successfully, but these errors were encountered: