I added this handler to fix a tooltip showing for a control when it loses focus.

Without this handler:

• Incorrect behavior when some different ToolTip instances are set:
  

• Incorrect behavior when one ToolTip instance is set:
  

With this handler:

• Expected work:
  

@RussKie, @M-Lipin, @Tanya-Solyanik, @JuditRose, @hughbe, @weltkante, could you please look and say what negative effect this might give for other controls and tooltips? I did not find any bugs.

Well, I recognize the behavior you describe and try to fix, I have seen it before in our applications but I never digged down to find its root cause. I don't know if the behavior was intended, so with your change you could either be breaking intended behavior or fixing a bug.

Either way your implementation is incorrect and can't be left this way, you are subscribing within a public API without ever unsubscribing, so multiple calls will accumulate event handlers. The typical pattern is unsubscribing and resubscribing - the first unsubscribe cleans up previous subscriptions (no-op if none exist). However since you are using a lambda capturing the control as a closure variable I don't know if this pattern works here. (I don't know how equality works when closures are in play, I'd expect each closure to be distinct so to unsubscribe you'd have to save the closure away, but I may be mistaken. If you want to test it you'd have to check that its not called multiple times after multiple SetToolTip calls by putting breakpoints or debug output into the LostFocus handler. You'd also have to check that calling SetToolTip on multiple controls doesn't unsubscribe each other.)

Good points, I will look at ways to fix these issues. Thank you!

@weltkante, I changed the implementation. Subscription and Unsubscription happen once now when setting a tooltip many times, I checked. Please review.

Also, I'll ask testers to test these changes using automated and manual testing.

I used protected for SetToolTip method thereby adding API for developers and they can change this implementation.
This is correct or I need to hide this protected API using the private protected modifier?
/cc: @RussKie, @Tanya-Solyanik, @merriemcgaw

Any custom control must be able to hook into the tooltip display chain to override the display logic, if necessary. With that, I believe, should be made protected.

This change to the public surface will not require designer changes, I don't see any problems with it.

How would you explain, when to use Tooltip.SetToolTip and when to use Control.SetToolTip?
Perhaps this method can be named differently?

That's the thing, I can't see any real benefit of using one over the other.
myToolTip.SetToolTip(myControl, toolTipText) calls into myControl.SetToolTip(myToolTip, toolTipText) which recurses.

I can guess the original idea of ToolTip was to extend arbitrary controls. However then a number of controls decided to displaying tooltips in their own way (e.g. Label when its text is ellipsised) by keeping own instances of ToolTip and exposing properties like ToolTipText. So now we have an inconsistent devex because for some controls a developer must use an instance of own ToolTip, and for some other control - not.

With this API cleanup we further blurring the line and removing reasons to use ToolTip control. Instead making it a little more consistent experience - each Control allows setting its tooltips in a common manner. There be 🐉 🐉 though (e.g. the Label's case) that we'll likely need to resolve. We touched on these with @vladimir-krestov and he was meant to raise issues for tracking purposes.
Also now it may be possible to reduce number of instances of ToolTip, have one global singleton per app and pass it to all controls that require tooltips.

Now we can probably take this further and question whether we can have a single instance of a ToolTip provider/renderer. But that's a whole separate discussion.

consider factoring this string out into a const field and using it everywhere in this file. Not necessarily in this same PR

please remove this qualifier

please remove the commented out line

If this was useful for feature development, it will be also useful when debugging this feature. Are there any problems with keeping this test?

The project "MultipleControls" test app already has TabControl inside for testing so I planned to remove the current app after the fix. Do you think we need a separate test app for TabControl to test TabPage tooltips work? If so, I'll refactor it later.

tt-> tooltip

on this line we know that control is not null be cause cast on line 644 succeed

Consider a simplified name - IsHovered

This property overrides Control.IsHoveredWithMouse property, which related to IKeyboardToolTip.IsHoveredWithMouse() method.

I think it will be incorrect to make different names.

We need to have xml-docs, so they will flow into the docs.

Why return;? It seems to me that method should call CreateHandle(); in case IsHandleCreated == false and should throw an ArgumentNullException in case toolTip == null.

Definitely not, you must not call CreateHandle when setting a tooltip, this would cause handle instantiation in the constructor during InitializeComponents before all designer properties have been set. The rest of the tooltip infrastructure has logic to not create handles and store the tooltip somewhere else when the handle is not created.

If anything you could throw an exception if this code path is taken when no handle is available, because it would be a bug in the internal logic.

I see that toolTipText is not used in some implementation. Please use default value for this.

I'll do, thanks!

It seems that call SetToolTip() with toolTip = null is not correct and we should throw ArgumentNullException. Maybe argument checks can be added to the base implementation and overridden methods should call base.SetToolTip() before the remaining implementation.

That's a good call.
We'll need to record this in dotnet/docs#17085

The same as previous: arguments check.

The same as previous: argument check.

The test ToolTipText != toolTipText is already in the property setter implementation.

Check `toolTip' for null in base method.