Hiding and showing anchorable in document's pane throws an exception #71
Comments
Rasenshurikenbum
changed the title
Rasenshurikenbum
changed the title
|
Hi, would you please attach the updated version that works with 3.5.12 to verify your problem using your test client? Thank you. |
|
If you meant to upload my test project then there it is. |
|
hmmm, this is strange. I cannot verify your prolem although your workflow description is detailled and easy to follow. Is it possible that you used an older than 3.5.12 version and did not update correctly to the recent version (because there was a recent fix in 3.5.11 about this)? |
|
I tried both overwriting old version and installing a fresh one. Every time I get the same results. I also found out that the first exception occurs in all versions from 3.5.4 up. In version 3.5.3 no exception is thrown but instead it doesn't let the closed window to be shown again (choosing the proper view from menu does nothing). |
I have tested the application that you attached and it works for me without any exception being thrown. Its really strange - not sure how to fix a problem I cannot verify on my computer :-( Would you please give me the full Statcktrace of the exception that you see? It should normally look like the Stacktrace in this Issue. Thanx |
|
Here's the stack trace:
And here is the second exception's stack trace:
|
|
OK, I tried it again and I am able to also get the exception. It is important to close the tool window with X because I previously made the mistake of closing it via Tools>... menu entry and it did work in this instace. Now I can look for a fix ... thank you for you patience |
|
Awesome, hope it's not something difficult to fix. |
|
hmmm, I've been looking at this for a while but cannot seem to determine why the exception occurs only if I close the document with 'X' and I also noticed that it only occurs for the first tool window that is dragged into the document pane (?) but the workflow actually works for the 2nd tool window: 1 Using the attached sample project (with LayoutInitializer disabled for testing for above URL): Repeat steps 1-4 I also noticed that the PreviousContainerIndex can be -1 in the InsertAt statement so the code below could be a minor improvement in LayoutAnchorable.show() at about line 447 (but its not fixing the problem reported here): var previousContainerAsLayoutGroup = PreviousContainer as ILayoutGroup;
if (PreviousContainerIndex < previousContainerAsLayoutGroup.ChildrenCount)
previousContainerAsLayoutGroup.InsertChildAt((PreviousContainerIndex < 0 ? 0 : PreviousContainerIndex), this);
else
previousContainerAsLayoutGroup.InsertChildAt(previousContainerAsLayoutGroup.ChildrenCount, this);Whats really bothering me (because I cannot explain it) is why the same code works on one of the tool windows but not for the other even though conditions seem to be the same in both instances (inserting a LayoutAnchorable into a ILayoutGroup) but one of them ends in an exception(!)... @scdmitryvodich Do you see what I am missing? Why is this exception one of the tool windows and not on both? |
|
@Dirkster99 i noticed this exception too, and trying to figure out some workaround. But im curious why "close" button on LayoutAnchorable works like close instead of hide. Afaik Anchorables in anchorablePanel has "hide" button, so is there some reason that Anchorable will close? If no, then i think that replacing Close behavior for Hide behavior for LayoutAnchorables in docoment panel should work. Also i noticed that closing and reopening of layout anchorable loses layout position. But hiding and unhiding preserves locations. So its another plus for me. |
|
@Dirkster99 @Rasenshurikenbum And its worked for me. But i dont know if there are other side effects Also as @Dirkster99 asked did you noticed that when closing recentFiles previous container is set to LayoutDocumentPanel but when closing FileStats, previous container is set to LayoutDocumentPanel too, but right after is set to LayoutPanel? This seems strange to me and possible source of this exception. Because when you try to restore layout after, there is wrong LayoutGroup with T type LayoutPanel which cant cast LayoutAnchorable |
|
Hi Muhahe, I've updated the test client to current sources and can still see the Exceptions previously described :-( Version_03_Edi_RecentFilesTW_AD40_20200304.zip Replacing the Close with Hide command is a good hint but seems to be a strange solution (because this works for many other workflows). Maybe there is a better fix such as calling Hide instead of Close under a certain condition? At this point I am not sure but will try to look into this but am not sure if I can find a better fix either... |
|
Hi All, Here is my point of view on this. I think that hiding when close is requested is a bad idea, this breaks the intention. There are already AutoHide, CanClose properties to influence the behavior. If you don't want the anchorable to be closed, set CanClose to false. By using these settings the error is probably bypassed. The actual error occurs somewhere else. When closing, the CloseInternal function of LayoutContent gets called. It remembers the parent as previouscontainer for reinstation later. on line 706 it checks that if it was the last one in the parent, it moves itself up in the layout tree by setting previouscontainer to it's grandparent (a LayoutPanel), by assumption that the parent will be garbage collected. This will not happen because in the garbage collection routine (LayoutRoot.CollectGarbage) there is an exception for the LayoutDocumentPane of the main view (line 379). The grandparent (LayoutPane) does not accept an LayoutAnchorable or LayoutDocument, because the do not implement ILayoutPanelElement. So in my opinion the code in LayoutContent.CloseInternal should be adapted to keep the parent if it is the 'main' documentpane. I'm not sure this will cover all the situations with floating windows correctly. I hope someone can do the actual changes and various tests. |
|
@mkonijnenburg Your analysis is right :-) as usual :-) I created a branch to make the current solution available for testing and review: I created a new
to make this dependency more obvious and ensure consistency in the result. The only thing remaining to close this issue is the broken binding which is visible when I close the Anchorable in the DocumentPane with the (X) button and look at the Menu Entry which shows the Anchorable still being checked :-( |
|
I found a fix in LayoutAnchorable.cs in this commit which is essentally setting the IsVisible property to false when closing the LayoutAnchorable. When testing, I am finding another related issue which is that the LayoutAnchorable in the DocumentPane reloads without showing the Close (X) button probably because the wrong control is applied in this case(?) The Close and Close All, Close But this in the Menu Context (which otherwise work) are also not working for the Layout reload case.
TBD PS' |
|
|
|
I have tested this fix (as it is already commited in master) but it does not solve the problem reference in this workflow. I am not sure how this change could be related to the exceptions that are visible when the above workflow is executed? |
|
Hi @Dirkster99 |
|
Yes this is a confusing issue ticket. The resolution is probably very difficult and involved (which is why I was not able to resolve it yet). From what I saw it looks like:
There also seems to be an inconsistency between
|
|
Yes, I was confused when dealing with the problem of #71 |
|
|
|
Hi @Rasenshurikenbum, |
|
Hi @Dirkster99 |
|
I guess the change in #181 does not hurt but it does not fix the problem in this issue :-( @LyonJack |
Steps to reproduce:
System.InvalidCastException: 'Unable to cast object of type 'Xceed.Wpf.AvalonDock.Layout.LayoutAnchorable' to type 'Xceed.Wpf.AvalonDock.Layout.ILayoutPanelElement'.'Other exception:
System.ArgumentOutOfRangeException: 'Index must be within the bounds of the List. Parameter name: index'The text was updated successfully, but these errors were encountered: