윈도우 앱개발을 향하여

Understanding Shell Namespace Extensions (MSDN 번역)

윈도우 탐색기는 사용자가 Shell Object에 접근할 수 있게 도와주는 도구와 결합된 Shell namespace의 graphical representation이다. With a namespace extension, you can take any body of data and have Windows Explorer present it to the user as a virtual folder. When a user browses into this folder, your data는 tree-structured 계층의 폴더들과 파일들로 표현되어 보여집니다, much like the rest of the Shell namespace. 사용자와 application들은 다른 namespace object들과 비슷한 방법으로 가상 폴더(virtual folder)의 내용물을 사용할 수 있습니다. 이 문서는namespace extension을 생성하는 방법을 다룹니다.

목차

How a Namespace Extension Works

The Default System Folder View Object(DefView)

How Windows Explorer Interacts with a Namespace Extension

TreeView

Folder View

Menu Bar and Toolbars

Status Bar

- How a Namespace Extension Works

One way to present this kind of data to a user is to write an application to allow users to view and interact with the various items. However, if your data can be presented as a folder/file hierarchy, much of the functionality you will need to implement might be user interface services that are already provided by Windows Explorer. A much more efficient approach could be to write a namespace extension and let Windows Explorer become your GUI.

To implement a namespace extension, your information must be organized as a tree-structured namespace. Your namespace root is presented as a virtual folder in the Shell namespace. The root folder, and all its subfolders and data items, becomes part of the Shell namespace, and Windows Explorer becomes your user interface. You can thus present your information to the user in a familiar and readily accessible way with much less UI programming than would be required for a custom application.

A namespace extension consists of two basic components:

• A data manager
• An interface between the data manager and Windows Explorer

The first component on the list is entirely up to you. You can store and manage your data in whatever way is most effective. The second component is the code needed to package your data as folder objects and handle the interaction with Windows Explorer. Windows Explorer can then call these objects to allow users to view and interact with your data as if it were a collection of folders and files. Your namespace extension's folder objects must interact with Windows Explorer as if they were normal folders. Before attempting to implement a namespace extension, you must first understand how Windows Explorer handles a folder object.

- The Default System Folder View Object (DefView)

The Shell provides a default implementation of the folder view, colloquially known as DefView, so that you can avoid much of the work of implementing your own namespace extension. Because some view features cannot be achieved through custom views, it is often recommended that the default system folder view object is used in place of a custom view. For more information, see SHCreateShellFolderView.

- How Windows Explorer Interacts with a Namespace Extension

Windows Explorer provides users with a GUI that allows them to do a variety of tasks, including:

• Navigating the namespace hierarchy and viewing the contents of folders.
• Managing the contents of the namespace by moving, deleting, and copying objects.
• Retrieving a variety of information about objects.
• Launching applications.

The Windows Explorer GUI has five basic components. The following illustration names the components and shows where they are typically displayed within Windows Explorer.

When a user displays a folder that belongs to a namespace extension in Windows Explorer, the folder object has at least partial control over the contents of all five areas.

- Tree View

The tree view provides a high-level view of the namespace. This area hosts a tree view control that can display every namespace folder and the folder's position in the namespace hierarchy. A user can perform several operations with the tree view area, including:

• Displaying or hiding the next level in the namespace.
• Copying, moving, or deleting folders.
• Right-clicking a folder to display a shortcut menu.
• Selecting a folder and viewing its contents in the folder view.

The tree view communicates with folder objects primarily through their IShellFolder interface. For example, when a user clicks the plus sign (+) next to the folder's icon, Windows Explorer expands the display to show the folder's subfolders. To obtain the information needed to update the tree view, the Shell makes several calls to the folder object's IShellFolder interface to:

• Request the folder's attributes.
• Enumerate the contents of the folder.
• Request display names for each subfolder.
• Request an icon to display next to each folder.

