Skip to content
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

Closed
wants to merge 7 commits into from

Conversation

halgab
Copy link
Contributor

@halgab halgab commented Jun 27, 2023

Proposed changes

Microsoft Reviewers: Open in CodeFlow

@ghost ghost assigned halgab Jun 27, 2023
@ghost ghost added the area: NRT label Jun 27, 2023
@halgab halgab marked this pull request as ready for review June 27, 2023 21:24
@halgab halgab requested a review from a team as a code owner June 27, 2023 21:24
@elachlan
Copy link
Contributor

Why the change away from IComponent to Control?

@halgab
Copy link
Contributor Author

halgab commented Jun 29, 2023

Because we keep casting the IComponents to Control, to the point where they can't not be Control instances. So I figured it would be simpler to be more specific and stop casting around all the time.

@elachlan
Copy link
Contributor

Awesome. Sounds good.

Copy link
Contributor Author

@halgab halgab left a 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)
Copy link
Contributor Author

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

@halgab halgab marked this pull request as draft June 30, 2023 07:32
@ghost ghost added the draft draft PR label Jun 30, 2023
@halgab halgab marked this pull request as ready for review June 30, 2023 21:32
@dreddy-work dreddy-work marked this pull request as draft June 30, 2023 21:46
@halgab halgab marked this pull request as ready for review July 1, 2023 12:19
@ghost ghost removed the draft draft PR label Jul 1, 2023
LeafShi1
LeafShi1 previously approved these changes Jul 5, 2023
Copy link
Member

@dreddy-work dreddy-work left a 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?

@ghost ghost added the 📭 waiting-author-feedback The team requires more information from the author label Jul 5, 2023
@halgab
Copy link
Contributor Author

halgab commented Jul 5, 2023

I'm usually having a pretty hard time running tests locally, but sure, I'll have a look. I understand your concerns

@ghost ghost removed the 📭 waiting-author-feedback The team requires more information from the author label Jul 5, 2023
@dreddy-work dreddy-work added the 📭 waiting-author-feedback The team requires more information from the author label Jul 6, 2023
@dreddy-work
Copy link
Member

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 start-vs.cmd from the repo root, it should load everything needed.

@ghost ghost removed the 📭 waiting-author-feedback The team requires more information from the author label Jul 11, 2023
@dreddy-work
Copy link
Member

We will take this early in 9.0

@@ -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)
Copy link
Member

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

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Member

@KlausLoeffelmann KlausLoeffelmann left a 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();
Copy link
Member

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)
Copy link
Member

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()
Copy link
Member

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?

@ghost ghost added the 📭 waiting-author-feedback The team requires more information from the author label Oct 10, 2023
@RussKie
Copy link
Member

RussKie commented Oct 11, 2023

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.

@halgab
Copy link
Contributor Author

halgab commented Oct 11, 2023

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 ArrayLists with Lists help with the nullability annotations, so if that's okay with the team, I'll attempt to address the second bullet point in a first PR (staying conservative this time, again sorry for the mess here), and then follow-up with a NRT annotation PR.

@ghost ghost removed the 📭 waiting-author-feedback The team requires more information from the author label Oct 11, 2023
@halgab
Copy link
Contributor Author

halgab commented Oct 11, 2023

I've just opened #10091 that focus solely on the ArrayList removal. This should be easy to review

@halgab
Copy link
Contributor Author

halgab commented Oct 27, 2023

Closed in favor of #10091, #10092 and #10183

@halgab halgab closed this Oct 27, 2023
@halgab halgab deleted the DesignerUtils-nullable branch October 27, 2023 20:14
@ghost ghost locked as resolved and limited conversation to collaborators Nov 27, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants