1

サードパーティのライブラリを使用して、サードパーティの入力デバイスからWindowsフォームにデータを通信しています。私が探しているのは、デバイスから入力データを収集して処理し、特定の条件が与えられた場合に、何が起こっているかをWindowsUIスレッドに報告することです。サードパーティのDLLのソースコードにアクセスできませんが、メインメソッドがバックグラウンドプロセスにあり、作成しなかったために結果をメインUIスレッドに返すことができないことを知っていますか？

Windowsフォーム：

public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();

        // create instance of my listener
        MyListener listener = new MyListener(this);
        Controller controller = new Controller(listener);
   }
}

サードパーティクラスのリスナーを拡張するMyListenerクラス：

public class MyListener : Listener
{
    public Form1 form;
    private Frame frame;

    // overloaded constructor
    public LeapListener(Form1 f)
    {
        form = f;
    }

    /// <summary>
    /// onFrame is the main method that runs every milisecond to gather relevant information 
    /// </summary>
    public override void onFrame(Controller controller)
    {
        // Get the most recent frame and report some basic information
        frame = controller.frame();
     }
 }

問題は、MyListenerクラス内のどこからでもメインUIスレッドに通信できることですが、onFrameメソッドはバックグラウンドスレッドで実行されているため、通信できません。とにかく、私が作成しなかったバックグラウンドスレッドからメインスレッドを取得する方法はありますか？

ReportProgressを試し、MyListenerでイベントを作成しようとしましたが、onFrameからメインUIスレッドと通信しようとすると、アプリケーションがクラッシュし、無効なメモリロケーションエラーが発生します。

どんな助けでも大歓迎です。

4

1 に答える 1

0

Usually, trying to access a UI object from a thread other than the one handling the UI is problematic. This is not a windows only problem, but a more general pattern.

The usual solution is to setup some form of event propagation mechanism, which would contain the data needed to update the UI, and let the main thread handle that task.

Let's call the UI thread UI, and the Background thread BT.

You could have a function which post an event to UI from BT, and then block BT until the event is processed by UI. It's a simple system using a semaphore to block BT until UI releases it. The advantage of such a system is that it's simple, you don't need to handle more than one event at a time from either thread. The downside is that if events take a long time to be processed, the application would have a very poor sampling resolution from the device. An alternative (and better) way is to create an event queue, have BT post to it, and UI poll it to update itself. It requires a bit more work, but it's way more resilient to UI long timing.

For that second technique, you must establish a format for your event, setup a shared and mutex guarded queue between BT and UI, and the rest should be easy to do.

The queue could be something like the following:

#include <queue>


template <typename EVENT>
class EventQueue {
   protected:
     typedef EventQueue<EVENT> self_type;
     typedef std::queue<EVENT> queue_type;
     Mutex m_;
     queue_type q_;
     void lock(){
         // lock the mutex
     }
     void unlock(){
         // unlock the mutex
     } 
   public:
     EventQueue() {
        // initialize mutex
     }
     ~EventQueue() {
        // destroy mutex
     }

     void push(EVENT &e){
         lock();
         q_.push(e);
         unlock();
     }
     EVENT &pop(){
         EVENT &e;
         lock();
         e = q_.pop();
         unlock();
         return e;
     }
     int size(){
         int i;
         lock();
         i = q_.size();
         unlock();
         return i;
     }
};

This is very simple as you can see, you just have to use the template above with whatever EVENT class you need.

I have left out the code handling the mutex, it depends on which api you want to depend on. As stated above, UI must only poll the queue, that is check the size of the queue, and take an event out if there's one available. On BT side, all you need to do is to include the event push call in your MyListener class, instead of accessing the form directly.

This method is very effective at letting both threads working together without stepping on each other toes.

于 2012-12-14T20:38:59.667 に答える