• [アーティクル]

June 2009

Volume 24 Number 06

Windows 7 徹底解剖 - ライブラリの紹介

Yochay Kiriaty | June 2009

ここでは、以下について説明します。

  • Windows 7
  • ライブラリ
  • コモン ファイル ダイアログ
  • シェル プログラミング モデル
 この記事では、次のテクノロジを使用しています。
Windows 7

この記事は、Windows 7 のプレリリース版を基にしています。ここに記載されている情報は変更される可能性があります。

目次

Windows 7 のユーザーにライブラリがもたらす意味
ライブラリに対応したアプリケーション
コモン ファイル ダイアログを使用する
フォルダに似たライブラリを選択および使用する
シェル プログラミング モデル
シェル プログラミング モデルを使用する
新しい IShellLibrary API を使用する
内部ライブラリ
完全なライブラリ モデルのサポート
まとめ

この記事は、Windows 7 に関する連載の第 1 回です。このシリーズでは、Windows 7 でアプリケーションを洗練されたものにするために利用できる新しいユーザー エクスペリエンスを中心に説明します。この記事 (第 1 部) のテーマは、ライブラリと呼ばれる Windows 7 の新しいユーザー プロファイル ストレージの概念です。Windows 7 製品候補 (RC) 版をダウンロードして、この記事を有効に活用してください。

Windows 7 のユーザーにライブラリがもたらす意味

Windows 7 ライブラリ API の使用を開始する前に、Windows 7 でライブラリが導入された理由と、ライブラリによってコンテンツ管理のユーザー エクスペリエンスがどのように向上するかということに対する理解を深めておく必要があります。Windows 7 のライブラリの概念に対する理解を深めるには、時間をさかのぼってふりかえる必要があります。Windows Vista や Windows XP など、以前のバージョンの Windows には、マイ ドキュメントのようにユーザー コンテンツを保存するための一連の特殊フォルダが用意されていました。Windows XP では、アプリケーションが頻繁に使用する特殊フォルダを識別するために、システム非依存の方法による一意の値の一覧、CSIDL (Constant Special Item ID List) を使用していましたが、これらのフォルダの名前や場所はシステム間で統一されていません。

Windows Vista の時代になると、CSIDL は Known Folder ID (既知のフォルダ ID) と呼ばれる新しいストレージ システムに進化しました。Windows Vista では、CSIDL 特殊フォルダは一連の GUID 値によって参照されます。CSIDL システムは下位互換性を維持するために Windows Vista および Windows 7 でもサポートされています。Known Folder ID の一覧に FOLDERID_Documents というフォルダがあります。このフォルダでは、マイ ドキュメント フォルダをユーザー ストレージ プロファイルの一部として表し、FOLDERID_Fonts をシステムの特殊フォルダの一部として表します。Windows 7 では、Known Folder ID の一覧が拡張され、Windows 7 ライブラリもサポートされています。この一覧には、ドキュメント ライブラリを表す FOLDERID_DocumentsLibrary などの GUID があります。Windows Vista では、これらの特殊フォルダには自動的にインデックスが作成され、ユーザーがより高速かつ効率的にコンテンツを検索できるようになっています。ところが、多くのユーザーはファイルをコンピュータ上のさまざまな場所 ("特殊な" ユーザー プロファイル フォルダに限らず、c:\My Temp フォルダ、d:\Birthday2008\pictures、あるいはリモート ストレージなどのさまざまなフォルダ) に保存していることがわかりました。ユーザー プロファイル ストレージ領域の外部にファイルを保存すると、インデックスの作成に影響し、ユーザーの検索操作に時間がかかるようになります。ほんの数日前に使用したファイルの保存場所を忘れて検索したら、ファイルのインデックスが作成されていなかったために検索に失敗したということも珍しくありません。

