2012-05-11 12 views
0

オブジェクトに接続されている場所が問題であれば、私は駄目でした。たとえば、私が信号を発信するかもしれない呼び出しを行う前に私はそれを行うのですが、コールが行われるまで存在しないQNetworkReplyなどのノードの場合は、後でそれを行う必要があります。たぶん、私は接続が行われる前にいくつかのチェックをする必要があります。接続先はどこですか?

この信号をスロットに接続する接続が行われる前に、信号が放射される可能性はありますか?例えば

ClassA::function() { 

    ClassB b; 

    b.someCall(); 

    connect(&b, SIGNAL(finished()), this, SLOT(someSlot())); 
} 

ClassB::someCall() { 

    emit finished(); 

} 

はスロットがここに呼ばれることだろうか?この場合、戻り値を使用する可能性があるため、これはあまり実用的ではありません。しかし、いくつかのケースで私はこれを行います。例えば、 "someCall"が踏み込むことができるルーチンであり、そのルーチン内のネットワーク要求が失敗した場合、または最初に何らかのエラーが発生した場合、失敗する可能性があります。いずれにしても、 "failed()"信号が出力され、あらゆる種類の障害を処理するためのスロットが必要です。例えば;

ClassB::someCall() { 

    allocate "something" 

    if(something == NULL) emit finished(); 


    QNetworkReply *reply = someNetworkAccessManager.put(something); 

    connect(reply, SIGNAL(finished()), this, SIGNAL(finished())); 

} 

ここで、finish()をほぼすぐに、またはしばらくしてから呼び出すことができます。この呼び出しを行った後に接続を作成すると、最初のfinished()がキャッチされますか?

答えて

1

いいえ、mocはQT用の接続マクロを処理し、信号とスロットの魔法を実行するために必要なすべての基盤を作成します。 mocがプロジェクトにコードを追加する場所の可視性が、関数呼び出しを解決しようとするときにコンパイラのスコープ内にある限り、すべてうまくいくでしょう。そして、実際には、これらの接続呼び出しを可能な限り早く、つまりオブジェクトが宣言された後で、ヘッダ内で使用される前に配置します。

+0

あなたの答えは尋ねられていたものとはほとんど関係ありません。最後の文だけが答えを提供すると言いますが、実際にはありません。別のスレッドに存在するQObjectインスタンスには注意が必要です。それ以外の場合は、QObjectのシグナルソースインスタンスの構築との接続がどのくらい離れているかは重要ではありません。接続が確立する前にイベントループに戻っていない限り、あなたは大丈夫です。 –

関連する問題