The information in this article applies to:
SUMMARY
When hosting the Internet Explorer 4.0x WebBrowser control, it is possible
to move the control to both virtual and file folders on the user's
local computer. These are folders such as the desktop and My Computer. The
problem is that when the user opens a folder in the control, a new Internet
Explorer window is opened to display the contents of the selected folder.
This might not always be the desired behavior.
MORE INFORMATIONThe following file is available for download from the Microsoft
Download Center. Click the file name below to download the file: WebApp.exeRelease Date: Jul-22-1998 For more information about how to download files from the Microsoft Download Center, please visit the Download Center at the following Web address http://www.microsoft.com/downloads/search.aspand then click How to use the Microsoft Download Center. For folders that exist in the file system, the path name can be retrieved from the DDE command and the WebBrowser control can be moved to the new folder by name. However, with virtual folders (such as My Computer), there is no path contained in the DDE command. In these cases, you need to move the control to an ITEMIDLIST pointer (PIDL), which is also included in the DDE command. The host application is always responsible for freeing the PIDL, whether a folder name is included or not. This PIDL is created in shared memory by the shell so that the PIDL can be used between different processes. Because of this, you need to use special functions to access and free the PIDL. Unfortunately, these functions are not public and must be loaded by ordinal number. There are two other special cases that you also need to consider. The first is when the user selects Explore instead of Open. In this case, the host application will not know the actual command until the DDE conversation has already been established. By this time, it is too late to allow the DDE conversation to be handled by the default shell implementation. To work around this, the host application must call ShellExecuteEx itself to get the default behavior. While doing this, it must prevent itself from responding the new DDE conversation. The second special case that you must handle is when another application calls ShellExecuteEx to navigate to a folder. This can happen if the user Selects Run from the Start Menu and types in a folder name, like "C:\". This triggers a call to ShellExecuteEx. In this case, the host application must not respond to the DDE conversation. To avoid this, the host application must only respond to DDE conversations that are being initiated by a window that is in the same process as the host application. This can be determined by getting the process ID of the window handle that is passed in the WM_DDE_INITITIATE message. If the window's process ID is not the same as the host application's process ID, the host application should simply return 0 from the WM_DDE_INITITIATE message. Additional query words:
Keywords : kbWinOS2000 kbSDKInet400 kbSDKInet401 kbSDKWin32 kbWebBrowser kbWinOS95 kbGrpShell |
Last Reviewed: January 25, 2000 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |