2

私は現在、Raw Input API からの情報を処理するライブラリを作成しており、すべてをカスケード関数で処理しています。これにより、いくつかの、非常に小さく、非常に読みやすく、非常に焦点を絞った関数が作成されました。

しかし、 Windows に障害を適切に示す方法を理解していないことに気付きました。私は機能を持っています：

/* OnInput: Handle data received from Windows via a `WM_INPUT` message. */
static LRESULT CALLBACK OnInput(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
    BOOL DispatchRawInput(CONST PRAWINPUT);

    assert(msg == WM_INPUT);

    return DefWindowProc(hWnd, msg, wParam, lParam);
}

そして、ドキュメントに記載されているようにゼロを返します。ただし、これは成功を前提としています。

実際のテキストには次のように記載されています。

「アプリケーションがこのメッセージを処理する場合、ゼロを返す必要があります。」

でも我慢できなかったらどうしよう。私は当初、電話してそのままにしておくだけだと思っDefWindowProcていましたが、それは何かが起こったことを Windows に知らせません。

このメッセージWM_CREATEは、ゼロ以外の値を返す唯一のインスタンスのようです。

「アプリケーションがこのメッセージを処理する場合、ウィンドウの作成を続行するには 0 を返す必要があります。アプリケーションが –1 を返す場合、ウィンドウは破棄され、CreateWindowEx または CreateWindow 関数は NULL ハンドルを返します。」

エラー処理は本当にプログラマー/チーム次第であり、オペレーティングシステムに通知する必要はありませんか? そのようなイベントWM_CREATEが失敗し、ウィンドウの作成を防ぐ必要がある場合はどうですか?

4

2 に答える 2

3

致命的なエラーの場合は、他の致命的なエラーと同じように処理する必要があります。何らかの方法でユーザーにエラーを通知します ( MessageBox、stderrなど) およびexit()またはabort().

致命的ではないエラーの場合は、それをアプリケーションに伝える必要があります。これは、フラグを設定する、関数を呼び出す、WM_APPメッセージを投稿するなど、さまざまな方法で実行できます。アプリケーションはそれを処理する必要があります。 . 全体として、Windows はあまり気にしません。合理的な方法でエラーを処理するのはユーザーの責任です。

他の人が使用することを意図したライブラリを作成している場合は、アプリケーションに明確に定義され文書化されたエラー手順があることを確認してください。ライブラリ内で内部エラーが発生した場合は、アプリケーションがエラー コールバックを指定できるようにしてから、そのコールバックを呼び出してアプリケーションに処理させます。

于 2013-08-28T20:42:28.920 に答える
1

各メッセージのドキュメントに従ってエラーを示します。メッセージがエラーについて何も述べていない場合は、メッセージにエラー インジケータがないことを安全に想定できます。これは、OS が単に何かが発生したことを通知する通知メッセージによく見られます。あなたからの返信は必要ありません。

于 2013-08-28T20:36:15.893 に答える