Windows 7 のライブラリの概念は、ドキュメント ライブラリのフォルダ構造をユーザーが完全に制御できるようになったために、ユーザーがコンテンツをコンピュータのあらゆる場所に保存するという問題に対処することを目指しています。つまり、Windows 7 のユーザーはドキュメント ライブラリに含めるフォルダを定義できます。ユーザーは、Windows 7 のすべてのライブラリに含めるフォルダを定義できます。ライブラリは、ユーザー コンテンツを論理的に表すフォルダのユーザー定義コレクションであると言えます。フォルダをライブラリに含めることによって、ユーザーは重要なデータが存在する場所を Windows に通知します。これらのフォルダのインデックスが作成されて検索が高速化し、Windows エクスプローラで、ファイル プロパティおよびメタデータに基づいてより高度な表示レイアウト機能を利用できるようになります。図 1 では、複数のフォルダを 1 つのライブラリ ビューに統合し、Windows 7 のエクスプローラで高度な検索機能とピボット表示機能を表示しています。

fig01.gif

図 1 複数のフォルダを 1 つのライブラリ ビューに統合した場合

ライブラリは Windows シェルに組み込まれています。ファイルをフォルダ内にある場合と同じ方法で参照できるため、ユーザーが新しい動作を習得する必要がないという点で、この統合はきわめて重要です。ドキュメント ライブラリをクリックすると、すべてのドキュメントが特定のレイアウトで表示されます。また、ライブラリが Windows シェルに統合されていることにより、ユーザーは、写真の撮影日付、歌のジャンル、アイテムの人気度などのプロパティやメタデータを使用して、検索操作や結果のフィルタ処理を実行できます。ライブラリを使用することで、ユーザーはインデックス付けされた柔軟なファイル ストレージを利用できます。

ライブラリに対応したアプリケーション

Windows 7 のライブラリは、多くのアプリケーションで適切に動作しますが、Windows 7 のライブラリ環境を利用すると、より充実したユーザー エクスペリエンスが実現します。では、アプリケーションがライブラリをサポートしていない場合はどうするのかという疑問を持たれるかもしれません。たとえば、アプリケーションに、ファイルをディスクに保存する機能を実装する場合、アプリケーションはユーザーに対して、ファイルの保存場所を選択するオプションを表示します。ユーザーは、日頃ドキュメントを操作する場合に保存先にしているドキュメント ライブラリを保存場所として選択する可能性があります。

ところが、ドキュメント ライブラリが通常のフォルダではないことをアプリケーションが認識しなかった場合、アプリケーションは、ディスク上の別のフォルダと同様に、ファイルを直接ドキュメント ライブラリに保存しようとします。ライブラリはファイル システム以外の場所にあり、通常のフォルダとして扱うことはできないため、これが問題になります。アプリケーションは、処理対象がライブラリであることを認識する必要があります。さいわい、Windows 7 には、更新されたシェル API、ライブラリ API、および更新されたコモン ファイル ダイアログがあります。コモン ファイル ダイアログは、ライブラリを適切に処理する機能を開発者に提供します。

ライブラリ対応のアプリケーションには、ユーザーが意図せずにライブラリをフォルダと同様に扱って、ファイルをライブラリに保存しようとしたり、ライブラリのコンテンツを読み込もうとした場合に対処するメカニズムがあります。また、多くのアプリケーションで、ユーザーがアプリケーション操作の一部としてファイル システムを操作することができます。アプリケーションは、使い慣れたエントリ ポイントと UI を Windows 7 ライブラリによってユーザーに提供する必要があります。フォルダをライブラリに含めることによって、ユーザーは重要なデータの保存場所を指定して、そのデータが必要なコンテンツであることを通知します。アプリケーションでライブラリをサポートすることによって、アプリケーションはこれらの場所のレベルを上げる必要があります。

