-
Notifications
You must be signed in to change notification settings - Fork 983
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable nullability in DesignerUtils and replace ArrayList with List #9381
Conversation
b1cb929
to
8c1e1c0
Compare
Why the change away from |
Because we keep casting the |
Awesome. Sounds good. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I might have been a bit too optimistic. I'll rollback to a less ambitious version. I'll put this PR back to draft in the meantime
{ | ||
return; | ||
} | ||
|
||
foreach (IComponent childComp in designer.AssociatedComponents) | ||
foreach (T childComp in designer.AssociatedComponents) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that if this doesn't hold, we're going to break later, but I'm not 100% sure
1511576
to
8a7de66
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Logically looks good but hard to validate these design scenarios at runtime.
Any possibility to add some unit tests around these changes?
src/System.Windows.Forms.Design/src/System/Windows/Forms/Design/Behavior/DropSourceBehavior.cs
Outdated
Show resolved
Hide resolved
I'm usually having a pretty hard time running tests locally, but sure, I'll have a look. I understand your concerns |
Let me know what kind of issue you see when running tests locally. If you start VS using |
We will take this early in 9.0 |
86ac0bc
to
77459b8
Compare
@@ -216,16 +216,16 @@ private void SetDesignerHost(Control c) | |||
SetDesignerHost(control); | |||
} | |||
|
|||
if (c.Site is not null && !(c.Site is INestedSite) && destHost is not null) | |||
if (c.Site is not null && !(c.Site is INestedSite) && _destHost is not null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For readability, maybe we should rename c
to control
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is not annotated as part of this PR. Do you still want me to address this here, or should I wait for a dedicated PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think maybe you can do it in this PR, since it doesn't require many changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's done. This file could use some cleanup on other aspects, but I'll leave that for a subsequent PR
src/System.Windows.Forms.Design/src/System/Windows/Forms/Design/Behavior/DropSourceBehavior.cs
Show resolved
Hide resolved
eb5d403
to
c86efc3
Compare
c86efc3
to
906cd5f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have only started to look through this, but I am not at all feeling comfortable taking this.
Why can we assume, that the behaviors/designers only process Controls and no (I)Components or other objects?
I know in the Out-Of-Proc Designer, for example, this would not work.
But maybe I am missing some additional information or have not read previous discussions, so I am happy to hear more about this!
Thx!
@@ -205,7 +205,7 @@ private void StartDragOperation(Point initialMouseLocation) | |||
|
|||
//must identify a required parent to avoid dragging mixes of children | |||
Control requiredParent = _containerControl.Parent; | |||
List<IComponent> dragControls = new(); | |||
List<Control> dragControls = new(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we want to change this from IComponent
to Control
?
{ | ||
} | ||
|
||
/// <summary> | ||
/// Internal constructor that takes the service provider, the list of dragComponents, and a boolean | ||
/// indicating that we are resizing. | ||
/// </summary> | ||
internal DragAssistanceManager(IServiceProvider serviceProvider, List<IComponent> dragComponents, bool resizing) : this(serviceProvider, null, dragComponents, null, resizing, false) | ||
internal DragAssistanceManager(IServiceProvider serviceProvider, IReadOnlyList<IComponent> dragComponents, bool resizing) : this(serviceProvider, null, dragComponents, null, resizing, false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this not break backwards-compatibility in certain custom Designer scenarios? What makes us sure, that it doesn't?
@@ -16,7 +15,7 @@ internal class BehaviorDataObject : DataObject | |||
{ | |||
private readonly DropSourceBehavior _sourceBehavior; | |||
|
|||
public BehaviorDataObject(ICollection dragComponents, Control source, DropSourceBehavior sourceBehavior) : base() | |||
public BehaviorDataObject(List<Control> dragComponents, Control source, DropSourceBehavior sourceBehavior) : base() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How can we be sure only be getting controls at this point?
These are two different kind of changes that must not be mixed together. The latter one has much higher risk of introducing a breaking change. |
Yes, I get now that my attempt at a refactoring here got out of hand and shouldn't be mixed with the nullability here. I'll revisit this PR. My feeling is that replacing |
I've just opened #10091 that focus solely on the |
Proposed changes
DesignerUtils
.ArrayList
s withList<T>
s (contributes to ConvertArrayList
usage toList<T>
where possible #8140). This change should make it easier to annotate all the files touched by this refactoringMicrosoft Reviewers: Open in CodeFlow