2nd Monitor restore LayoutAnchorablePaneGroup about avalondock

[mbullock976]

Correction

It seems when I have more than 3 layout floating anchorables grouped together on the 2nd monitor, I then cannot restore back to the 2nd monitor. I've attached example which contains 4 floating anchorable windows (not working) and an example of 3 floating layout anchorables grouped on 2nd monitor (working example)

not working 4 floating windows grouped 2nd monitor.txt

working example 3 floating windows grouped 2nd monitor.txt

I'm running 2 monitors both as 1920 x 1080

[mbullock976]

Hi,

I've done some further investigation and it looks like if I have more than one LayoutAnchorablePaneGroup within a LayoutAnchorableFloatingWindow, then it won't deserialize the floating window on the 2nd monitor.

I believe depending on how you dock a Layoutanchorable within an existing floating window, it will create a nested paneGroup if the orientation of the dock has changed.

In the example below, (which seems to work), I've created 2 floating windows resized to take up the size of the 2nd monitor. Each floating window has one paneGroup and the orientation are the same.

Working example with one anchorable group per floating winow 2nd monitor.txt

So this could be my workaround for now

[Dirkster99]

Hi Thanks for your input,

I was looking at your issue and found another crash #28 that appears only if you save/load the layout and then hide the floating window.

The problem for hidding the floating tool window does not appear if you start with a fresh copy (remove the layout file in the bin folder and do not save/load the layout).

While I found a fix for it I am not too sure whether this introduces new problems or whether this is a good fix :-( but I'll be thinking about it.

Could you please, in the meantime, verify that you can re-preduce the problem in #28 and whether the fix in the branch works for you or not?

For the issue in this report - please do use a test application out of the demo apps in this repository. I extended MLib_Test to include 5 tool windows now. I think this should be plenty for this issue, right?
And I am able to reload the maximized floating window with 5 tool windows in it:

(Right side is my second screen with different resolution)

For the issue here I am going to need a step by step list of actions and possibly screenshots to reproduce the issue you are trying to tell me about. For a test report, it would be best if you:

1. Exit VS
2. use the CleanAll.bat
3. Start VS - Rebuild from scratch
4. Start MLib_Test to reproduce an issue (Layout is saved in Bin folder when you exit MLib_Test and re-loaded when you re-start)

I have also seen that the FloatingWindow impementation is not very stable and its difficult to describe the bug in a deterministic way but I have put together 5 windows on the 2nd screen and was able to end up in a situation where this was successfully reloaded (don't ask me how often I tried). So, it looks like we have to do certain specific workflow to reproduce the issue.

Would you be able to tell me how to re-produce the issue in a deterministic way please?

[mbullock976]

Hi @Dirkster99

Thanks for looking into this.

I've followed the steps you specified above using the FloatingGroup branch and the MLib_Test app.

I've been able to recreate the issue consistently using the following steps:

1). Do steps 1 - 3 of your previous message
2). Run the MLib_Test App
3). I maximise the screen on my 1st monitor (main)
4). I right-click on Tool 1 and select float from context menu
5). I right-click on Tool 2 and select float from context menu
6). I right-click on Tool 3 and select float from context menu
7). I right-click on File Stats and select float from context menu

8). I drag Tool 2 and Dock.Right into Tool 1
9). I drag Tool 3 and Dock.Bottom into Tool 1
10). I drag File Stats and Dock.Bottom into Tool 2
11). I drag the floating group panel comprised of panels from step 8 - 10 and drag over to my 2nd monitor and maximise the FloatingGroup
12). Select Save from File and Save from Layout menu
13). Close the app
14). See that avalondock.layout.config is now in \bin directory
15). Reload the application again
16). Results - the grouped panels are maximised on my 1st monitor

Below is screenshot of what I get:

Below is screenshot of what I expect:

Below is the layout config file that was generated:

AvalonDock.Layout.config.txt

Hope this helps

[mbullock976]

@Dirkster99

I notice it only works if I dock 'all the panels together horizontally' or 'all the panels vertically'

Screenshot of floating group of panels vertically:

Screenshot of floating group of panels horizontally:

Layouts generated:

AvalonDock.Layout.config.Docked_Vertically(Works).txt

AvalonDock.Layout.Docked_Horizontally(Works).txt

[mbullock976]

@Dirkster99 Just to let you know, I was able to get MLib_Test to replicate the screenshot you originally sent me, that works for me too which is strange, whereas my tests above don't work?

Ideally I am looking to have unlimited number of panels to be part of a floating group for 2nd monitor, but is ok if there will be a limit

[Dirkster99]

I can verify your problem with my screen setup. Thanx for the detailed explaination.
AvalonDock.Layout.txt