Windows 7 では、開発者向けに、アプリケーションをライブラリ対応にすることができる複数の統合ポイントがあります。開発者は次の 3 つの統合ポイントを検討し、要件に応じて選択する必要があります。

  1. 最も基本的な統合ポイントでは、コモン ファイル ダイアログ (CFD) を使用し、ユーザーが選択したファイルやフォルダをライブラリに直接保存します。
  2. 2 つ目の統合ポイントでは、アプリケーションでライブラリのコンテンツを選択および使用できるようにして、Windows 7 でアプリケーションを洗練するためのオプションをアプリケーションに提供します。
  3. 3 つ目の統合ポイントでは、完全なライブラリ プログラミング モデルをサポートするさらに高度な統合オプションを提供します。

コモン ファイル ダイアログを使用する

Windows 7 ライブラリは CFD の優良市民なので、ライブラリを参照して検索する機能をユーザーに提供できます。ライブラリ内のフォルダだけではなく、ライブラリそのものをライブラリの保存場所として選択することもできます。Windows 7 ライブラリはストレージでサポートされているため、ユーザーは権限のあるライブラリ内の任意のフォルダにファイルを保存およびコピーできます。各ライブラリには、ファイルをライブラリに直接コピーおよび保存する場合の既定の保存場所があります。既定では、この場所は既定のライブラリに含まれる既知のフォルダまたはカスタム ライブラリに追加された最初のフォルダです。

ただし (注意しなければならない点は常にあるものです)、レガシ バージョンの CFD ではなく、Windows Vista で導入された新しい CFD インターフェイスを使用することを強くお勧めします。アプリケーションの互換性の都合上、レガシ CFD を使用するための API は Windows Vista および Windows XP 以降で変更されていません。ところが、レガシ バージョンの CFD は Windows 7 のライブラリやまったく新しいユーザー エクスペリエンスを直接サポートしていません。レガシ バージョンの CFD と新しい CFD を図 2 に並べて表示します。

fig02a.gif

fig02b.gif

図 2 コモン ファイル ダイアログ ボックスの古い画面と新しい画面

レガシ CFD では、ライブラリが右のナビゲーション ウィンドウに表示されている場合でも、1 回余分にクリックして、ライブラリ自体ではなく、ライブラリに含まれているフォルダのいずれかに保存する必要があります。レガシ CFD は異なるフォルダ場所から複数のファイルを取得する機能をサポートしていないため、ユーザーは CFD 内から直接検索を行ったり、機能豊富なプレビュー ハンドラを使用したり、フォルダ間の複数のファイルを選択することはできません。これに対し、Windows 7 ライブラリはこの機能をサポートしています。

適切な API を使用して、適切なバージョンの CFD を表示することが重要です。.NET を使用して CFD を表示する場合、開発者は System.Windows.Forms.FileDialog または Microsoft.Win32.FileDialog 名前空間を使用できます。Microsoft.Win32.FileDialog 名前空間ではレガシ バージョンの CFD を使用するため、.NET 開発者は必ず WinForms 名前空間を使用して新しい CFD を表示する必要があります。図 3 のコード例では、共通のファイル保存ダイアログを表示してユーザーがフォルダまたはライブラリを選択できるようにし、ユーザーに保存場所の選択を要求しています。

図 3 SaveFileDialog ファイル

System.Windows.Forms.SaveFileDialog _fd = new System.Windows.Forms.  SaveFileDialog();
_fd.Title = "Please choose a location to save your file";
_fd.FileName = "[Get Folder…]";
_fd.Filter = "Library|no.files";
if (_fd.ShowDialog() == System.Windows.Forms.DialogResult.OK)
{
    string dir_path = System.IO.Path.GetDirectoryName(_fd.FileName);
    if (dir_path != null && dir_path.Length > 0)
    { 
        lblResult.Content = dir_path; 
    }
}

ネイティブ コードの開発者は、IFileDialog ネイティブ API の新しいファミリ (IFileDialog、IFileOpenDialog、IFileSaveDialog、IFileDialogCustomize、IFileDialogEvents、IFileDialogControlEvents) を使用する必要があります。これらの API は、以前のバージョンの Windows のレガシ API (GetOpenFileName および GetSaveFileName) に代わるものです。

