0

私は現在、QTで非常に長時間実行されているGUIアプリケーションを使用しています。その後、そのアプリケーションは、フルスクリーンのキーボードなしで組み込みデバイス上でテストおよび実行される予定です。

デバッグを容易にするために、特定のアサーション（今のところ回避する必要のある既知のバグのある部分を含む可能性があります）などを無視できるカスタムアサーションマクロがあります。当面は、「アサーション：XXXX」などの何かをコンソールに出力します。失敗しました;中止/無視」。これは、コンソール内でアプリケーションを起動する場合は問題ありませんが、最終的なデバイスで実行すると最終的に失敗します。その場合、assertは入力を待機しているメインスレッドをブロックし、回復を期待せずにGUIをひどくハングさせます。

今、私はこの状況を改善する方法を考えています。1つのアイデアは、標準のアサートと同様に、アサートをクラッシュさせることです。しかし、私はそのアイデアがあまり好きではありません。なぜなら、多くの既知の問題があり、アプリケーションをテストするときに無視できるアサーションが非常に役立つことを常に知っているからです。また、メッセージを別のファイルに入れる必要があるので、後でテスト中に何が起こったかを確認できます。後でこれらのファイルを読むことは可能ですが、何が悪かったのかを見つけるためのより簡単な方法を望んでいます。

もう1つのアイデアは、代わりにウィンドウを作成することでした。ただし、アサートはどのスレッドでもトリガーされる可能性があり、GUIスレッドでのみ新しいウィンドウを作成できます。また、メインイベントループがassertによってブロックされる可能性があるため、イベントが正しく処理されるかどうかはわかりません。どういうわけか、いくつかのボタンのみを処理する、別のスレッドで完全に応答するスタンドアロンウィンドウが必要になります。

これはQT4でどういうわけか可能ですか？

4

1 に答える 1

1

メイン スレッドにイベントを投稿してダイアログを表示し、GUI 以外のスレッドからの応答を待つか、現在のスレッドがアプリ スレッドの場合はダイアログを表示するだけです。

int result = -1;
if ( QTrhead::currentThread() == QCoreApplication::instance()->thread() )
{
    result = AssertHandler->ShowDialog(where, what, condition);
}
else
{
    QMetaObject::invokeMethod(AssertHandler, "ShowDialog", Qt::QueuedBlockingConnection, Q_RETURN_ARG(int, result), Q_ARG(QString, where), Q_ARG(QString, what), Q_ARG(QString, condition);
}

if (result != 0)
{
     // handle assert
}

AssertHandler は、スロットを持つ QObject ベースのクラスint ShowDialog(const QString &where, const QString what, const QString &condition)です。アサートデータとボタンアサート/無視を含むダイアログを表示する必要があります。ユーザーが無視を押した場合は 0 を返し、それ以外の場合はゼロ以外の値を返します。

于 2012-10-29T14:21:25.607 に答える