Fix AutoScroll effectively deactivating description

[ite-klass]

between RightToLeft and AutoScroll

The value references were wrong.

However, the entire paragraph was misleading or wrong.

Not the RightToLeft property is decisive, but the Anchoring. The example took this implicitly into account, which made the whole paragraph even more confusing.

This change clarifies that and makes this a note.

[ite-klass]

Actually, there is more wrong references in this paragraph. But it is very confusing, because again it talks of AutoScroll as if being set to a RightToLeft value.

But what confuses me the most is the example it gives.

The issue is described as if AutoScroll is set to true but RightToLeft is set to false.

But the example talks about a right-anchor. That's not the same as RightToLeft. That sounds like yet another problem that just behaves the same, but is a different trigger/source.

[ite-klass]

I can confirm that right and bottom alignment breaks the AutoScroll functionality.

Hence, I think this should mention that explicitly.

[ite-klass]

I just tried RightToLeft. The issue is explicitly NOT about RightToLeft. It is about anchoring to bottom and right.

[mairaw]

@OliaG @merriemcgaw @RussKie can one of you review the changes made to ScrollableControl?

[RussKie]

@ite-klass thank you for the input, I agree the remark section is confusing.

However I wonder whether the remark only applies to certain versions of .NET Framework.
I have tried a Panel with AutoScroll = true, and anchoring a control on a panel to right, bottom and bottom right and in all cases the panel remained scrollable under .NET Framework 4.7.2 and .NET Core 3.0.

Do you have a repro that exhibits the scenario?

@Olina-Zhang do we have any tests for the described scenario?

[Olina-Zhang]

@RussKie, the test scenarios you tried are sufficient, it is just we can test other Scrollable container controls with same scenarios. This behavior should apply for all .Net frameworks and .Net Core 3.0.

The related doc is in https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.scrollablecontrol.autoscroll?view=netframework-4.8, we can see the "Remarks" area in there.

[ite-klass]

I had tested on a project targeting .NET Framework 4.0, and tested it in a TabPage I believe (which extends Panel and consequently ScrollableControl).

[RussKie]

@ite-klass are you able to share the repro?

[ite-klass]

No, not that project.

[ite-klass]

Do you want me to try and reproduce it in a new, empty project?

I guess that would make sense after you were not able to reproduce it in two instances, unless you have other plans.

[RussKie]

It would certainly help if you can provide a repro. This way we can test the issue, reason what versions are affected and update the docs as necessary.

For .NET Core 3.0 and .NET 5.0 issues you can raise the issue directly in our GitHub repo at https://github.com/dotnet/winforms/

Thank you

[ite-klass]

I created a test project https://github.com/ite-klass/TestWinFormsAutoSizeAnchors

The form contains four panels, each panel with AutoScroll true and one TextBox child with Multiline and a size exceeding the container size, and varying Anchor values.

I tried target .NET Framework 4.0, 4.5, 4.7.2. The issue exists in all those versions.

The behavior is as I described earlier. Right anchor prevents horizontal scrollbar. Bottom anchor prevents vertical scrollbar. No anchor also prevents scrollbar in the corresponding axis.

Screenshot in repo

It is visible in the designer and at runtime.

• VS 16.2.5
• Windows 10 x64 Enterprise 1903
• NET Install Release version 528040 (4.8)
• CLR 4.0.30319.42000
• In installed programs list I only see SDK 4.6.1, I can target 4.7.2 in VS though.

[RussKie]

Thank you for the repro.

It would be great if labels described expectations as well.

I tried your example on .NET Core 3.1 and it behaves the same way.

[mairaw]

@RussKie I'm a bit lost on what we want to do with this PR and it has been lingering for a few months. Do we want to accept or do we need to make changes? Thanks!

[RussKie]

@mairaw yes, we need to correct the docs.

[RussKie]

Thank you @ite-klass