Access VBAでGetOpenFileNameなどのWindows APIを使いファイル選択ダイアログを表示する処理は、32bit環境では問題なく動作していても、64bit対応（PtrSafe追加）後にエラーや無反応になるケースがあります。本記事では、64bit対応後にダイアログが開かなくなる原因と、修正すべきポイントを整理して解説します。
64bit対応で起こる典型的な問題
PtrSafeを付けただけでは64bit対応は完了しません。特に多いのが、宣言の型とポインタサイズの不一致です。
Access VBAではLong型が32bit固定であるため、64bit環境ではポインタを扱うAPIで不整合が発生し、ダイアログが正常に表示されないことがあります。
今回のように「開かない」「エラーが出る」症状はこの典型例です。
最も重要な修正ポイント（LongPtrへの変更）
64bit対応で最も重要なのは、Long型をLongPtrに修正することです。
特に以下のようなメンバは必ず見直しが必要です。
・hwndOwner
・hInstance
・lpstrCustomFilter
・lpfnHook
・ポインタ系のLong宣言
これらがLongのままだと、64bit環境でメモリアドレスが正しく扱えず、API呼び出しが失敗します。
OPENFILENAME構造体の修正ポイント
提示コードではOPENFILENAME構造体の多くがLong型になっていますが、ここも修正対象です。
64bit環境では以下のように修正する必要があります。
・Long → LongPtrへ変更（ポインタ系）
・String型の扱い確認（バッファ指定が必要）
特にlpstrFileやlpstrFilter周りは、固定長バッファを確保する必要がある点にも注意が必要です。
PtrSafeだけでは不十分な理由
PtrSafeは「64bitでもコンパイルできるようにする宣言」にすぎず、型の互換性までは保証しません。
そのため、PtrSafeを追加しただけでは動作せず、内部構造のポインタ型修正が必須になります。
つまり「コンパイルは通るが動かない」状態が発生します。
安定して動作させる推奨方法（代替API）
Windows APIを直接使う方法は柔軟ですが、64bit対応のミスが起きやすいため、Application.FileDialogの利用が推奨されます。
Access標準機能であるため、32bit/64bit両対応で安定動作し、今回のような構造体定義も不要です。
特別な理由がない限りはこちらを使用する方が安全です。
まとめ
PtrSafeを追加してもファイルダイアログが開かない場合、多くはLong型のまま残っているポインタ関連の型不一致が原因です。
特にOPENFILENAME構造体の修正不足が典型的なエラー要因になります。
より安定した実装としてはApplication.FileDialogの利用も有効な選択肢です。
コメント