図 4 に、IFileDialog ネイティブ API の新しいファミリを使用してユーザーに保存ダイアログを表示し、フォルダまたはライブラリの保存を要求する方法を示します。

図 4 IFileDialog ネイティブ API

*ppsi = NULL;
IFileSaveDialog *pfod;
hr = CoCreateInstance(
CLSID_FileSaveDialog, 
NULL, 
CLSCTX_INPROC, 
IID_PPV_ARGS(&pfod));
if (SUCCEEDED(hr))
{
  hr = pfod->SetOptions(FOS_PICKFOLDERS);
  if (SUCCEEDED(hr))
  {
  hr = pfod->Show(hWndParent);
           if (SUCCEEDED(hr))
           {
           hr = pfod->GetResult(ppsi);
           }
    }
    pfod->Release();
}

シェル ネイティブ API は COM に基づいています。COM オブジェクトを使用する前に、CoCreateInstance を呼び出して、COM オブジェクトを初期化する必要があります。*pfod IFileSaveDialog 変数を初期化し、IFileOpenDialog.SetOptions() に FOS_PICKFOLDERS フラグを渡して、フォルダを選択するダイアログ オプションを設定します。このコードは、ユーザーがファイルではなくフォルダを選択できるようにし、ライブラリを保存先として選択できるようにすることを [ファイルを開く] ダイアログ ボックスに通知します。ライブラリを選択する場合、CFD は選択したライブラリに関連付けられた既定の保存場所フォルダを返します。

図 3 と図 4 はきわめて単純で、新しいコードの追加もありません。それでも、Windows 7 で実行するアプリケーション間の一貫性を高め、Windows 7 ライブラリをサポートすることが重要です。CFD は、新しい Windows エクスプローラでのライブラリなどの操作性を統一することを目的にしています。Windows 7 エクスプローラのすべての機能拡張が CFD に引き継がれています。CFD は、多くの場合に、ユーザーがアプリケーションからライブラリを参照して操作するのに最適な方法です。

フォルダに似たライブラリを選択および使用する

ユーザーに対してピクチャーを表示するスライドショー アプリケーションの場合を考えてみましょう。ライブラリを使用して、ユーザーは重要な画像が画像ライブラリに保存されていることをシステムに通知します。アプリケーションは画像ライブラリを直接参照して、画像のコレクション全体をユーザーに表示することができます。また、開発者は、ライブラリ システムを使用して、たとえば、画像の個別の構成ファイルやデータベースを維持する必要をなくすことができます。シェル ライブラリのプログラミング API を使用する前に、シェル プログラミング モデルに関するいくつかの概念を理解する必要があります。

シェル プログラミング モデル

一般にアイテムと呼ばれるシェル項目 (IShellItem) は、シェルの UI の表現手段であり、プログラミング モデルです。アイテムは、個別の自己完結型コンテンツ ソースです。たとえば、CFD の制御に使用するインターフェイス メソッドの中で、ファイル システム パスではなくシェル項目を使用してフォルダを参照しているものはごくわずかです。CFD はファイル システム フォルダおよびその他の仮想フォルダ (コントロール パネルや [Computer] (コンピューター) フォルダなど) に関する情報をやりとりできるため、これは重要なことです。

その他の重要なシェルの COM インターフェイスを以下に示します。

  • 通常、ファイル、フォルダ、または実行可能ファイルへのリンクを表す IShellLink インターフェイス
  • シェル名前空間からのシェル フォルダ オブジェクトを表す IShellFolder インターフェイス。IShellFolder を使用して、フォルダのコンテンツのスキャン、フォルダ内のアイテムの表示名の取得、フォルダに相対的な表示名の解析、アイテム ID 一覧の取得を行うことができます。

