Running Process in the Background
in [MFC]
|
Prev: CRichEditControl and error when number of chars is >3072 in single line
Next: hi..pointer newbie question.
From: jayMFC on 6 May 2008 11:28 I want to design a process in MFC that runs in the background and is able to accept Windows Registered Message. The window registered message would then be used to determine the message to display on a dialog prompting for user's response. I am looking for a way to design this process to run in the background, can anybody help. Thanks.
From: Giovanni Dicanio on 6 May 2008 11:31 "jayMFC" <jayMFC(a)discussions.microsoft.com> ha scritto nel messaggio news:A27F01A3-9FDB-4AF7-A0B5-39D0955104DF(a)microsoft.com... >I want to design a process in MFC that runs in the background and is able >to > accept Windows Registered Message. The window registered message would > then > be used to determine the message to display on a dialog prompting for user's > response. > > I am looking for a way to design this process to run in the background, > can > anybody help. I believe an excellent place to visit is Joe's web-site: http://www.flounder.com/mvp_tips.htm you will find very interesting essays also about multi-threading there. Giovanni
From: Tom Serface on 6 May 2008 11:45 You could add it as a shell tray icon and hide the main window. That way the user would still get some feedback, but the program could be running just like any other program. And, you could have the main window show for the purposes of testing, etc. This class may help you: http://www.naughter.com/ntray.html The nice thing about this approach is that it makes it easy to work with the desktop and you would be running in the user's context without having to set up any login stuff like you would with a service. Tom "jayMFC" <jayMFC(a)discussions.microsoft.com> wrote in message news:A27F01A3-9FDB-4AF7-A0B5-39D0955104DF(a)microsoft.com... >I want to design a process in MFC that runs in the background and is able >to > accept Windows Registered Message. The window registered message would > then > be used to determine the message to display on a dialog prompting for user's > response. > > I am looking for a way to design this process to run in the background, > can > anybody help. > > Thanks.
From: Joseph M. Newcomer on 6 May 2008 23:58 The process has to have a message pump. That's crucial; without the message pump, it can't receive Registered Window Messages from another process. There are several ways to do this. One is to simply create the process. This works. But it is visible in the task bar. Another is to create a dialog-based process that has a tray icon. There is a description of how to do this in my essay on dialog-based apps, and Nish granted permission to use part of his artcle, which concerns how to create a dialog-based app that doesn't "flash" the main window before it becomes invisible. Another is to create a process that runs with an invisible top-level window. It will not appear in your task bar either, and you can create a tray icon for it if you want. But if it is a specialized process, you can create an ordinary console process and communicate with it via anonymous pipes. To choose what is the ideal mechanism requires having some additional detail about what this "background process" does, what it needs to do to interact with the user, why it is a separate process instead of a thread, and similar parameters. joe On Tue, 6 May 2008 08:28:04 -0700, jayMFC <jayMFC(a)discussions.microsoft.com> wrote: >I want to design a process in MFC that runs in the background and is able to >accept Windows Registered Message. The window registered message would then >be used to determine the message to display on a dialog prompting for user�s >response. > >I am looking for a way to design this process to run in the background, can >anybody help. > >Thanks. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: jayMFC on 7 May 2008 08:42
Thanks for all the comments, I found them all very useful. We were able to meet the desired specification using the System tray. We hide the icon and main window, to get the process running on the background that can respond to system registered messages. The comments from Tom Serface pointed us in the right direction. Thanks. jayMFC "Joseph M. Newcomer" wrote: > The process has to have a message pump. That's crucial; without the message pump, it > can't receive Registered Window Messages from another process. > > There are several ways to do this. One is to simply create the process. This works. But > it is visible in the task bar. > > Another is to create a dialog-based process that has a tray icon. There is a description > of how to do this in my essay on dialog-based apps, and Nish granted permission to use > part of his artcle, which concerns how to create a dialog-based app that doesn't "flash" > the main window before it becomes invisible. Another is to create a process that runs with > an invisible top-level window. It will not appear in your task bar either, and you can > create a tray icon for it if you want. > > But if it is a specialized process, you can create an ordinary console process and > communicate with it via anonymous pipes. > > To choose what is the ideal mechanism requires having some additional detail about what > this "background process" does, what it needs to do to interact with the user, why it is a > separate process instead of a thread, and similar parameters. > joe > > On Tue, 6 May 2008 08:28:04 -0700, jayMFC <jayMFC(a)discussions.microsoft.com> wrote: > > >I want to design a process in MFC that runs in the background and is able to > >accept Windows Registered Message. The window registered message would then > >be used to determine the message to display on a dialog prompting for user's > >response. > > > >I am looking for a way to design this process to run in the background, can > >anybody help. > > > >Thanks. > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm > |