By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,815 Members | 1,066 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,815 IT Pros & Developers. It's quick & easy.

WM_CLOSE

P: n/a
Hello,
Does anyone have any code that will catch a WM_CLOSE message (or any
window message) sent to another application?

TIA,
Steve
Nov 20 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
maybe this will help..
http://msdn.microsoft.com/library/de...dproctopic.asp

Imran.

"Steven" <no****@spam.com> wrote in message
news:ex**************@TK2MSFTNGP09.phx.gbl...
Hello,
Does anyone have any code that will catch a WM_CLOSE message (or any
window message) sent to another application?

TIA,
Steve

Nov 20 '05 #2

P: n/a
Thanks, Imran, that's basically the idea, but I need to do it for another
application. Imagine this scenario: my app (app1) is running, another app
(app2) is running. App2 is closed by user interaction and WM_CLOSE is
generated. App1 needs to catch the WM_CLOSE, determine who it is destined
for, and respond accordingly by updating it's app1 application display. Any
ideas?

Steve

"Imran Koradia" <no****@microsoft.com> wrote in message
news:uG*************@TK2MSFTNGP11.phx.gbl...
maybe this will help..
http://msdn.microsoft.com/library/de...dproctopic.asp
Imran.

"Steven" <no****@spam.com> wrote in message
news:ex**************@TK2MSFTNGP09.phx.gbl...
Hello,
Does anyone have any code that will catch a WM_CLOSE message (or any
window message) sent to another application?

TIA,
Steve


Nov 20 '05 #3

P: n/a
If I understand correctly, you're trying to catch the WM_CLOSE of another
app (app2) in your app (app1), right? As far as I know, I don't think you
can catch events raised in one application from another application if that
is in fact what you are implying. However, I may be wrong.
Any specific reason why you want to it this way? Maybe there's some other
way to accomplish what you are attempting to do. A little more detail might
help..

Imran.

"Steven" <no****@spam.com> wrote in message
news:uO**************@tk2msftngp13.phx.gbl...
Thanks, Imran, that's basically the idea, but I need to do it for another
application. Imagine this scenario: my app (app1) is running, another app
(app2) is running. App2 is closed by user interaction and WM_CLOSE is
generated. App1 needs to catch the WM_CLOSE, determine who it is destined
for, and respond accordingly by updating it's app1 application display. Any ideas?

Steve

"Imran Koradia" <no****@microsoft.com> wrote in message
news:uG*************@TK2MSFTNGP11.phx.gbl...
maybe this will help..

http://msdn.microsoft.com/library/de...dproctopic.asp

Imran.

"Steven" <no****@spam.com> wrote in message
news:ex**************@TK2MSFTNGP09.phx.gbl...
Hello,
Does anyone have any code that will catch a WM_CLOSE message (or any
window message) sent to another application?

TIA,
Steve



Nov 20 '05 #4

P: n/a
If I understand correctly, you're trying to catch the WM_CLOSE of another
app (app2) in your app (app1), right? As far as I know, I don't think you
can catch events raised in one application from another application if that
is in fact what you are implying. However, I may be wrong.
Any specific reason why you want to it this way? Maybe there's some other
way to accomplish what you are attempting to do. A little more detail might
help..

Imran.

"Steven" <no****@spam.com> wrote in message
news:uO**************@tk2msftngp13.phx.gbl...
Thanks, Imran, that's basically the idea, but I need to do it for another
application. Imagine this scenario: my app (app1) is running, another app
(app2) is running. App2 is closed by user interaction and WM_CLOSE is
generated. App1 needs to catch the WM_CLOSE, determine who it is destined
for, and respond accordingly by updating it's app1 application display. Any ideas?

Steve

"Imran Koradia" <no****@microsoft.com> wrote in message
news:uG*************@TK2MSFTNGP11.phx.gbl...
maybe this will help..

http://msdn.microsoft.com/library/de...dproctopic.asp

Imran.

"Steven" <no****@spam.com> wrote in message
news:ex**************@TK2MSFTNGP09.phx.gbl...
Hello,
Does anyone have any code that will catch a WM_CLOSE message (or any
window message) sent to another application?

TIA,
Steve



Nov 20 '05 #5

P: n/a
Your understanding is correct. I am trying to detect when an
application(app2) closes so that I may update app1's GUI. I have
applications that run 24/7. I am writing another application(AutoStart.exe)
that automates some of the day to day chores concerning these 24/7
applications. What I am trying to do is easy if the AutoStart app starts
the 24/7 apps. As long as the AutoStart app is not closed, it can detect
when any app it has started exits. But in practice, AutoStart starts these
apps, say at system boot, and is then closed. A user then logs in later in
the day and starts the AutoStart app. Now, the AutoStart app displays a list
of running processes in a list box that we are interested in. The problem
is, when one of these apps is closed in any manner, AutoStart does not now
know it and therefore cannot update its display in real time. I could set
up a timer and poll the running processes list at specified intervals, but
this seems wasteful and is not real time. I thought that if I could catch
the WM_CLOSE message going to the closing app in AutoStart, it could respond
appropriately. It's not that easy it seems. Any ideas would be helpful.

