Randal Ferguson wrote:Antonio,
<<You may use GetModuleHandle( cModuleName ) --> hInstance>>
I've tried using the name as it appears in the Window title bar and the .exe name and it always returns 0. What should I specify for cModuleName? What are the possible return codes? Is this function documented anywhere?
This external application isn't necessarily started from my fw app.
Thanks,
Randal
It seems that GetModuleHandle() can retrieve only the handle of the module started from the current process. From the MSDN:
Platform SDK: DLLs, Processes, and Threads
GetModuleHandle
The GetModuleHandle function retrieves a module handle for the specified module if the file has been mapped into the address space of the calling process.
To avoid the race conditions described in the Remarks section, use the GetModuleHandleEx function.
HMODULE GetModuleHandle(
LPCTSTR lpModuleName // module name
);
Parameters
lpModuleName
[in] Pointer to a null-terminated string that contains the name of the module (either a .dll or .exe file). If the file name extension is omitted, the default library extension .dll is appended. The file name string can include a trailing point character (.) to indicate that the module name has no extension. The string does not have to specify a path. When specifying a path, be sure to use backslashes (\), not forward slashes (/). The name is compared (case independently) to the names of modules currently mapped into the address space of the calling process.
If this parameter is NULL, GetModuleHandle returns a handle to the file used to create the calling process.
Return Values
If the function succeeds, the return value is a handle to the specified module.
If the function fails, the return value is NULL. To get extended error information, call GetLastError.
Remarks
The returned handle is not global or inheritable. It cannot be duplicated or used by another process.
The GetModuleHandle function returns a handle to a mapped module without incrementing its reference count. Therefore, use care when passing the handle to the FreeLibrary function, because doing so can cause a DLL module to be unmapped prematurely.
This function must also be used carefully in a multithreaded application. There is no guarantee that the module handle remains valid between the time this function returns the handle and the time it is used by another function. For example, a thread might retrieve a module handle by calling GetModuleHandle. Before the thread uses the handle in another function, a second thread could free the module and the system could load another module, giving it the same handle as the module that was recently freed. The first thread would be left with a module handle that refers to a module different than the one intended.
Windows 95/98/Me: GetModuleHandleW is supported by the Microsoft Layer for Unicode. To use this, you must add certain files to your application, as outlined in Microsoft Layer for Unicode on Windows 95/98/Me Systems.
Example Code
For an example, see Using Brushes.
Requirements
Windows NT/2000/XP: Included in Windows NT 3.1 and later.
Windows 95/98/Me: Included in Windows 95 and later.
Header: Declared in Winbase.h; include Windows.h.
Library: Use Kernel32.lib.
Unicode: Implemented as Unicode and ANSI versions on Windows NT/2000/XP. Also supported by Microsoft Layer for Unicode.
See Also
Dynamic-Link Libraries Overview, Dynamic-Link Library Functions, FreeLibrary, GetModuleFileName, GetModuleHandleEx
Platform SDK Release: November 2001 What did you think of this topic?
Let us know. Order a Platform SDK CD Online
(U.S/Canada) (International)
Requirements
Windows NT/2000/XP: Included in Windows NT 3.1 and later.
Windows 95/98/Me: Included in Windows 95 and later.
Header: Declared in Winbase.h; include Windows.h.
Library: Use Kernel32.lib.
Unicode: Implemented as Unicode and ANSI versions on Windows NT/2000/XP. Also supported by Microsoft Layer for Unicode.
See Also
Dynamic-Link Libraries Overview, Dynamic-Link Library Functions, FreeLibrary, GetModuleFileName, GetModuleHandleEx
EMG