[GH-ISSUE #112] Ensure that all UI-related methods are called in the UI thread.

gitea-mirror commented

2026-05-05 11:03:13 -06:00

Owner

Originally created by @pauldotknopf on GitHub (Mar 23, 2019).
Original GitHub issue: https://github.com/qmlnet/qmlnet/issues/112

This includes things like activating signals, working with INetJsValue, etc.

This will ensure correctness in programs.

There will be an option to delete it for unit testing. By default, it will be enabled.

Originally created by @pauldotknopf on GitHub (Mar 23, 2019). Original GitHub issue: https://github.com/qmlnet/qmlnet/issues/112 This includes things like activating signals, working with ```INetJsValue```, etc. This will ensure correctness in programs. There will be an option to delete it for unit testing. By default, it will be enabled.

gitea-mirror closed this issue

2026-05-05 11:03:13 -06:00

gitea-mirror commented

2026-05-05 11:03:17 -06:00

Author

Owner

@pauldotknopf commented on GitHub (Mar 23, 2019):

You will likely want to disable this for unit tests.

QmlNetConfig.ShouldEnsureUIThread = false;

@pauldotknopf commented on GitHub (Mar 23, 2019): You will likely want to disable this for unit tests. ``` QmlNetConfig.ShouldEnsureUIThread = false; ```

gitea-mirror commented

2026-05-05 11:03:17 -06:00

Author

Owner

@WingedToaster commented on GitHub (Sep 13, 2019):

How do I force a task to run on the UI thread? I have a serial port device and it is receiving data in a secondary thread. I am validating the data an then need to show a result screen but I am running up against this exception.

@WingedToaster commented on GitHub (Sep 13, 2019): How do I force a task to run on the UI thread? I have a serial port device and it is receiving data in a secondary thread. I am validating the data an then need to show a result screen but I am running up against this exception.

gitea-mirror commented

2026-05-05 11:03:18 -06:00

Author

Owner

@TripleWhy commented on GitHub (Jan 11, 2020):

@pauldotknopf Any progress on this? Or perhaps a recommendation on how to raise signals from non-UI threads?
This is possible in Qt, actually it is one of its core features.
In Qt, we can even choose how inter-thread signals are handled, per connection: <https://doc.qt.io/qt-5/qt.html#ConnectionType-enum

As a side note, this can't be done from the C#-side, since the main thread is locked in the app.Exec() call.

@TripleWhy commented on GitHub (Jan 11, 2020): @pauldotknopf Any progress on this? Or perhaps a recommendation on how to raise signals from non-UI threads? This is possible in Qt, actually it is one of its core features. In Qt, we can even choose how inter-thread signals are handled, per connection: <https://doc.qt.io/qt-5/qt.html#ConnectionType-enum As a side note, this can't be done from the C#-side, since the main thread is locked in the `app.Exec()` call.

gitea-mirror commented

2026-05-05 11:03:19 -06:00

Author

Owner

@WingedToaster commented on GitHub (Jan 11, 2020):

https://github.com/qmlnet/qmlnet/issues/165

@WingedToaster commented on GitHub (Jan 11, 2020): https://github.com/qmlnet/qmlnet/issues/165

gitea-mirror commented

2026-05-05 11:03:20 -06:00

Author

Owner

@TripleWhy commented on GitHub (Jan 11, 2020):

Thanks for this.
But since you don't sound convinced you did it correctly, and because this is the place where the exceptions sends you to, I would still like to see an official recommendation here.

@TripleWhy commented on GitHub (Jan 11, 2020): Thanks for this. But since you don't sound convinced you did it correctly, and because this is the place where the exceptions sends you to, I would still like to see an official recommendation here.

gitea-mirror commented

2026-05-05 11:03:21 -06:00

Author

Owner

@WingedToaster commented on GitHub (Jan 11, 2020):

No worries. My last post on the issue is pretty much how it stayed and now it’s on 11 devices out in the wild, soon to be 200.

@WingedToaster commented on GitHub (Jan 11, 2020): No worries. My last post on the issue is pretty much how it stayed and now it’s on 11 devices out in the wild, soon to be 200.

gitea-mirror commented

2026-05-05 11:03:21 -06:00

Author

Owner

@pauldotknopf commented on GitHub (Jan 11, 2020):

This issue was about ensuring, via validation, that all interactions with QObjects-and-friends where on the main thread. I have done this. See this.

As for running actions on the UI thread, this is done, and there are a few options.

Methods like Qml.Net.Signals.ActivateSignal do things correctly, just like in Qt land. The handlers for the signals get called on the thread that owns the QObject (the main thread).
There are methods like Qml.Net.QCoreApplication.Dispatch(Action action) and await Qml.Net.QCoreApplication.DispatchAsync(Func<Task> action). These allow you to dispatch .NET delegates to the UI thread. In my applications, I create an IDispatcher interface.

public interface IDispatcher
{
    void Dispatch(Action action);

    Task DispatchAsync(Func<Task> action);
    
    bool IsMainThread { get; }

    void VerifyMainThread();
}

class QtDispatcher : IDispatcher
{
    private readonly QCoreApplication _application;
    
    public QtDispatcher(QCoreApplication application)
    {
        _application = application;
    }

    public void Dispatch(Action action)
    {
        _application.Dispatch(action);
    }

    public Task DispatchAsync(Func<Task> action)
    {
        return _application.DispatchAsync(action);
    }

    public bool IsMainThread => QCoreApplication.IsMainThread;
    
    public void VerifyMainThread()
    {
        if (!IsMainThread)
        {
            Console.WriteLine("Not main thread!");
            throw new InvalidOperationException(
                "The calling thread cannot access this object because a different thread owns it.");
        }
    }
}

This allows me to keep Qt-specific bits out of my business logic, while still having the concept of a "GUI" thread.

In the .NET types that I register with QML, I listen to some global system-level events. I use this interface to jump back into the GUI thread so that I can update properties/etc.

@pauldotknopf commented on GitHub (Jan 11, 2020): This issue was about *ensuring*, via validation, that all interactions with QObjects-and-friends where on the main thread. I have done this. See [this](https://github.com/qmlnet/qmlnet/blob/develop/src/net/Qml.Net.Tests/BaseTests.cs#L12). As for running actions on the UI thread, this is done, and there are a few options. 1. Methods like ```Qml.Net.Signals.ActivateSignal``` do things correctly, just like in Qt land. The handlers for the signals get called on the thread that owns the QObject (the main thread). 2. There are methods like ```Qml.Net.QCoreApplication.Dispatch(Action action)``` and ```await Qml.Net.QCoreApplication.DispatchAsync(Func<Task> action)```. These allow you to dispatch .NET delegates to the UI thread. In my applications, I create an ```IDispatcher``` interface. ```csharp public interface IDispatcher { void Dispatch(Action action); Task DispatchAsync(Func<Task> action); bool IsMainThread { get; } void VerifyMainThread(); } ``` ```csharp class QtDispatcher : IDispatcher { private readonly QCoreApplication _application; public QtDispatcher(QCoreApplication application) { _application = application; } public void Dispatch(Action action) { _application.Dispatch(action); } public Task DispatchAsync(Func<Task> action) { return _application.DispatchAsync(action); } public bool IsMainThread => QCoreApplication.IsMainThread; public void VerifyMainThread() { if (!IsMainThread) { Console.WriteLine("Not main thread!"); throw new InvalidOperationException( "The calling thread cannot access this object because a different thread owns it."); } } } ``` This allows me to keep Qt-specific bits out of my business logic, while still having the concept of a "GUI" thread. In the .NET types that I register with QML, I listen to some global system-level events. I use this interface to jump back into the GUI thread so that I can update properties/etc.

gitea-mirror commented

2026-05-05 11:03:22 -06:00

Author

Owner

@TripleWhy commented on GitHub (Jan 11, 2020):

Thanks for the reply. I am using exactly what you have described in 1, and have never expected there to be an issue. Yet, after I upgraded the Qml.Net version to 0.10.1 recently, I suddenly get the exception that sends me here, anytime I want to activate a signal from a non-UI thread.
That is caused by this line. Stack trace, in case you are interested:

System.Exception: You must be on the UI thread to perform this task. See https://github.com/qmlnet/qmlnet/issues/112
   at Qml.Net.QmlNetConfig.<>c.<.cctor>b__17_0()
   at Qml.Net.QmlNetConfig.EnsureUIThread()
   at Qml.Net.Internal.Types.NetReference.ActivateSignal(String signalName, Object[] parameters)
   at Qml.Net.Signals.ActivateSignal(Object instance, String signalName, Object[] args)

@TripleWhy commented on GitHub (Jan 11, 2020): Thanks for the reply. I am using exactly what you have described in 1, and have never expected there to be an issue. Yet, after I upgraded the Qml.Net version to 0.10.1 recently, I suddenly get the exception that sends me here, anytime I want to activate a signal from a non-UI thread. That is caused by [this line](https://github.com/qmlnet/qmlnet/blob/v0.10.1/src/net/Qml.Net/Internal/Types/NetReference.cs#L37). Stack trace, in case you are interested: ``` System.Exception: You must be on the UI thread to perform this task. See https://github.com/qmlnet/qmlnet/issues/112 at Qml.Net.QmlNetConfig.<>c.<.cctor>b__17_0() at Qml.Net.QmlNetConfig.EnsureUIThread() at Qml.Net.Internal.Types.NetReference.ActivateSignal(String signalName, Object[] parameters) at Qml.Net.Signals.ActivateSignal(Object instance, String signalName, Object[] args) ```

gitea-mirror commented

2026-05-05 11:03:23 -06:00

Author

Owner

@pauldotknopf commented on GitHub (Jan 11, 2020):

Oh, I see.

Yeah, that might be a little too aggressive. We should probably remove that check in NetReference.ActivateSignal.

@pauldotknopf commented on GitHub (Jan 11, 2020): Oh, I see. Yeah, that might be a little too aggressive. We should probably remove that check in ```NetReference.ActivateSignal```.

gitea-mirror referenced this issue

2026-05-05 11:20:35 -06:00

[PR #68] [MERGED] Fixed typo in README.md #195

Rows
Columns

[GH-ISSUE #112] Ensure that all UI-related methods are called in the UI thread. #68