Thanks

"Imran Koradia" <no****@microsoft.com> wrote in message
news:uZ**************@TK2MSFTNGP12.phx.gbl...
If I understand correctly, you're trying to catch the WM_CLOSE of another
app (app2) in your app (app1), right? As far as I know, I don't think you
can catch events raised in one application from another application if that is in fact what you are implying. However, I may be wrong.
Any specific reason why you want to it this way? Maybe there's some other
way to accomplish what you are attempting to do. A little more detail might help..

Imran.

"Steven" <no****@spam.com> wrote in message
news:uO**************@tk2msftngp13.phx.gbl...
Thanks, Imran, that's basically the idea, but I need to do it for another
application. Imagine this scenario: my app (app1) is running, another app (app2) is running. App2 is closed by user interaction and WM_CLOSE is
generated. App1 needs to catch the WM_CLOSE, determine who it is destined for, and respond accordingly by updating it's app1 application display.

Any
ideas?

Steve

"Imran Koradia" <no****@microsoft.com> wrote in message
news:uG*************@TK2MSFTNGP11.phx.gbl...
maybe this will help..

http://msdn.microsoft.com/library/de...dproctopic.asp

Imran.

"Steven" <no****@spam.com> wrote in message
news:ex**************@TK2MSFTNGP09.phx.gbl...
> Hello,
> Does anyone have any code that will catch a WM_CLOSE message (or any > window message) sent to another application?
>
> TIA,
> Steve
>
>



Nov 20 '05 #6

P: n/a
Your understanding is correct. I am trying to detect when an
application(app2) closes so that I may update app1's GUI. I have
applications that run 24/7. I am writing another application(AutoStart.exe)
that automates some of the day to day chores concerning these 24/7
applications. What I am trying to do is easy if the AutoStart app starts
the 24/7 apps. As long as the AutoStart app is not closed, it can detect
when any app it has started exits. But in practice, AutoStart starts these
apps, say at system boot, and is then closed. A user then logs in later in
the day and starts the AutoStart app. Now, the AutoStart app displays a list
of running processes in a list box that we are interested in. The problem
is, when one of these apps is closed in any manner, AutoStart does not now
know it and therefore cannot update its display in real time. I could set
up a timer and poll the running processes list at specified intervals, but
this seems wasteful and is not real time. I thought that if I could catch
the WM_CLOSE message going to the closing app in AutoStart, it could respond
appropriately. It's not that easy it seems. Any ideas would be helpful.

Thanks

"Imran Koradia" <no****@microsoft.com> wrote in message
news:uZ**************@TK2MSFTNGP12.phx.gbl...
If I understand correctly, you're trying to catch the WM_CLOSE of another
app (app2) in your app (app1), right? As far as I know, I don't think you
can catch events raised in one application from another application if that is in fact what you are implying. However, I may be wrong.
Any specific reason why you want to it this way? Maybe there's some other
way to accomplish what you are attempting to do. A little more detail might help..

Imran.

"Steven" <no****@spam.com> wrote in message
news:uO**************@tk2msftngp13.phx.gbl...
Thanks, Imran, that's basically the idea, but I need to do it for another
application. Imagine this scenario: my app (app1) is running, another app (app2) is running. App2 is closed by user interaction and WM_CLOSE is
generated. App1 needs to catch the WM_CLOSE, determine who it is destined for, and respond accordingly by updating it's app1 application display.

Any
ideas?

Steve

"Imran Koradia" <no****@microsoft.com> wrote in message
news:uG*************@TK2MSFTNGP11.phx.gbl...
maybe this will help..

http://msdn.microsoft.com/library/de...dproctopic.asp

Imran.

"Steven" <no****@spam.com> wrote in message
news:ex**************@TK2MSFTNGP09.phx.gbl...
> Hello,
> Does anyone have any code that will catch a WM_CLOSE message (or any > window message) sent to another application?
>
> TIA,
> Steve
>
>



Nov 20 '05 #7

P: n/a
On Fri, 30 Jul 2004 18:39:56 -0000, Steven wrote:
Thanks, Imran, that's basically the idea, but I need to do it for another
application. Imagine this scenario: my app (app1) is running, another app
(app2) is running. App2 is closed by user interaction and WM_CLOSE is
generated. App1 needs to catch the WM_CLOSE, determine who it is destined
for, and respond accordingly by updating it's app1 application display. Any
ideas?


What you're trying to accomplish is called a cross process hook, and is
possible using the API call SetWindowsHookEx. The problem is that you will
not be able to do this directly from VB.NET. A cross process hook requires
the hook callback function to reside in a standard dll - which means you
must create that function using C/C++ or another language that supports
creation of those dll's. You can then tie into your dll, via P/Invoke.

--
Tom Shelton [MVP]
Nov 20 '05 #8