Windows 7 では IShellLibrary という名前の新しいシェル API が導入されました。この API を使用して、IShellItem からクエリを行い、Windows 7 のライブラリを操作し、サポートすることができます。

例では、シェル プログラミング モデルのさまざまなコンポーネントを定義しているので、ライブラリがこのモデルにどのように組み込まれているかを確認できます。ライブラリはファイル システムの場所ではないため、FindFirstFile などのファイル システム固有の API は使用できません。代わりに、ライブラリのコンテンツを使用するための 2 つの主なオプションがあります。

シェル プログラミング モデルを使用する

IShellItem インターフェイス、IShellFolder インターフェイス、およびさまざまなヘルパ関数を使用して、通常のフォルダと同様の方法でライブラリのコンテンツを列挙できます。これにより、アプリケーションは新しいライブラリ API を使用しなくてもライブラリのコンテンツを使用できます。既存のコードベースの変更もごくわずかで済みます。

図 5 に、IShellFolder インターフェイスを使用して画像ライブラリのコンテンツ全体を列挙する方法を示します。

図 5 IShellFolder インターフェイス

IShellItem *psi;
HRESULT hr =  SHGetKnownFolderItem(FOLDERID_PicturesLibrary, KF_FLAG_CREATE, NULL, IID_PPV_ARGS(&psi));
if(SUCCEEDED(hr))
{
    IShellFolder *psf;
    hr = psi->BindToHandler(NULL, BHID_SFObject | , IID_PPV_ARGS(&psf));
    if(SUCCEEDED(hr))
         {
               IEnumIDList *penumIDList;
               psf->EnumObjects(NULL, SHCONTF_FOLDERS | SHCONTF_NONFOLDERS , IID_PPV_ARGS(&penumIDList));
               //use penumIDList to enumerate the content of the folder
          }
}

ここでは、ライブラリの正しい場所が取得されることを確認するために、ヘルパ関数 SHGetKnownFolderItem に FOLDERID_PicturesLibrary を渡します。FOLDERID_PicturesLibrary は、既知のフォルダ (この場合は画像ライブラリ) を表す GUID です。この関数の呼び出しに成功すると、シェル項目として表されるライブラリの適切な情報が IShellItem *psi インターフェイスに設定されます。残りのコードは、BindToHandler を使用して、以前に取得した Shell アイテムを Shell フォルダにバインド (キャスト) する標準的なシェル プログラミングです。次に、シェル フォルダ内の別のアイテムを列挙処理します。ライブラリの場合はファイルまたはフォルダです。SHGetKnownFolderItem はシェル ヘルパ関数であり、Windows 7 RC SDK の shlobj.h ヘッダー ファイルにある、より大きいヘルパ関数のグループに属します。SHCONTF_FOLDERS | SHCONTF_NONFOLDERS フラグを渡していることに注意してください。このフラグは、ライブラリ内のすべてのファイルとフォルダを取得する必要があることをシェル フォルダに通知しています。ここでは、SHCONTF_NAVIGATION_ENUM を渡して、ライブラリのコンテンツではなく、ライブラリの場所を取得しています。

新しい IShellLibrary API を使用する

図 5 と同じ機能を、図 6 のように新しい Windows 7 の IShellLibrary API を使用して実装することもできます。

図 6 IShellLibrary API

IShellLibrary *pslLibrary;
HRESULT hr = SHLoadLibraryFromKnownFolder(FOLDERID_PicturesLibrary, STGM_READ, IID_PPV_ARGS(&pslLibrary));
if(SUCCEEDED(hr))
{
       IShellItemArray *psiaFolders;
       hr = pslLibrary->GetFolders(LFF_STORAGEITEMS, IID_PPV_ARGS(&psiaFolders)); 
       IEnumShellItems *penumShellItems;
       psiaFolders->EnumItems(&penumShellItems);
       //work with penumShellItem to enumerate the items in the library
}

