App1 can send a message to App2 and change App2's caption so I know I have the correct handle to App2 so why can I not subclass App2 from App1 using App2's handle
I have a working WndProc in App1 and it can subclass App1 using App1's handle but if I change the handle to App2's handle it wont catch messages from App2
Can it be done
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
Because the code of App2 works in other address space. If you want to subclass window in the other application you should do it in the context of this application. Imagine if you assign the address of procedure that is in the caller application to the window that is in the other application. You pass the address of function that is not valid in other application because each process have its own address space. I know the two approaches either dll injection or code injection.
When you inject a dll to the needed application you can subclass a window from the dll. You can pass each message to your application using different IPC methods. This method is described here.
Code injection is like to the previous method. You just inject a code to application and run it by any approach (for example CreateRemoteThread). This method is described here.
You can use hooks and filtering the inessential windows pass messages to your application.
Hijacking of window message in other process is more complex than in the process itself.
It is usually far easier, far more reliable, and far more stable over time just to pay for a version of a product that exposes an API instead of relying on hijacking. This normally violates your license agreement anyway and is a form of piracy.
Even if the vendor doesn't care, if he doesn't offer a version exposing an API you're usually far better off just replicating the functionality you require yourself.
For one thing both apps are mine. I wrote both applications so I don't need to pay for a version of a product that exposes an API instead of relying on hijacking, as you put it.
I have now found out that I can subclass App2 if I Shell it (which I really don't want to do this) from App1 instead of it running it as a standalone. In view of this then can it be said that App2 no longer runs in it's own address space but now it runs in the same address space as App1 and if not then how is it I can subclass App2.
App1 is the control panel application and App2 is one of several "robot" apps for a game I am developing. App1 is used by a person to manipulate the movements and other actions to be performed by the "robots"
If I cannot subclass App2 as a standalone then maybe I will have to change the way App1 controls these robot apps - probably going to need to use SendMessage instead.
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
dilettante sees hackers and malware authors hiding around every corner :P
jms if you wrote both apps then you shouldn't even need to subclass one from the other, just implement a strong interprocess communications routine. Maybe look into WM_COPYDATA
Yes, I am aware of other ways to cross communicate like CopyData as you suggest, winsock, DDE, etc. I just thought I would give subclassing a try to see if it would work out better and like I mentioned I can subclass as long as I Shell the other app. Also, as Magic suggested I might even try ActiveX
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
Since you have control of both programs there is another option, perhaps the most obvious one.
Extract the code you want to share between these two programs as a DLL project. Then have both programs make use of that.
This is a far easier thing to do than adding an Automation API to an existing program. It is easier to test, easier to deploy, easier to avoid or cope with binary compatibility breaks, and more efficient than cross-process communication anyway.
Well, that appears as an excellent option except I don't have the slightest idea how to go about making a DLL and then share code so both programs communicate with each other
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
I wasn't looking for IPC. I asked about subclassing. Where did you get the idea I was looking for IPC. If I mentioned it, it was only in response about being aware of IPC
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
Sorry, trick, but I can't use you project. I doesn't work and I can't figure it out because everything is in Russian and I can't read the message boxes so I don't know whats going on
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
Sorry, trick, but I can't use you project. I doesn't work and I can't figure it out because everything is in Russian and I can't read the message boxes so I don't know whats going on
Ok. I've made the other example. This example contain two projects: DLL and Exe.
DLL allows to subclass the different windows in other process as well. In order to start work you should call Initialize function. This function should return True if success. Further you can call SetSubclass for subclassing. This function takes a window handle at first parameter and a callbakc function at the second parameter. The callback function should have the following format:
Code:
Public Function UserWndProcProto( _
ByVal hwnd As Long, _
ByVal uMsg As Long, _
ByRef wParam As Long, _
ByRef lParam As Long, _
ByRef defCall As Boolean) As Long
defCall determines whether the default procedure should be called or not. You can change wParam, lParam and defCall to change behavior of window.
In order to delete a subclassing you should call RemoveSubclass function. You should pass the same parameters you passed to SetSubclass.
I attach the sources both DLL and EXE. All the sources is commented in English (sorry for my English) i think you should understand the sense. This dll may contains some bugs because i don't test it enough.
Some explanation.
This dll uses a communication window for message exchanging. It registered special window class and create an instance of this window class. It uses file-mapping for data exchanging and a mutex object for synchronization. When you subclass a window in other process it installs a WH_CALLWNDPROC hook in order to load HookDLL to the needed process. Further it send the special global window message to the subclassed window that contains an information about sublcalssing. This message is intercepted by CallWndProc function in the needed process and it installs the subclassing in other process by SetWindowSubclass function. Every message passed to the subclassed window now goes thru WndProc procedure. Now it is necessary pass the messages to the our application. I decide to ensure the data exchange through a shared memory. In order to ensure atomic access to the shared memory i use the mutex object. When the mutex is capured i can access to shared memory exclusively. It is helpful if you want to do many subclassing or use this dll in the many projects. Each message will be process separately. After the mutex is captured we can pass the message data to the our communication window through shared memory. When the message has been processed we check a DefCall field if it equals to true it calls the default window proc. Eventually it is release mutex in order to other processes can use the shared memory.
OK, your example (post 14) works very nice but I do have a concern. On the app I am subclassing I get an error message everytime I close that app even though i have already closed the subclassing app. The error message occurs no matter how or when I close the subclassed app.
Error message box =
Project1.exe - Application Error
The instruction at "0x734b37f4" referenced memory at "0x00000000". The memory could not be "read".
Click on OK to terminate the program.
Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.
OK, your example (post 14) works very nice but I do have a concern. On the app I am subclassing I get an error message everytime I close that app even though i have already closed the subclassing app. The error message occurs no matter how or when I close the subclassed app.
Error message box =
Project1.exe - Application Error
The instruction at "0x734b37f4" referenced memory at "0x00000000". The memory could not be "read".