P: n/a
The technique mentioned by Tom will work in real time and will be quite
efficient. If you can do away with a little delay, you could use a seperate
thread to poll your apps (processes) from within your Auto Start app say
every 0.5 to 1 sec and update your process/app list accordingly. This
shouldn't be too wasteful and should be good enough to appear real time for
us humans :)

hope this helps..
Imran.

"Tom Shelton" <to*@YOUKNOWTHEDRILLmtogden.com> wrote in message
news:m0****************************@40tude.net...
On Fri, 30 Jul 2004 18:39:56 -0000, Steven wrote:
Thanks, Imran, that's basically the idea, but I need to do it for another application. Imagine this scenario: my app (app1) is running, another app (app2) is running. App2 is closed by user interaction and WM_CLOSE is
generated. App1 needs to catch the WM_CLOSE, determine who it is destined for, and respond accordingly by updating it's app1 application display. Any ideas?

What you're trying to accomplish is called a cross process hook, and is
possible using the API call SetWindowsHookEx. The problem is that you

will not be able to do this directly from VB.NET. A cross process hook requires the hook callback function to reside in a standard dll - which means you
must create that function using C/C++ or another language that supports
creation of those dll's. You can then tie into your dll, via P/Invoke.

--
Tom Shelton [MVP]

Nov 20 '05 #9

P: n/a
On Fri, 30 Jul 2004 18:39:56 -0000, Steven wrote:
Thanks, Imran, that's basically the idea, but I need to do it for another
application. Imagine this scenario: my app (app1) is running, another app
(app2) is running. App2 is closed by user interaction and WM_CLOSE is
generated. App1 needs to catch the WM_CLOSE, determine who it is destined
for, and respond accordingly by updating it's app1 application display. Any
ideas?


What you're trying to accomplish is called a cross process hook, and is
possible using the API call SetWindowsHookEx. The problem is that you will
not be able to do this directly from VB.NET. A cross process hook requires
the hook callback function to reside in a standard dll - which means you
must create that function using C/C++ or another language that supports
creation of those dll's. You can then tie into your dll, via P/Invoke.

--
Tom Shelton [MVP]
Nov 20 '05 #10

P: n/a
The technique mentioned by Tom will work in real time and will be quite
efficient. If you can do away with a little delay, you could use a seperate
thread to poll your apps (processes) from within your Auto Start app say
every 0.5 to 1 sec and update your process/app list accordingly. This
shouldn't be too wasteful and should be good enough to appear real time for
us humans :)

hope this helps..
Imran.

"Tom Shelton" <to*@YOUKNOWTHEDRILLmtogden.com> wrote in message
news:m0****************************@40tude.net...
On Fri, 30 Jul 2004 18:39:56 -0000, Steven wrote:
Thanks, Imran, that's basically the idea, but I need to do it for another application. Imagine this scenario: my app (app1) is running, another app (app2) is running. App2 is closed by user interaction and WM_CLOSE is
generated. App1 needs to catch the WM_CLOSE, determine who it is destined for, and respond accordingly by updating it's app1 application display. Any ideas?

What you're trying to accomplish is called a cross process hook, and is
possible using the API call SetWindowsHookEx. The problem is that you

will not be able to do this directly from VB.NET. A cross process hook requires the hook callback function to reside in a standard dll - which means you
must create that function using C/C++ or another language that supports
creation of those dll's. You can then tie into your dll, via P/Invoke.

--
Tom Shelton [MVP]

Nov 20 '05 #11

P: n/a
Imran, Tom,
Thanks for your replies. I had hoped to avoid the polling method. We
have some C++ guys here, maybe they can whip up a dll or something in short
order.

Thanks again,
Steven

"Imran Koradia" <no****@microsoft.com> wrote in message
news:O9**************@TK2MSFTNGP09.phx.gbl...
The technique mentioned by Tom will work in real time and will be quite
efficient. If you can do away with a little delay, you could use a seperate thread to poll your apps (processes) from within your Auto Start app say
every 0.5 to 1 sec and update your process/app list accordingly. This
shouldn't be too wasteful and should be good enough to appear real time for us humans :)

hope this helps..
Imran.

"Tom Shelton" <to*@YOUKNOWTHEDRILLmtogden.com> wrote in message
news:m0****************************@40tude.net...
On Fri, 30 Jul 2004 18:39:56 -0000, Steven wrote:
Thanks, Imran, that's basically the idea, but I need to do it for another application. Imagine this scenario: my app (app1) is running, another app (app2) is running. App2 is closed by user interaction and WM_CLOSE is
generated. App1 needs to catch the WM_CLOSE, determine who it is destined for, and respond accordingly by updating it's app1 application
display.
Any ideas?


What you're trying to accomplish is called a cross process hook, and is
possible using the API call SetWindowsHookEx. The problem is that you

will
not be able to do this directly from VB.NET. A cross process hook

requires
the hook callback function to reside in a standard dll - which means you
must create that function using C/C++ or another language that supports
creation of those dll's. You can then tie into your dll, via P/Invoke.

--
Tom Shelton [MVP]


Nov 20 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.