Add synchronization context

[breyed]

• Supports posting methods to the synchronization context to be dispatched from the message loop on the main thread.
• Events are forwarded directly to the handler, except that events from background threads or configured to post are posted to the synchronization context.
• When a task method completes, the status is posted on the synchronization context.
• C# async/await uses the synchronization context by default, causing continuations to run on the main thread. .NET code that can run safely on a background thread can opt to do so with ConfigureAwait(false).

This commit eliminates background thread calls into FoxPro and C# continuations, avoiding race conditions and data tearing, and providing a deterministic runtime environment.

[Copilot]

Pull Request Overview

This PR adds synchronization context support to wwDotNetBridge to enable proper thread marshaling between .NET and FoxPro. The key enhancement allows .NET events and async operations to be safely invoked on the FoxPro main thread, preventing reentrancy issues and enabling safe cross-thread communication.

Key changes:

• Introduces FoxProSynchronizationContext to marshal callbacks to the FoxPro UI thread using Windows messages
• Adds PostMethod and PostStaticMethod methods to queue method invocations instead of executing them immediately
• Refactors EventSubscriber to directly invoke handler methods instead of using an async wait pattern

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 12 comments.

Show a summary per file

File	Description
wwDotNetBridge.csproj	Enables latest C# language features
wwDotNetBridge.cs	Adds synchronization context infrastructure and splits invoke methods into immediate vs. posted execution paths
FoxProSynchronizationContext.cs	New class that implements Windows message-based synchronization for FoxPro interop
EventSubscriber.cs	Refactored to directly invoke handler methods with optional synchronization context posting
wwDotnetBridge.PRG	Adds PostMethod/PostStaticMethod APIs and updates event subscription to use new EventSubscriber design

Comments suppressed due to low confidence (4)

DotnetBridge/Utilities/FoxProSynchronizationContext.cs:38

• Poor error handling: empty catch block.

                try { postedEvent.handler(postedEvent.state); } catch { }

DotnetBridge/wwDotNetBridge.cs:770

• Variable args may be null at this access as suggested by this null check.

                if (args[i] is ComValue)

DotnetBridge/wwDotNetBridge.cs:1038

• Variable args may be null at this access as suggested by this null check.

                if (args[i] is ComValue)

DotnetBridge/Utilities/FoxProSynchronizationContext.cs:38

• Generic catch clause.

                try { postedEvent.handler(postedEvent.state); } catch { }

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[breyed]

Since with this PR all code running in FoxPro runs on the main thread, the multithreading-related caveats in the documentation can be removed:

• Calling Async or Task returning Methods
  • "not safe if multiple async requests are running"
  • "Keep Callback Handlers simple" (entire section)
• InvokeMethodAsync
  • "Remarks" (entire section). Should be replaced with comments in code about post option.
• InvokeTaskMethodAsync
  • “It’s recommended that if you do any significant code you schedule that code onto the main FoxPro thread.”