Windows Explorer then updates the tree view to show the selected folder's subfolders. If the subfolders have subfolders, a '+' character is displayed next to their folder icon. There are a number of more sophisticated tasks that a user can also perform with the tree view, including:

• Using the Clipboard to cut or copy a folder and paste it into another folder.
• Using drag-and-drop to cut or copy a folder and drop it on another folder.
• Using a search engine to search for items in a folder or its subfolders.
• Modifying the folder's properties.

For a more detailed discussion of how a namespace extension handles these user actions, see Implementing the Basic Folder Object Interfaces.

- Folder View

When a user selects a folder, the contents of the folder are displayed in the folder view. To some extent, the normal functionality of the folder view overlaps with the tree view. Users can move or copy folders, change folder properties, view the contents of a subfolder, display a shortcut menu for a folder, and so on. However, there are some distinct differences between tree view and folder view:

• Folder view displays only the contents of a single folder, not part or all of the namespace hierarchy.
• Folder view displays file objects as well as folder objects.
• Folder view can display much more information about objects than tree view.
• Folder view allows namespace extensions to have almost complete control over what information is displayed and how. Only minor aspects of the tree view, such as folder icons, can be modified.

Unlike the tree view, Windows Explorer does not directly control the contents of the folder view. The folder view is an area that Windows Explorer provides to folder objects. Displaying and managing the contents of a folder in the folder view are the responsibility of the folder object. Although most folder views follow a fairly standard format, there are actually few limitations on what can be displayed or how. An extreme case is the Internet folder, which is a full-featured browser.

When a user selects a folder that belongs to your namespace extension, you create a window and pass its handle to Windows Explorer. This window becomes a child of the folder view window. Windows Explorer provides the dimensions of the folder view window but places no restrictions on the content of your child window. You can then use the child window to display the folder's folder view.

Namespace extensions use one of two approaches for creating a folder view:

• Use your child window to host a list view control. This control allows you to display the contents of a folder in much the same way as the Windows Explorer classic view.
• Use your child window to host a WebBrowser control and use a Dynamic HTML (DHTML) document to display the contents of the folder.

Both approaches display a folder view that looks very much like that displayed for system folders. However, if you want to use a different display scheme, you are free to do so.

- Menu Bar and Toolbars

Like most Windows applications, Windows Explorer provides the user with a collection of tools. A complete selection of tools is available through the menu bar. The more commonly used tools are also represented by buttons or edit boxes on a toolbar. Unlike many Windows applications, the Windows Explorer menu bar is actually a toolbar control that has been customized to behave like a conventional menu. Both the menu bar and the toolbar are incorporated into a rebar control to allow users to organize the individual controls to suit their needs.

By default, Windows Explorer supports a standard set of buttons and menu items, such as Copy and Properties. Your namespace extension can customize the menu bar and toolbars by deleting standard tools and adding custom tools. When your folder view object is initialized, Windows Explorer passes a pointer to its IShellBrowser interface. This interface supports several methods that you can call to customize the menu bar and toolbar. When the user selects one of your custom menu items or toolbar buttons, Windows Explorer forwards WM_COMMAND messages for custom menu and toolbar items to your child window's window procedure.

- Status Bar

The Windows Explorer status bar displays information about the currently selected object. Your namespace extension can use the status bar to display status information, such as a text string. You can customize the status bar by calling IShellBrowser.

Common Explorer Concepts 

( == Introduction to the Shell Namespace) (MSDN 번역)

The Shell namespace는 쉘에 의해 관리되는 file system과 other Object들을 single tree-structured 계층으로 organizes한다. (Shell namespace는 file system보다 큰 개념이다.)

목차

Introduction

Identifying Namespace Object

Item IDs

Item ID Lists

PIDLs

Allocating PIDLs

- Introduction

