▼ なすこじさん
> ▼ kobakeさん
> いえ、FALSEは返ってきません。
> エラー処理は元々実装されているので、FALSEが来れば最初から問題無いです。
> APIがおかしいのか .nMaxFile をよほど小さくしないとtoo smallは返ってこないので別の対応が必要です。まぁ使い方がおかしいだけかもしれませんが……
>
> ANSIなので絶対パスは260バイト以下なわけですが、260バイト目まで文字を詰め込んできます。切れ目が2バイト文字の途中の場合、259バイト目まで詰め込んで260バイト目に0を書かずに返ってきます。
>
> 仮に今回too smallが来たとしても、ANSIで260バイトを超える絶対パスはMSの取り決めに反します。
> 260バイトを超えた絶対パスでいくとどうなるかは私は知りません。

なるほど、失礼しました。確かに試すとTRUEが返りますね。
がっつりエラーチェックをするならこんな↓感じですかね (ここまでやるか、っつー極端な例かもしれませんが)。

OPENFILENAME ofn;
…
BOOL bRet = GetOpenFileName(&ofn);
DWORD dwErr = GetLastError();
if(dwErr==ERROR_INVALID_PARAMETER){
//想定外。プログラム側の問題 (だと思う)。
}
else if(dwErr==ERROR_OUTOFMEMORY){
//メモリ不足。
}
else if(dwErr==ERROR_INSUFFICIENT_BUFFER){
//バッファが足りない。バッファをもうちょい確保して再試行する or 失敗メッセージを出す？
}
else if(bRet){
//成功。ユーザの入力したパスが正常に取得できた。
}
else{
//ユーザキャンセル。
}


ちなみに環境依存かもしれないですけど(？)、Windows Vista Home Edition の環境では、
バッファを最初から _MAX_PATH*2 確保しておくと、んまぁ一応正常動作しました。結果論ですが。

▼ もかさん
> >Patches #2002211
> コマンドラインから_MAX_PATH以上のファイル名を送ると落ちるので、
> その対策パッチを追加しておきました。

どうもありがとうございます。
ソースコードおよび動作を確認しました。

あと、私の修正の方で260バイト目がSJISの1バイト目だった時にエラーとならないことがあったので修正しました。

Windows98はちょっと動作が違うようで本修正が有効に働きませんでした。
異常終了しないような感じなので、取りあえずはそのままです (^^;