ご覧のように、ここでは別のヘルパ関数 SHLoadLibraryFromKnownFolder を使用して IShellLibrary オブジェクトを作成しています。このオブジェクトから GetFolders メソッドを呼び出して、IShellitemArray を取得できます。この返却値を後で列挙子の取得に使用して、ライブラリのコンテンツ全体をスキャンします。

最後の例では、ヘルパ関数 SHLoadLibraryFromKnowFolder を使用しています。前述したように、このヘルパ関数および Windows 7 ライブラリに関連するその他のヘルパ関数は、Windows 7 RC SDK の shlobj.h ヘッダー ファイルにあります。ライブラリの重要なヘルパ関数を以下に示します。

  • SHAddFolderPathToLibrary (ライブラリにフォルダを追加する)
  • SHCreateLibrary (IShellLibrary オブジェクトを作成する)
  • SHLoadLibraryFromItem (指定したライブラリ定義ファイルから IShellLibrary オブジェクトを作成して読み込む)
  • SHLoadLibraryFromKnownFolder (指定した KNOWNFOLDERID から IShellLibrary オブジェクトを作成して読み込む)
  • SHLoadLibraryFromParsingName (指定したパスの IShellLibrary オブジェクトを作成して読み込む)
  • SHRemoveFolderPathFromLibrary (フォルダをライブラリから削除する)
  • SHResolveFolderPathInLibrary (移動された、または名前が変更されたライブラリ フォルダのターゲットの場所の解決を試行する)
  • SHSaveLibraryInFolderPath (IShellLibrary オブジェクトをディスクに保存する)

図 7 のコードをご覧ください。このコードでは、これらのヘルパ関数のいくつかを使用して、新しいライブラリを作成し、フォルダをそのライブラリに関連付けて、Libraries フォルダにライブラリを保存しています。

図 7 SHCreateLibrary ヘルパ関数を使用した IShellLibrary

IShellLibrary *pIShelLibrary;
HRESULT hr = SHCreateLibrary(IID_PPV_ARGS(&pIShelLibrary));
if (SUCCEEDED(hr))
{
      IShellItem *pIShellItem;
      SHAddFolderPathToLibrary(pIShelLibrary, L"C:\\Users\\Public\\Documents");
      hr = pIShelLibrary->SaveInKnownFolder(FOLDERID_Libraries, L"My New Library", LSF_MAKEUNIQUENAME, 
            &pIShellItem);
      pIShellItem->Release();
      pIShelLibrary->Release();
}

ここでは、SHCreateLibrary ヘルパ関数を使用して、新しい IShellLibrary オブジェクトを作成しています。次に、パブリック フォルダ Documents を Library オブジェクトに追加します。新しいライブラリを他のライブラリと共に Libraries フォルダに保存し、My New Library という名前を付けます。

図 7 では、IShellLibrary インターフェイスの SaveInKnownFolder メソッドを使用して、作成した新しいライブラリを保存します。IShellLibrary インターフェイスの多くのメソッドにはわかりやすい名前が付いていますが、特に注意を要するメソッドを確認しておきましょう。

  • Commit メソッドは、ライブラリの変更を既存のライブラリ ファイルにコミットします。変更を保存するには、プログラムでライブラリを変更するたびに Commit メソッドを呼び出す必要があります。
  • SetIcon メソッドは、リソース DLL の名前とアイコンのインデックスを受け取って、ライブラリのアイコンを設定します。
  • SetFolderType は既知の "フォルダの種類" テンプレートを入力パラメータとして受け取ります。この GUID は、ライブラリの種類を定義します。ライブラリの種類は、Generic (汎用)、Pictures (画像)、Music (音楽)、Video (ビデオ)、Documents (ドキュメント) のいずれかです。フォルダの種類テンプレートを設定すると、Windows エクスプローラのライブラリの表示が変更され、ライブラリの種類に固有の検索およびピボット表示オプションが有効になります。