More likely than not, we have to extend this fix to also account for LayoutAnchorablePaneGroups - but give me a bit of time to analyze the problem :-)

[mbullock976]

I’m glad you are able to reproduce my problem.

I understand that it might take some time to analyse and fix this issue.

I look forward to some good news soon :-)

[Dirkster99]

Hi,

found the root cause of your problem thanks to the hard work you put into finding a deterministic way of verifying it :-) The problem is right in the DokumentManager.CreateUIElementForModel() method.

This method is invoked after deserialization of the XML to instantiate the content within its correct container. Here is the line that been buggy:

        var paneForExtensions = modelFW.RootPanel.Children.OfType<LayoutAnchorablePane>().FirstOrDefault();
        if( paneForExtensions != null )
        {
          //ensure that floating window position is inside current (or nearest) monitor
          paneForExtensions.KeepInsideNearestMonitor();

          newFW.Left = paneForExtensions.FloatingLeft;
          newFW.Top = paneForExtensions.FloatingTop;
          newFW.Width = paneForExtensions.FloatingWidth;
          newFW.Height = paneForExtensions.FloatingHeight;
        }

newFW.ShowInTaskbar = false;

The problem with this code is that it completely ignores the fact that you could also have the LayoutAnchorablePaneGroup at the base of a floating window (as we discovered here). So, for reference, the fix is simply an else {} branch to test and implement that situation.

        var paneForExtensions = modelFW.RootPanel.Children.OfType<LayoutAnchorablePane>().FirstOrDefault();
        if( paneForExtensions != null )
        {
          //ensure that floating window position is inside current (or nearest) monitor
          paneForExtensions.KeepInsideNearestMonitor();

          newFW.Left = paneForExtensions.FloatingLeft;
          newFW.Top = paneForExtensions.FloatingTop;
          newFW.Width = paneForExtensions.FloatingWidth;
          newFW.Height = paneForExtensions.FloatingHeight;
        }
        else
        {
          // Floating Window can also contain only Pane Groups at its base (issue #27) so we check for that
          // and make sure the window is position back to where it was before (or the nearest monitor)
          var panegroup = modelFW.RootPanel.Children.OfType<LayoutAnchorablePaneGroup>().FirstOrDefault();
          if (panegroup != null)
          {
            panegroup.KeepInsideNearestMonitor();  // Check position is valid in current setup

            newFW.Left = panegroup.FloatingLeft;   // Position the window to previous or nearest valid position
            newFW.Top = panegroup.FloatingTop;
            newFW.Width = panegroup.FloatingWidth;
            newFW.Height = panegroup.FloatingHeight;
          }
        }

newFW.ShowInTaskbar = false;

This fix is available in a seperate branch called FloatingWindowGroup together with the other fix for issue #28. Could you download this branch and test it floating windows please? I have identified a few test cases for how you can drag and drop different configurations together - you surely do not have to test all of them but it would be cool if you could confirm 3-4 cases out of this collection tested with the second monitor maximize/normal layout. I could then prepare the next minor release from these solutions :-)

[mbullock976]

Hi @Dirkster99

Awesome work!, I've gone through all the test cases which seem to work fine, except Test Case 9.

I've tested Test Cases 0 - 9 using the latest commit of the FloatingWindowGroup

Test Cases 0 - 8 are working correctly as you've specified and I have matching xml files and they are appearing on the 2nd monitor as described in you screenshots :-) :-) :-)

Test Case 9 - You've almost resolved it. However I've spotted one particular case it still reloads on the 1st monitor. My test is consistent and repeatable.

Essentially, following the steps of Test Case 9, if you Maximise the Floating Group Window 'before' docking the File Stats tool window test step...then the floating group window reloads on 1st monitor. Below is the xml results of Test Case 9:
(it works if you dock all 4 panels first, then maximise on 2nd monitor)

There seems to be some differences in the xml, if you maximise the the Floating Group before docking the file stats panel (e.g the 2nd LayoutAnchorableGroup is missing FloatingWidth, FloatingHeight, FloatingLeft, FloatingTop and IsMaxmised flags

Test Case 9 - Reloads on 1st monitor (maxmise group before dock filestats).config.txt

Test Case 9 - Reloads on 2nd monitor - Dock all 4 panels first - then maximise the Floating Group.config.txt

[Dirkster99]

The problem with the missing IsMaximized and FloatingWidth, FloatingHeight, FloatingLeft, FloatingTop properties seems to be caused by the creation of LayoutAnchorablePaneGroup in AnchorablePaneDropTarget.

So, instead of finding a child under the RootPanel I have opted to go for the RootPanel itself since this already a LayoutAnchorablePaneGroup and seems to hold the required information in all test case concerned. So, the above code in the DockingManager is now replaced with this code:

// Floating Window can also contain only Pane Groups at its base (issue #27) so we check for
// RootPanel (which is a LayoutAnchorablePaneGroup) and make sure the window is positioned back
// in current (or nearest) monitor
var panegroup = modelFW.RootPanel;
if (panegroup != null)
{
  panegroup.KeepInsideNearestMonitor();  // Check position is valid in current setup

  newFW.Left = panegroup.FloatingLeft;   // Position the window to previous or nearest valid position
  newFW.Top = panegroup.FloatingTop;
  newFW.Width = panegroup.FloatingWidth;
  newFW.Height = panegroup.FloatingHeight;
}

...


  if( panegroup != null && panegroup.IsMaximized )
  {
    newFW.WindowState = WindowState.Maximized;
  }
  
  return newFW;
}

