Broken layout in 7.2

[Scyllinice]

Broken layout in 7.2

[GeorgRottensteiner]

I'll try to reproduce, but alas, it doesn't happen.

The dock panel positions are restored inside LoadSettings, which uses the DockPanelSuites internal layout restore.

The general window position is restored in WindowStateManager.GeometryFromString in the MainForm constructor.
My first test would be to move that call above LoadSettings.

Edit: Of course not above LoadSettings, because then it won't work. Can I provide you with a version with extra logging to check a few potential issues that might cause the problem?

[Scyllinice]

Sure. If you want to throw it up in a branch, I can pull it down and give it a go. The issue is consistent with me and hasn't gone away.

[GeorgRottensteiner]

In a quick hack I've just added the logging to the webmisc release (I'll do the branch if that step doesn't help us), so please download from https://www.georg-rottensteiner.de/webmisc/C64StudioRelease.zip

To look at the extra debug you need to run another program (https://www.georg-rottensteiner.de/webmisc/DebugHost2.zip)
Just run the exe, the extra log (if any) will be shown in that tool. If you then provoke the error I sincerely hope for an exception message showing up. I hope that's managable, I'll open up a new branch otherwise.
Thanks!

[Scyllinice]

No luck. No exceptions were thrown. The debug host only has the help path and OK<br>7.2<br>

[Scyllinice]

More data: it does only happen with scaling turned on.

If I set my resolution to something lower than 4k with 100% scaling, everything works as expected.

If I set the scaling to anything above 100%, the panels disappear again.

If I go back to 4k and set the scaling to 100%, the panels reappear with a maximized window.

So maybe it has something to do with how the docking library handles scaling.

[Scyllinice]

Looks like that might be the case

dockpanelsuite/dockpanelsuite#604

[Scyllinice]

Commenting out the call to DPIHandler.ResizeControlsForDPI( this ); in MainForm.cs causes the panels to appear with a maximized window, but the toolbars are wrong (of course).

I'm going to see if there's anything in there that leads me to a solution.

Edit:

So far I've narrowed it down to AdjustControlChildsSize. The loop that it does to go through all of the controls and call ResizeControlsForDPI again brings up the problem. Commenting either the call on line 124 of DPIHandler.cs or the call to ResizeControlsForDPI in AdjustControlChildsSize makes the panels appear.

I'm not entirely sure why and doing that is what causes the toolbars to be wrongly sized.

[GeorgRottensteiner]

Awesome work! I can't thank you enough.

In the end all boils down to AdjustControlSize, which just multiplies the size. Could you check the values of DPIX and DPIY inside?
These might be something unexpected, or the resulting size is maybe getting too large.

[Scyllinice]

It's late here, but I'll report back in the morning when I can give it a shot.

I do know that the value checked against 96 to set the DPI Ratio flag is 144. I don't know if they both were.

[GeorgRottensteiner]

No worries! Anything I can do to support, let me know.
The DPIHandler code is mine, so I expect the error to be in there.
I've only occasionally tested it in the highest DPI settings. I can't go higher than 1920 x 1080 though.

[Scyllinice]

Ok, I can confirm that both DPIX and DPIY are the same at 144.

What's interesting is if I drop a breakpoint right after the calculations of newWidth, newHeight, newX, and newY, the value of newX and newY are sometimes zero. Additionally, sometimes Control.Location.X and Control.Location.Y are also zero, and I don't know why. They definitely shouldn't be I don't think.

I'll dig some more later today and let you know what I come up with. I haven't done C# in many years, so I'm a bit rusty on debugging techniques :) (I haven't touched C# in any meaningful way since 2010)

[GeorgRottensteiner]

Now that's truly baffling. The variables are static and assigned once. I simple workaround would be to ignore setting anything if size and location are all zero.

[Scyllinice]

To be clear, the width and height are fine. It's the x and y coordinates that appear to be off. The output of the x and y calculations sometimes come out to zero where I don't think they should.

[Scyllinice]

Further debugging:

I output all of the newX, newY, newHeight, and newWidth values for every call to AdjustControlSize when the panels are there and when they are missing.

I diffed the files and they were identical.

The only things that make a difference in behavior for me is if I comment out the calls I mentioned. Either of them will make the problem disappear, but introduces a new problem.

This is very strange to me.

I even tried to see what would change if I just commented out the entire body of AdjustControlSize. Amazingly, the panels are still missing if I do that.

This does happen under 1920x1080 if you set the scaling option in the display settings to 125% or above, atleast for me.

[GeorgRottensteiner]

Ye Gods, I can provoke the bug. Having the most main panels (e.g. Solution Explorer, Output, etc..) starting at 0,0 is correct. The DockPanelSuite call later on should move and dock them where they were before. That is the part that seems to break and/or not do what it is supposed to do.

[Scyllinice]

Great, so I'm not crazy :). It makes sense that nothing I'm doing in DPIHandler changed behavior if the problem is in DockSuitePanel.

[GeorgRottensteiner]

Interesting. I've looked with Spy++. The panels are actually all there. But! There is a dock panel window in the center of C64Studio, everything is inside there. And there is a second child window at the exact same location, with a MDICLIENT class. When maximized, MDICLIENT comes first, and due to WM_CLIPSIBLINGS clips everything else.
If not maximized, the MDICLIENT comes after the main panel, and thus everything is visible.

Now just to figure out where that MDICLIENT thing comes from. I hope it's me.

[GeorgRottensteiner]

Quick hackaround: Add this after the applying of GeometryManager:

foreach ( Control ctrl in this.Controls )
{
// just wow
if ( ctrl is MdiClient )
{
ctrl.Visible = false;
break;
}
}

That simply looks for the MdiClient and hides it. I'll see if I find where it really comes from.

Urgh. In the Designer of MainForm set the IsMdiContainer to false (which is actually the default)

[GeorgRottensteiner]

Fixed with commit 1191723
At least that now works on my machine, please confirm if it also works for you.

[Scyllinice]

Confirmed fixed. It works great on my machine now.

Sorry I couldn't figure it out myself :D.

[GeorgRottensteiner]

Wouldn't have done without the info about maximize and scaling. Closing this.