内部ライブラリ

図 7 のコードでは、新しいライブラリ ファイルを Libraries フォルダに作成しています。Windows 7 のライブラリは、ファイル拡張子が .library-ms の XML 定義ファイル形式で保存されます。ファイル名はライブラリの名前です。たとえば、ドキュメント ライブラリは Documents.library-ms という名前の XML ファイルで表されます。ライブラリの説明はディスク上の %appdata%\Microsoft\Windows\Libraries フォルダ (FOLDERID_Libraries とも呼ばれる) に保存されます。

次に、ドキュメント ライブラリ定義ファイルのスキーマについて説明します。XML の構造はきわめてわかりやすいものですが、その要素のいくつかについて説明します。図 8 に示すように、ファイルの冒頭にライブラリのヘッダー情報が記述されます。

図 8 ドキュメント ライブラリ定義ファイルのスキーマ

<libraryDescription xmlns="https://schemas.microsoft.com/windows/2009/  library">
  <name>@shell32.dll,-34575</name>
  <ownerSID>S-1-5-21-2127521184-1604012920-1887927527-4897363</ownerSID>
  <version>4</version>
  <isLibraryPinned>true</isLibraryPinned>
  <iconReference>imageres.dll,-1002</iconReference>
  <templateInfo>
    <folderType>{7D49D726-3C21-4F05-99AA-FDC2C9474656}</folderType>
  </templateInfo>

ルート XML 要素は libraryDescription です。この要素に、ライブラリを定義する次のような子要素が含まれます。

  • <ownerSID> は、このライブラリを作成したユーザーのセキュリティ ID を定義してライブラリを隔離し、ユーザー データを他のユーザーから保護します。
  • <isLibraryPinned> は、ライブラリをタスク バーではなく Windows エクスプローラの左側のナビゲーション ウィンドウに固定するかどうかを定義するブール型の要素です。
  • <version> は、このライブラリのコンテンツのバージョンを定義します。この要素には、ライブラリ定義ファイルが変更された回数が反映されます。
  • <templateInfo> は省略可能なコンテナ要素です。この要素では、作成者がフォルダの種類 (ドキュメント、画像、ビデオ) を指定して、Windows エクスプローラでの表示レイアウトを制御することができます。
  • <iconReference> は、標準の Windows シェル リソースのスタイルを使用してアイコン リソースを定義します。たとえば、次のような形になります。

<iconReference> C:\Windows\system32\imageres.dll,-65 </iconReference>

このアイコンは Windows エクスプローラのライブラリを表します。

ユーザーは既定のライブラリ アイコンを Windows エクスプローラで変更したり、ライブラリ アイコンを新しいカスタマイズされたユーザー定義ライブラリに割り当てることはできません。これらの操作は、API を使用してプログラムで行うことができます。これについては、この連載の今後の記事で説明する予定です。

この XML の重要な部分は、ライブラリが表す場所の一覧です。そのコードを次に示します。

<searchConnectorDescriptionList>
    <searchConnectorDescription publisher="Microsoft" product="Windows">
      <description>@shell32.dll,-34577</description>
      <isDefaultSaveLocation>true</isDefaultSaveLocation>
      <isSupported>true</isSupported>
      <simpleLocation>
        <url>knownfolder:{FDD39AD0-238F-46AF-ADB4-6C85480369C7}</url>
      <serialized>MBAAAE…. </serialized>
      </simpleLocation>
    </searchConnectorDescription>
  • <searchConnectorDescriptionList> には、ライブラリに含まれる物理的な場所にマップする 1 つまたは複数のコネクタが含まれます。
  • <searchConnectorDescription> には、ライブラリに含まれる 1 つの場所を示す simpleLocation 要素が含まれます。
  • <url> は、この場所の URL を定義します。読みやすくすることだけを目的としています。情報が古くなる可能性があるため、開発者はこの要素を使用できません。
  • <serialized> は、シリアル化された ShellLink オブジェクトであるライブラリの場所を実際に表します。