This seems to be a lot more straightforward and reliable as it works for all tests that I was able to come up with. The inconsistency with the missing properties is still at large but I am thinking right now that I rather leave this as it is since I am not completely sure whether this realy has to be fixed or not - so, I might look at this in anther issue :-)

Please let me know what you think about this fix, thanks

[mbullock976]

HI @Dirkster99

Thanks, the last commit seems to be working for me now for Test Case 9 using the MSLib_Test app.
I'm happy if you want to commit this into the next release.

I tried to see if this branch would work with my solution. However I'm still getting it reloading on the 1st monitor for test case 9.

To test, I replaced my nuget references to the latest release of this repo and instead referenced the avalondock and avalondock.themes.2013 cs projects within my solution.

Strange thing is, if I run the MSLib_Test app with the xml file produced from my solution it loads up correctly on the 2nd monitor...I was able to debug into the new code changes you made from my solution...so something must be different between your test app and my wpf app

[mbullock976]

@Dirkster99 I've managed to get my app to load the layout correctly on the 2nd monitor using this branch now.

My wpf app is a MVVM implementation. It might be a bit early to say but it could be down to me loading and saving the layout using attached behaviour (i.e Behaviour < < DockingManager > >). I chose this way, to prevent adding code behind into my mainwindow.xaml.cs

However, if I remove this attached behaviour and instead move the xmllayoutserializer code into my MainWindow.xaml.cs (in the same way as your mvvm test app), then it works correctly.

So for now I shall try and remove my attached behviours for load and save and instead move the layout serializer and deserialize into the code behind of the main window, thanks

[mbullock976]

I can confirm my app is now working correctly with the 2nd monitor.

I've discarded my attachedbehaviour classes that attached to the dockingmanager to perform the xml serialize and deserialize...and instead moved that logic into my MainWindow code behind.

Thank you for all you help on this !!!! and I look forward to having the your fixes here pushed into a new release :-)

[Dirkster99]

Hi,

its great to here this is starting to work for your application as well. Release 3.5.5. is out and the Nugets are available as we speak ...

I could take a guess if you would share the code for your behavior(?).

I don't know why your behavior would not work - I prefer behaviours as well, but they also have a downsides:
-they are more difficult to debug and
-its also OK to have a view implement code behind - the code you mentioned - could for example, be moved into a seperate user control and there is not that much wrong with it - I've done that in Edi too.

[mbullock976]

Hi,

Thanks I’ll start using release 3.5.5

I agree about your opinion regarding behaviour, as it’s also difficult to unit test.

I’ll try your idea with a user control, that might be better

[Dirkster99]

OK I close this for now - I saw a custom WIX setp project somewhere in your repositories and that made me think if you could help me getting a simple setup to work for my Edi project.

Normal setup projects don't work for this since the build output is generated from several independent projects that are not all referencing each other. So, the challenge is to build a setup for all files contained in a folder called Release - sound simple - but so far it does not seem to be as simple as it should...

[mbullock976]

Yes sure. I'll try and setup up a wix installer for the EDI project. I'm still quite new to it but I'll try and upload a working solution. Allow for a few days please, thanks,

[mbullock976]

Hi @Dirkster99

I've forked your EDI project here and added a wix installer solution to it (new installer folder)

https://github.com/mbullock976/Edi

This contains a new installer.sln which will using Wix Toolset 3.11.1, build a MSI by scraping the contents of the EDI release folder. PS you have to build the EDI project first in Release mode before running the installer.

My commit comments might also help

I've also added in a links.txt of useful tips and tricks.

This project generates a new MSI file in the Installer\Installs folder. I've uploaded a working MSI file for you to test.

If you're familiar with Costura Fody on nuget, this can reduce the binaries down to just the exe and the exe config required for deployment, thus bringing down the size of the MSI

Hope this helps

[Dirkster99]

Cool - I got it to work and build an MSI file - thanks so much for that - I'll study the links you've send and hopefully this will be an off to a good start :-)