2016-12-22 9 views
0

ここ数週間、私は非常に細かいTSynEditコンポーネントに基づいてカスタムの社内コードエディタを作成していました。バックグラウンド処理用のスレッドセーフなTSynEditラインの作成

ユーザ入力を検証し、誤った構文を強調表示するためのエディタ行needeのバックグラウンド処理があります。この処理は、メインフォーム上のTTimerによって500ミリ秒ごとにトリガされます。 行数/エラーテキスト

std::map<int, String> 

を充填各ライン上

バリスレッド反復。

TSynEditのOnSpecialLineColorイベントがマップに対応する行を探しているとのisEmpty(もしさ)は行の背景が赤になり、falseです。

#include <memory> 

#define BOOST_THREAD_USE_LIB 
namespace boost { extern "C" void tss_cleanup_implemented(void) {}; } 
#include <boost/thread.hpp> 


class TMySynEdit : public TSynEdit 
{ 
private: 
    boost::mutex FMutexLines; 

    TStrings* GetLines() 
    { 
     boost::lock_guard<boost::mutex> guard(FMutexLines); 
     return TSynEdit::Lines; 
    } 

    void SetLines(TStrings* ALines) 
    { 
     boost::lock_guard<boost::mutex> guard(FMutexLines); 
     TSynEdit::Lines = ALines; 
    } 

public: 
    __fastcall TMySynEdit(TComponent* AOwner) 
     : TSynEdit(AOwner) 
    {} 

    virtual __fastcall ~TMySynEdit() 
    {} 

    __property TStrings* Lines = {read=GetLines, write=SetLines}; 
}; 

同期()または一部 WinAPIのメッセージのものを使用する必要がなく、十分にスレッドセーフSynEditを作るために、私の考えでは、このようなコードのいくつかの種類を使用することでした TSynEditのプロパティをスレッドセーフ(?)で上書きします。

タイマ起動スレッドは、boost :: threadで実行される解析機能です。

私の質問は今です: これは適切な解決法ですか、それとも何か不足していますか?

+0

あなたのソリューションは 'Lines'プロパティ自体を保護するだけで、' Lines'オブジェクト内の個々の行へのアクセスは保護しないので、リモートからスレッドセーフではありません。あなたの実際の処理スレッドはどこですか? 'TTimer'はスレッドではありません。あなたのタイマーは何かをするために別のスレッドを通知していますか?スリープループや待機可能なタイマーの代わりに、スレッド自体にUIタイマーを使用しているのはなぜですか? –

+0

実際のコードは私の作業マシン上にあり、私は今は私の祝日にいるので、簡単な説明しかできません: – FlKo

+0

最初のアイデアはすべての副作用のためにここでスレッドを使用しないことでした。このアプリケーションには、UIコントロールを有効にするためのものと、エラー処理のためのものがありますが、いくつかの小さな行のラックティックが必要でしたが、メインフォームに2つの個別のタイマーがありました。 boost :: thread thrd(&MyClass :: ParsingFunc、this); – FlKo

答えて

0

Remyのおかげで、仕事に戻ったときに私はおそらく非スレッド版に戻ります。

関連する問題