[Bug]: Docked controls are rendered with smaller size which hides the caption/title text.

[bakerhillpins]

Describe the bug This problem was mentioned during discussions in issue https://github.com/Krypton-Suite/Standard-Toolkit/issues/653#issuecomment-1093981598 by @iomismo and I don't see it being separately tracked so I decided to log it here. If I missed it being tracked somewhere else then my apologies.

Short story, Left/Right docked pages are only rendered wide enough to show the right hand side buttons.

It should also be noted that I've created a project where I've embedded a KryptonPanel with a KryptonDockingManager in a document and displayed it in a KryptonDockableWorkspace (so a nested docking panel) and I see the same type of issue in the working version.

Steps to reproduce the behavior:

1. Open the Demo project Krypton Docking Examples 2019 - Nuget.sln and set the startup project to Multi Control Docking 2019
2. Note that currently this project references <PackageReference Include="Krypton.Toolkit.Canary" Version="6.2110.274-beta" />
3. Debug the application and note that the vertically docked (not auto hidden) groups are displayed where one can read the caption/title.
4. Upgrade the Krypton packages to the latest version, such as: <PackageReference Include="Krypton.Toolkit.Canary" Version="65.22.3.89-beta" />
5. Rebuild and run and now the tabbed group is rendered like this:

Expected behavior The rendered tab should be wide enough to show the caption/title of the page. According to the discussion the last time this worked was version 6.2201.4.

I've created a project where I've embedded a KryptonPanel with a KryptonDockingManager in a document and displayed it in a KryptonDockableWorkspace (so a nested docking panel) and I see the same type of issue in 6.2201.4 version. After I submit this I'll modify the Krypton example for this design and upload it. Uploaded

Desktop (please complete the following information):

• OS: Windows 10 Pro
• Version 19044.1586

Here's the example project updated with an embedded DockingManager. The embedded docking manager has this issue regardless of the version. Krypton Docking Examples 2019 - Nuget.zip

[bakerhillpins]

Poking around in the code it seems that the size of the docked panel is determined by the call to KryptonWorkspaceCell.GetMinSize() here.

If I put a breakpoint on the returned size and modify the width it will compensate.

While stepping though the code I noted that the adjustment calculations do not ensure a positive result. I.e. a situation where sizeBefore < childSizeBefore. As I am not familiar with the system I don't know if there is a guarantee elsewhere in the code.

[edit] I just realized I'm sitting on the master branch and I suspect I need to be on canary or otherwise to see the current state. What branch should I be on when I'm looking to debug these errors? I'd hate to spend time on stuff you've already looked at or started changing. Thanks!

[PWagner1]

Hi @bakerhillpins

What branch should I be on when I'm looking to debug these errors?

The active development branch is alpha

[bakerhillpins]

After spending some time on this it seems like recent changes around how you calculate size are the culprit. Not that they are incorrect, it's that they seem to be using the MinimumSize property now where they were not in the past?

I.E. - If I update my code so the KryptonPage's I add to the Docking Manager have a Minimum size set (which overrides the default 50/50 value) then they render "correctly". Otherwise the code goes with 50 pix wide.

I'm not sure what your plans are around size (I still need to figure out how to retain the float page size) but it would seem that the minimum calculations that are currently in place should possibly include the width of the title text? Or just choose some value for KryptonPage.MinimumSize in the constructor that's greater than 50/50?

[Smurf-IV]

it's that they seem to be using the MinimumSize property now where they were not in the past?

This is so that the Dock page will be at "least" as wide as the control it contains, if a minimum size on the contained control has been set. If not then what you seeing is the result.

I'll try and investigate a "happy path" for these conditions

[Smurf-IV]

@bakerhillpins How this? Note: Comment corrected to state 150, 50

[bakerhillpins]

@bakerhillpins How this? Note: Comment corrected to state 150, 50

After playing with this quite a bit over the past few days and trying to control docked/floating sizes of my application components my opinion is that a sizing strategy built around only the MinimumSize property is inadequate (appears to be the current design based upon my code inspection).

I've spent time trying to rationalize the MS Docs on this subject and admit I'm far from a full understanding. However, it would seem that a proper strategy should be using the Control.Size (Possibly PreferredSize?) in conjunction with the Min/Max size and the available space in it's docking position (which obviously varies).

With the current design I've got no way to suggest a size to the system and provide my ideal constraints. If I set the MinimumSize to the size I'd like it I can get results that overwrite docking controls. I have a Document which would like to be close to the size of the screen. If I set that to the MinimumSize and display it, it overwrites any components docked Right.

Off the cuff it would seem that the size of any given window would be calculated by comparing it's Size, MinimumSize, MaximumSize and the space available by the docking element and making a best fit choice. For Left/Right docked components this is a width issue, Top/Bottom it's a Height issue, and Documents need both sizes considered (or possibly ignore both when docked in the workspace and considered only when Floating).

For example, Docked Left/Right/Top/Bottom would be a test of the "min" size of all Pages that share the same Cell. (min being the bigger of the Size and MinimumSize for each Page). If that result is less than the available size of the Dockspace then use. Unless it is less than a system specified min for the dockspace (Like the current 50/50). If it's larger than the Dockspace allows it gets clipped and the user should have added scrolling to their control.

Anyway, I know all of this is easier to say than implement in some cases.

[bakerhillpins]

Since this is about sizing:

I'm also trying to get sizing to adjust when a Page is floated. I've been looking at all the events generated when I float a Page (FloatspaceAdding FloatingWindowAdding etc) but none of them allow me access to the page or pages (usercontrol) that will be floated so I can't adjust the floating window size. One of the events (can't recall which right now) even mentions the point of it is to allow user setup of the window before it's shown. But with no access to the pages it seems that this is meant for generic theming.

In the end, the sizing I discussed in the above comment would probably deal with this issue on the 1st show of the floating window. The other issue at hand is user changes to floating window sizes. When a floating page is docked and then floated again any previous user adjustment of size while floated is lost (it returns to the default (300x300 IIRC). It would appear that some changes to the Placeholder Page (KryptonStorePage) behavior (see DockingPropogateAction.StorePages implementation in KryptonDockingSpace) might be a solution for storing the previously user defined size that could be restored.

[Smurf-IV]

However, it would seem that a proper strategy should be using the Control.Size

Is is. If the "Embedded control" (Different controls can have different sizes dependant on their intended usage) has a min size set, then that is used when setting the docking variables. If not it will resort to the new Size(...) passed in that will apply to "All" pages.

I'm also trying to get sizing to adjust when a Page is floated.

Again it currently should be the embedded control's min size (If set)

[Smurf-IV]

If you can word what you are trying to achieve and create a linked Feature request, then it can be looked at when next a visit to dicking occurs.