最後に 1 つ、注意を要する点があります。アプリケーションで、ライブラリ記述ファイルへのアクセスや編集を試行しないでください。代わりに、アプリケーションでライブラリのコンテンツを使用および操作する場合は、必ずシェル プログラミング モデルまたは IShellLibrary API を使用してください。

完全なライブラリ モデルのサポート

ユーザーは、ライブラリ管理の UI で、場所の追加、削除、並べ替え、および既定の保存場所の変更を行うことができます。この UI を図 9 に示します。この画面は、Windows エクスプローラから直接表示できます。

fig09.gif

図 9 ライブラリ管理の UI

ライブラリの場所は IShellLibrary インターフェイスで変更することもできます。ライブラリ構造の変更はライブラリ定義ファイルに反映され、基になる .library-ms ファイルに直接保存されます。.library-ms ファイルの変更を監視することによって、このような変更の通知を受けることができます。アプリケーションがライブラリのコンテンツを使用している場合や、現在、アプリケーションに特定のライブラリのコンテンツが表示されている場合などに、ライブラリのコンテンツの変更が通知されるようになっていると便利です。アプリケーションがライブラリ定義ファイルの変更通知を受けるには、ネイティブの SHChangeNotifyRegister シェル ヘルパ関数を使用するか、System.IO 名前空間のマネージ FileSystemWatcher を使用します。これらのインターフェイスは新しい API ではなく、ドキュメントも完備しているため、使い方の説明はこの記事では省略します。

もう 1 つ、検討に値するオプションは、画像リポジトリに画像の新しいフォルダを追加するなど、アプリケーションでユーザーのフォルダを管理する必要がある場合です。画像ライブラリを使用している場合、Windows 7 でユーザーがライブラリ管理に使用するダイアログと同様のダイアログを、アプリケーションでライブラリ管理ダイアログを使用して表示できます。この機能を利用すると、外観と動作が統一されるため、ユーザーの評価も高くなります。ライブラリ管理ダイアログのインターフェイスを使用する場合、ライブラリの変更は、ライブラリのコンテンツを直接 Windows エクスプローラで変更する場合と同様に行われます。このダイアログはアプリケーションに情報を返しません。特定のライブラリのコンテンツを表示する場合、前述のように、通知を登録して更新を受け取るようにする必要があります。

まとめ

この記事では、Windows 7 のライブラリの概念とプログラミング モデルについて説明しました。Windows 7 のユーザー エクスペリエンスの一部として機能するライブラリの重要な役割も紹介しました。また、ライブラリの説明を掘り下げてライブラリの概念についての理解を深め、その基盤となるアーキテクチャについても説明しました。開発者がアプリケーションをライブラリ対応にするためのさまざまな可能性についても説明しました。また、使用可能な各種のプログラミング モデルおよび API の概要も紹介しました。

Yochay Kiriaty は、Windows 7 を得意とする Microsoft のテクニカル エバンジェリストです。ソフトウェア開発の分野で 10 年以上の経験があります。学術的なコンピュータ サイエンスの講座に関する著作や講義を行い、Windows に関するブログへの積極的な寄稿者でもあります。

Alon Fliess は Sela Group の CTO です。Sela は、IT トレーニングの分野で 18 年の実績を誇り、高度な IT 関連の人材育成を実施するイスラエルの代表的企業として認知されています。Alon はコンピュータ テクノロジに造詣が深く、Technion (Israel Institute of Technology) で電気およびコンピュータ エンジニアリングの理学士の学位を取得しています。過去 22 年間にわたってプログラミングと教育の仕事に携わり、Windows の内部、C++ Win32 のプログラミング、.Net と C# または C++/CLI をはじめとする数多くの Microsoft テクノロジのエキスパートでもあります。