Control.CheckForIllegalCrossThreadCalls to use Interlocked.Increment/Decrement

[ulfemsoy]

Background and motivation

Control.CheckForIllegalCrossThreadCalls is Boolean value that is not thread safe.

API Proposal

Replace with

Control.BeginIllegalCrossThreadCall() => Interlocked.Increment(...);
Control.EndIllegalCrossThreadCall() => Interlocked.Decrement(...);
Control.CheckForIllegalCrossThreadCalls => (Interlocked.Read(...) == 0);


### API Usage

```csharp

Control.BeginIllegalCrossThreadCall() ;
try
 {
// Get control handle, etc.
nint handle = control.Handle;

 }
finally
{
Control.EndIllegalCrossThreadCall() ;
}

Alternative Designs

Control.CheckForIllegalCrossThreadCalls could be [ ThreadStatic ].

Risks

No response

Will this feature affect UI controls?

Yes.

Will VS Designer need to support the feature? No
What impact will it have on accessibility? No
Will this feature need to be localized or be localizable? No

[JeremyKuhne]

@ulfemsoy CheckForIllegalCrossThreadCalls has to remain and work for compatibility. Changing it to a [ThreadStatic] directly is something that wouldn't be possible as it would dramatically change the behavior and would not be configurable. While we could conceivably do this by adding logic to the property and make it configurable, but that is pretty complicated and still somewhat risky as a global thing. We could possibly make it configurable per Control (ControlStyles maybe).

Is this showing up for you? Can you detail your scenarios?

[ulfemsoy]

@JeremyKuhne, The only purpose is to get access to the Control.Handle from another thread. I need the unsafe/raw window handle, and unfortunately the only option is to set the Control.CheckForIllegalCrossThreadCalls to false. IHandle, HandleInternal and HWNDInternal are all internal. Alternatively, is it possible to set any of these properties to public?

[JeremyKuhne]

@ulfemsoy I'll give it some thought. I'm not opposed to providing access to raw handles for advanced scenarios. This one is a little weird as the handle is already there. That said, intent is harder with the current method, hence our HandleInternal. Maybe we can layer the checks here. I presume you're not looking for auto-creation of the handle?

[ulfemsoy]

@JeremyKuhne, No, just the raw handle, if available. The handle will be used for short-lived SendMessage calls, etc. to the control from another thread. The purpose is not to create the control if it does not have a handle, as it would mess up the UI thread.

[JeremyKuhne]

@ulfemsoy Is posting instead of sending possible?

[ulfemsoy]

@JeremyKuhne , Yes, PostMessage will work as well, but getting the Handle of the Control will fail (since it is another thread).