쉘(Shell)의 주요 업무 중 하나는 file system을 구성하는 다양하고 방대한 object(디스크 드라이브를 차지하는 폴더들과 파일들이 대표적)들에 대한 접근을 제공 및 관리하는 것이다. 하지만 쉘은 파일시스템에 포함되지 않은 것들과 virtual object들도 관리한다. (Network Printers, Other Networked computers, Control Panel applications, The Recycle Bin 같은 것들)

어떤 virtual object들은 물리적인 storage를 가지지 않기도 한다. 

(예를 들어 The printer object  contains a collection of links to networked printers. Other virtual objects, such as the Recycle Bin, may contain data that is stored on a disk drive, but needs to be handled differently than normal files. For example, a virtual object can be used to represent data stored in a database. In terms of the namespace, the various items in the database could appear in the Windows Explorer as separate objects, even though they are all stored in a single disk file.)

Virtual object들은 심지어 다른 컴퓨터에 위치할 수도 있다.

(예를 들어 to facilitate roaming, a user's document files might be stored on a server. To give users access to their files from multiple desktop PCs, the My Documents folder on the desktop PC they are currently using will point to the server, not the hard disk of the desktop PC. Its path will include either a mapped network drive or a UNC path name.)

Namespace도 file system과 마찬가지로 폴더와 파일이라는 두개의 기본적인 타입의 object들을 포함한다. 폴더 objects는 tree의 nodes로써 다른 폴더와 파일 object들의 컨테이너다.  파일 object들은 tree의 leaves로써 평범한 디스크 파일이거나 virtual objects이다.  파일 시스템의 일부가 아닌 폴더들은 virtual folders라고도 불린다.

파일 시스템 폴더들과 마찬가지로 가상 폴더(virtual folder)들도 시스템 환경에 따라 다르다. 가상 폴더들의 세 가지 classes는...

• Standard virtual folders, such as the Recycle Bin, that are found on all systems.
• Optional virtual folders that have standard names and functionality, but may not be present on all systems.
• Non-standard folders that are installed by the user.

namespace 계층의 최상위에는 Desktop이 있고 그 바로 밑에는 My computer(내컴퓨터)와 휴지통 등과 같은 가상 폴더들이 있다. (윈도우 탐색기에서 바로 확인이 가능하다.)

다양한 디스크 드라이브들의 파일시스템들은 더 큰 namespace 계층의 일부로 보인다. 

(The roots of these file systems are subfolders of the My Computer folder. My Computer also includes the roots of any mapped network drives. Other nodes in the tree, such as My Documents, are virtual folders.)

- Identifying Namespace Objects

Namespace Object를 쓰기에 앞서 이것들을 구별하는 방법을 알아야 한다. 파일시스템의 object는 MyFile.htm과 같은 이름을 가지고 있을 수 있다. 하지만 동일한 이름의 파일이 시스템 내에 또 있을 수 있으므로 완전경로(Fully Qualified Path)("C:\MyDocs\MyFile.htm" 같은)를 요구한다. 이런 경로들은 기본적으로 파일시스템의 root인 C드라이브로부터 시작되는 모든 폴더명의 연속된 계층을 나열하고 마지막에 파일의 이름을 쓴 것이다.

하지만 완전경로는 파일시스템에 포함되있는 object들의 위치를 구별하는 데에는 유용하지만 virtual objects들에게 적용할 수 없다. 그래서 쉘은 모든 namespace object가 이용가능한 방법을 지원한다.

- Item IDs

Within a folder, each object는 item ID(which is the functional equivalent of a file or folder name)를 갖는다. Item ID는 실제로는 SHITEMID 구조체이다.

typedef struct _SHITEMID { 

USHORT cb; 

BYTE   abID[1]; 

} SHITEMID, * LPSHITEMID;

abID 멤버가 object의 구별자(identifier)이다. abID의 길이는 정해지지 않았고 그 값은 object를 포함하고 있는 폴더에 의해 결정된다. abID의 값이 폴더에 의해 결정되는 표준화된 방법이 없기 때문에 그 값들은 단지 해당 폴더 object와 함께할 때만 의미를 갖는다. Applications는 그 값들을 특정 폴더 내의 object들을 구별하는 토큰으로 취급하면 된다. Because the length of abID varies, the cb member holds the size of the SHITEMID structure, in bytes.

item ID가 display 목적으로 유용하지 않기 때문에 보통 해당 object를 포함하는 폴더가 object에게 display name을 배정한다. This is the name that is used by Windows Explorer when it displays the contents of a folder. (display names이 다루어지는 방법은 Getting Information From a Folder를 참조)

- Item ID Lists

Item ID가 그 자체로 쓰이는 경우는 별로 없고 보통은 item ID list의 일부로써 파일시스템의 경로와 동일한 목적으로 이용된다. 경로는 문자열로 이루어졌지만 item ID list는 ITEMIDLIST 구조체로 되어있다. 이 구조체는 item ID들의 연속으로 이루어지고 two-byte NULL로 끝이 난다. 

My Computer    C;/         MyDocs    MyFile.htm

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

|  cb  | abID   | cb | abID | cb | abID | cb | abID  | 2-byte NULL

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

item ID list안의 각 item ID는 namespace object와 일치한다. 그것들의 순서는 파일시스템의 경로처럼 namespace 내의 경로를 정의한다.

- PIDLs

쉘 API에서 namespace object들은 보통 ITEMIDLIST 구조체의 포인터(==Pointer to an item IDentifier List; PIDL)로 구별된다.

위 그림을 full(또는 absolute) PIDL이라고도 부를 수 있다. Full PIDL은 데스크탑부터 시작해서 중도에 있는 폴더들의 item ID를 포함하며 마지막에는 해당 object의 item ID와 two-byte NULL로 끝이 난다. Full PIDL은 완전경로와 비슷하고 Shell namespace내 object의 식별자 역활을 수행한다.

많은 함수들에서는 Full PIDL보다는 relative PIDL을 사용된다. relative PIDL의 root는 Desktop이 아닌 폴더이다. As with relative paths, the series of item IDs that make up the structure define a path in the namespace between two objects. Although they do not uniquely identify the object, they are usually smaller than a full PIDL and sufficient for many purposes.

The most commonly used relative PIDLs, single-level PIDLs, are relative to the object's parent folder. They contain only the object's item ID and a terminating NULL. Multi-level PIDLs are also used for many purposes. They contain two or more item IDs and typically define a path from a parent folder to an object through a series of one or more subfolders. Note that a single-level PIDL can still be a fully qualified PIDL. In particular, desktop objects are children of the desktop, so their fully qualified PIDLs contain only one item ID.

쉘 API는 object의 PIDL을 얻는 다양한 방법을 제공하는데 (그 방법은 Getting a Folder's ID 참조) 우리는 어떤 object의 PIDL을 다른 object의 PIDL과 구별하는 용도로 사용할 뿐 다른 용도로 이용하는 경우는 드물다. 따라서 PIDL의 내부는 공개되지 않았다.

- Allocationg PIDLs

PIDL들이 경로와 비슷하지만 그것의 사용방법은 다소 다르다. 특히 PIDL을 위한 메모리 할당과 해제가 그렇다. 경로가 문자열을 사용하는 것과 마찬가지로 PIDL도 반드시 메모리가 할당되어 사용된다(ITEMIDLIST 구조체를 위한 충분한 메모리 할당이 필수적). 대부분의 경우 쉘이 PIDL을 만들고 메모리 할당도 함께 한다. 그리고 보통 application에게 그 메모리를 해제할 책임이 있다. 이런 PIDL의 할당과 해제에는 CoTaskMemAlloc함수와 CoTaskMemFree함수가 쓰인다.

Common Explorer Concepts 

( == Introduction to the Shell Namespace) (MSDN 번역)