Calling a function in my first instance of my DLL 
Author Message
 Calling a function in my first instance of my DLL

Hello I am new to VC++ and have written a DLL that exports some functions
that are called from a Visual Basic application. I use SetWindowsHookEx to
set a hook to a window in a seperate process. In the callback function for
the windows messages I call a function in my VB app to notify it that a
certain message has been sent to the window in question (I use the address
of the function which all works fine when hooked to a window in the same
process as my VB app). Well it always GPF's on this line that calls my VB
function. It must be because it can not handle going across the process to
the VB function. Is it possible to setup a function within the DLL that is
called from any other instances of the DLL like when using SetWindowsHookEx
on a seperate process which will do the call to my VB app. This way the call
is coming from the same process and all should be fine. Please let me know
how I would do this? Also is it possible to have array data in a shared
section so all instance of my DLL can read or change it? Also how do you
intialize an array in its declaration?
Any help is greatly appreciated!!
Thanks,
Ken


Fri, 28 Jun 2002 03:00:00 GMT  
 Calling a function in my first instance of my DLL


Quote:
> Hello I am new to VC++ and have written a DLL that exports some functions
> that are called from a Visual Basic application. I use SetWindowsHookEx to
> set a hook to a window in a seperate process. In the callback function for
> the windows messages I call a function in my VB app to notify it that a
> certain message has been sent to the window in question (I use the address
> of the function which all works fine when hooked to a window in the same
> process as my VB app). Well it always GPF's on this line that calls my VB
> function. It must be because it can not handle going across the process to
> the VB function. Is it possible to setup a function within the DLL that is
> called from any other instances of the DLL like when using
SetWindowsHookEx
> on a seperate process which will do the call to my VB app. This way the
call
> is coming from the same process and all should be fine. Please let me know
> how I would do this? Also is it possible to have array data in a shared
> section so all instance of my DLL can read or change it? Also how do you
> intialize an array in its declaration?

The problem is that your hook executes in the context of the application
that caused the event that the hook is reporting. While a 32 bit number may
be the address of your VB function in one process there is no telling what
it might be in another.

Now, the easiest way to call a function in another application is to send a
message ( see SendMessage() ) to a window owned by it. I'd hesitate to send
a messages in a system wide hook though. PostMessage() seems a safer option
to me. The difference between the two is that SendMessage() does not return
until the message is processed and by implication the code related to it
executed.

You still have the address space problem though if you try to pass arbitrary
addresses in the messages with either SendMessage() or PostMessage().

A better technique, if you must, is to set the hook to cause your DLL to be
injected into the target. Once the hook runs then you can subclass the
window in the target process. Now your subclass window procedure runs in the
target task. Goodbye address space problem.

System wide hooks are really big hammers. Miss the mark and you are going to
hurt yourself or someone else. I don't mean any offense by this - but system
wide hooks and subclassing windows you don't own are techniques that demand
and require far more attention to detail than is found in your average VB
program. It's best to go slow if you must go down this path at all.

Regards,
Will



Fri, 28 Jun 2002 03:00:00 GMT  
 Calling a function in my first instance of my DLL
William,
Again thanks for the info!!
Thanks,
Ken



Quote:


> > Hello I am new to VC++ and have written a DLL that exports some
functions
> > that are called from a Visual Basic application. I use SetWindowsHookEx
to
> > set a hook to a window in a seperate process. In the callback function
for
> > the windows messages I call a function in my VB app to notify it that a
> > certain message has been sent to the window in question (I use the
address
> > of the function which all works fine when hooked to a window in the same
> > process as my VB app). Well it always GPF's on this line that calls my
VB
> > function. It must be because it can not handle going across the process
to
> > the VB function. Is it possible to setup a function within the DLL that
is
> > called from any other instances of the DLL like when using
> SetWindowsHookEx
> > on a seperate process which will do the call to my VB app. This way the
> call
> > is coming from the same process and all should be fine. Please let me
know
> > how I would do this? Also is it possible to have array data in a shared
> > section so all instance of my DLL can read or change it? Also how do you
> > intialize an array in its declaration?

> The problem is that your hook executes in the context of the application
> that caused the event that the hook is reporting. While a 32 bit number
may
> be the address of your VB function in one process there is no telling what
> it might be in another.

> Now, the easiest way to call a function in another application is to send
a
> message ( see SendMessage() ) to a window owned by it. I'd hesitate to
send
> a messages in a system wide hook though. PostMessage() seems a safer
option
> to me. The difference between the two is that SendMessage() does not
return
> until the message is processed and by implication the code related to it
> executed.

> You still have the address space problem though if you try to pass
arbitrary
> addresses in the messages with either SendMessage() or PostMessage().

> A better technique, if you must, is to set the hook to cause your DLL to
be
> injected into the target. Once the hook runs then you can subclass the
> window in the target process. Now your subclass window procedure runs in
the
> target task. Goodbye address space problem.

> System wide hooks are really big hammers. Miss the mark and you are going
to
> hurt yourself or someone else. I don't mean any offense by this - but
system
> wide hooks and subclassing windows you don't own are techniques that
demand
> and require far more attention to detail than is found in your average VB
> program. It's best to go slow if you must go down this path at all.

> Regards,
> Will



Sat, 29 Jun 2002 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. First Call to DLL is slow

2. Help: First dll for VB calling, .def file problems

3. new instance vs. static function calls

4. Call a CMainFrame menu function when app first starts

5. call other instance's function

6. Calling an exported function of a dll which are exported Stdcall calling convention

7. Call Back Functions call from within a DLL

8. Calling DLL functions without known function name, parameter-list until run-time

9. DLL function calling problems (explicit - only knowing function name at runtime)

10. First DLL - Problem accessing FUNCTIONS VS6 C++ NT4

11. Calling a dll function from another dll.

12. Exporting Template Function Instances From DLL

 

 
Powered by phpBB® Forum Software