Client app's window handle

[paulbent]

Within an ActiveX DLL, what's the easiest way to get the handle to the parent window of an application that creates an object from the DLL? The DLL needs the handle privately to use in API function calls.

Paul Bent
Northwind IT Systems

http://www.northwindit.co.uk

 

[SemperFiDownUnda]

You pass it in.

An application can have many windows. Each window has its own hwnd. An application loads a DLL once. Calling a DLL has nothing to do with the graphical window code. Ie there is no way at runtime to say code block x is owned by window y because it isn't its owned by thread z and thread z may independantly work on many windows.

 

[paulbent]

In this case I don't want to pass it in.

>>An application loads a DLL once.<<

Not necessarily. In this case the clients will be using late binding

>>there is no way at runtime to say code block x is owned by window y because it isn't its owned by thread z<<

An ActiveX DLL always runs in process and therefore must have the same process id as the client. Isn't there a way to get the parent handle from a process id? I know how to get a process id from a handle.

Paul Bent
Northwind IT Systems

http://www.northwindit.co.uk

 

[Hypetia]

Right from Win32 Programmer's Reference...

&quot;The GetActiveWindow function retrieves the window handle to the active window associated with the thread that calls the function.&quot;

 

[paulbent]

Hypetia,

Thanks for the response. I had considered this but it won't work if another app has input focus when the DLL calls GetActiveWindow. Under W9x I think I'd get the wrong handle and under NT/2000/XP it would return null.

Paul Bent
Northwind IT Systems

http://www.northwindit.co.uk

 

[SemperFiDownUnda]

&quot;Not necessarily. In this case the clients will be using late binding&quot;
late binding doesn't matter. A dll is only loaded ONCE. That is why you can't get single use from a component. Single use means that a seperate process is started for each instance. DLL's, as you have said, load into the callers address space (lets not get into COM+ here because even then they load in the callers address space the caller is just DLLHOST.EXE) thus only load ONCE.

&quot;...parent handle from a process id...&quot; My point is a process can have multiple windows. Write a VB program with a SUB MAIN then open 10 windows modaless from that sub main. The first window isn't the parent. All 10 windows have no parent window.

GetActiveWindow is a good bet just make sure your window is active before the call. But then you might as well just pass the window handle in.

For example I have 2 windows in my program. Window 1 is in the background but still processing its message pump (Modaless) Window 2 is the active window. Window 1 calls the DLL. The dll will get window 2 window not the caller, window 1, because both window 1 & 2 are in the same thread (vb is single threaded).

I'm a firm believer that if you want a method/function to know some state that its caller knowns then you should pass it in.

 

[strongm]

>I'm a firm believer that if you want a method/function to know some state that its caller knowns then you should pass it in.

Me too (although I'm not always religious about this, especially when providing examples here on tek-tips )