掲載 2001年4月24日/最終更新 2005年8月6日
tGetFile SDK はアプリケーションプログラムを tGetFile.dll に対応にさせ、 Pocket PC で 任意のファイルを選択するためのファイルオープンダイアログが 開くようにするのに必要となる開発キット(SDK)です。 本ページでは tGetFile.dll のサポート方法等について記述します。
![]() |
| tGetFile のファイルダイアログ |
![]() |
| tGetFile のフォルダダイアログ |
アプリケーションプログラムを、 tGetFile.dll 対応にするには、この tGetFile SDK が必要となります。 tGetFile SDK はヘッダファイル(tgetfile.h)と ライブラリ(tgetfile.lib)から構成されてます。
アプリケーションプログラムがすでに GetOpenFileName() や GetSaveFileName() API を利用してファイルを開くように 作られている場合は、 tGetFile SDK を利用するのは非常に簡単です。 GetOpenFileName() の代わりに tGetOpenFileName() を、 GetSaveFileName() の代わりに tGetSaveFileName() を利用すれば良いのです。 つまり、GetOpenFileName()やGetSaveFileName()の 先頭に、小文字の t をつければ良いだけです。
tGetOpenFileName() や tGetSaveFileName() では、アプリケーションプログラムが実行されている CE マシン上に tGetFile.dll がインストールされていなければ従来通りの GetOpenFileName() や GetSaveFileName() の ダイアログを開き、 tGetFile.dll がインストールされていれば tGetFile.dll の ファイルダイアログを開きます (Smartphone ではファイルダイアログがまったく提供されていないので何も起こりません)。
tgetfile.h の内容は、非常にシンプルで、 実質的には以下の 2 行が定義されているのみです。
BOOL tGetOpenFileName(OPENFILENAME *); BOOL tGetSaveFileName(OPENFILENAME *);
tgetfile.h では上記のように OPENFILENAME 構造体を引用しておりますので、 tgetfile.h をインクルードする前に commdlg.h のインクルードが必要になります。 (Smartphone の SDK には commdlg.h が存在しませんので、 代わりに tgetdlg.h をご利用ください)。
したがって、tGetFile.dll を利用するソースコードでは下記のような インクルード文が必要となります。
#include <commdlg.h> #include "tgetfile.h"
Smartphone の場合は以下になります。
#include "tgetdlg.h" #include "tgetfile.h"
すでにアプリケーションプログラムが GetOpenFileName() や GetSaveFileName() を利用している場合は、 commdlg.h はインクルードされているはずなので、 そのインクルード文の下に tgetfile.h のインクルード文を挿入すればいいわけです。
なお、tGetFile.dll の現行バージョンは GetOpenFileName() や GetSaveFileName() で良く使われる機能しかサポートしておりません(次項を参照ください)。 ご利用に当たっては、現行バージョンの tGetFile.dll に必要な機能が組み込まれているかどうかを十分確認してから ご利用ください。
tGetFile.dll が提供する tGetOpenFileName() および tGetSaveFileName() はそれぞれ OPENFILENAME 構造体型データへのポインタをの唯一の引数としてとる関数です。 ここでは、渡される OPENFILENAME 構造体の中でどのメンバフィールドが tGetFile.dll でサポートされているかについて記述します。
なお、GetOpenFileName() や GetSaveFileName() では、 エラーリターンしたときに、 CommDlgExtendedError() で何が悪いかを調べることができますが、 tGetOpenFileName() や tGetSaveFileName() では CommDlgExtendedError() でエラー情報が返りませんのでご注意ください。
OPENFILENAME 構造体は下記のように定義されております。
typedef struct tagOFN {
DWORD lStructSize;
HWND hwndOwner;
HINSTANCE hInstance;
LPCTSTR lpstrFilter;
LPTSTR lpstrCustomFilter;
DWORD nMaxCustFilter;
DWORD nFilterIndex;
LPTSTR lpstrFile;
DWORD nMaxFile;
LPTSTR lpstrFileTitle;
DWORD nMaxFileTitle;
LPCTSTR lpstrInitialDir;
LPCTSTR lpstrTitle;
DWORD Flags;
WORD nFileOffset;
WORD nFileExtension;
LPCTSTR lpstrDefExt;
DWORD lCustData;
LPOFNHOOKPROC lpfnHook;
LPCTSTR lpTemplateName;
} OPENFILENAME;
上記のメンバフィールドのサポート状況について説明します。
「○」や「△」のみがサポートされています。「×」は恐らく将来もサポートされません。 空欄はサポートを検討中です。
| フィールド | サポート | 備考 |
| lStructSize | △ | 参照していませんが、特に問題にはならないと思います |
| hwndOwner | ○ | |
| hInstance | △ | 参照していませんが、CE では使っていませんので問題にならないと思います |
| lpstrFilter | ○ | |
| lpstrCustomFilter | × | 元々CEではサポートされてません |
| nMaxCustFilter | × | |
| nFilterIndex | ○ | |
| lpstrFile | ○ | オンラインマニュアルには、「長さが足りなかった場合は必要な長さを先頭の 2 バイトに返す」とありましたので、バッファ長が足りない場合は、 バッファの先頭の TCHAR データ領域に、必要となる長さを入れ、 エラーリターンするようにしています。 なお、CE 標準の GetOpenFileName() では、 その場合はファイルダイアログ自身がエラーを出しリターンしないようです。 |
| nMaxFile | ○ | |
| lpstrFileTitle | ○ | v3.0にてサポート |
| nMaxFileTitle | ○ | |
| lpstrInitialDir | ○ | |
| lpstrTitle | ○ | |
| Flags | △ | 次項を参照ください |
| nFileOffset | 将来サポート予定です | |
| nFileExtension | 将来サポート予定です | |
| lpstrDefExt | ○ |
取りあつかいが多少 CE の標準と違っている気もします。「標準と違う」などのご意見がありましたら
宛にメールをいただけますよう願います。
|
| lCustData | × | 元々CEではサポートされてません |
| lpfnHook | × | |
| lpTemplateName | × |
「○」のみがサポートされています。「×」は恐らく将来もサポートされません。 空欄はサポートを検討中です。
| フラグ | サポート | 備考 |
| OFN_ALLOWMULTISELECT | × | 元々CEではサポートされてません |
| OFN_CREATEPROMPT | ||
| OFN_ENABLEHOOK | × | 元々CEではサポートされてません |
| OFN_ENABLESIZING | × | |
| OFN_ENABLETEMPLATE | × | |
| OFN_ENABLETEMPLATEHANDLE | × | |
| OFN_EXPLORER | × | CEでは無視されます |
| OFN_EXTENSIONDIFFERENT | ||
| OFN_FILEMUSTEXIST | ○ | |
| OFN_HIDEREADONLY | ||
| OFN_LONGNAMES | × | CEでは無視されます |
| OFN_NOCHANGEDIR | × | 元々CEではサポートされてません |
| OFN_NODEREFERENCELINKS | ○ | v3.0 にてサポート |
| OFN_NOLONGNAMES | * | 元々CEではサポートされてません。 tGetOpenFileName() はこのフラグを別の意味に用います。 このフラグが指定されていた場合はファイルオープンダイアログに 「名前」ボックスが表示されません。この機能は v4.0 で導入されました。 OFN_NOLONGNAMES の代わりに、別名の OFN_NONAMEBOX を利用しても結構です。 |
| OFN_NONETWORKBUTTON | × | 元々CEではサポートされてません。 |
| OFN_NOREADONLYRETURN | × | |
| OFN_NOTESTFILECREATE | × | |
| OFN_NOVALIDATE | × | CEでは無視されます |
| OFN_OVERWRITEPROMPT | ○ | Palm-size PC 版 dll では、標準ファイルダイアログと同様、 このフラグは無視されます。 |
| OFN_PATHMUSTEXIST | ||
| OFN_PROJECT | ○ | v3.0 にてサポート |
| OFN_PROPERTY | ||
| OFN_SHOW_ALL | tGetFile.dll では意味をなさないので無視されます。 | |
| OFN_READONLY | × | 元々CEではサポートされてません |
| OFN_SHAREAWARE | × | |
| OFN_SHOWHELP | × |
.NET CF からの tGetFile.dll の呼び出し用に tGetFile.dll v4.1 から 2 つの関数をエクスポートしています。
それぞれの関数は以下の構文により tGetFile.dll よりインポートしてご利用ください。
i1, i2, i3 には 0 を指定し、p1 には OPENFILENAME 構造体を Marshal.StructureToPtr した結果を指定してください。
注: 上記 API は tGetFile.dll の v4.1 以降 でのみサポートされます。
tGetFile SDK はシェアウェアです。 使用条件等は添付ファイルに記述してありますので あらかじめお読みいただいた上でご利用ください。
tgetfile.lib を EVT 3.0 で利用する場合においては、従来の tGetFile SDK 3.0 を引き続きご利用いただけます。tgetfile.lib と tGetFile.dll 間のインタフェースの変更はございませんので安心してご利 用を続けてください。
お知らせ
までご連絡ください。
tGetFile SDK 正式版は以下のようにライセンスされます。
通常版。tGetFile SDK 試用版で出ていた試用版メッセージが出ない tgetfile.lib が提供されます。 tGetFile SDK を利用する開発者一人当たり 1 ライセンスが必要となります。
Standard Edition で提供されるライセンスに加えて、 tGetFile.dll の最新版を、dll を zip でアー カイブした形態で購入後少なくとも 1 年間はお渡ししていきます。 Professional Edition をご購入すると、 この dll の継続的配布権が得られます。 それにより tgetfile.dll を自身の製品の一部として、 製品に完全に統合した形で配布することができます。 ソフトウェア製品の配布を行なう組織毎に 1 ライセンスが必要となります。
Standard Edition と Professional Edition とではライセンスの数え方が 若干異なりますのでご注意願います (なお、Professional Edition には Standard Edition が 1 ライセンス含まれます)。 また、それぞれを組み合わせて購入いただくことも可能です。 例えば、ソフトウェア製品を開発/販売する組織に、 tGetFile SDK を利用する開発者が 10 人おり、 tGetFile.dll の dll も製品に統合して配布する場合は、 Professional Edition が 1 本と、Standard Edition が 9 本必要となります。
それぞれの価格は以下のようになります。
| ライセンス | 価格 | ご購入はこちらから |
| tGetFile SDK Standard Edition | $29.99 |
|
| tGetFile SDK Professional Edition | $159.99 |
|
Standard Edition および Professional Edition のいずれについてもサポー トは含まれておりません。サポートが必要な場合は別途下記アドレスまでお問 い合わせ願います。
tGetFile.dll の変更履歴については tGetFile.dll のページ をご参照ください。
4.3 2005.8.6 DLL の変更のみで SDK には変更なし