|
When P1 starts, check for the existance of the special window and create it if necessary. Save the window handle for later. When P2 starts, check for the existance of the special window and create it if necessary. Save the window handle for later. When P1 ends, if it has a valid window handle and P2 is not running, close the special window. When P2 ends, if it has a valid window handle and P1 is not running, close the special window. Will that work?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
That's exactly what I'm doing already. The problem occurs when closing P1 but P2 is still running: the special window is closed anyway (which appears unavoidable unless a separate process is used for the special window).
|
|
|
|
|
So are you saying that P1 is closing the special window without first checking to see if P2 is still running?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
No; let me show you some psuedo-code to illustrate:
P1_OnExit()<br />
{<br />
if(!exists(P2))<br />
close(specialwindow)
}<br />
|
|
|
|
|
It looks as though the exists() function is not returning the correct status of P2.
On the other hand, I may be making an incorrect assumption about the "special window." Reading through the other replies to this post, I was assuming it was a separate process (since the word spawn) was used. If it is indeed just a window that is "owned" by P1, my posts are wrong.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
I don't believe a window can survive it's parent process. If that is true then you need the "special window" to be a separate process. Then i believe you can just make the special process a "single instance" process by using a mutex.
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
If I did that, would the new process be visible to the user (listed in Task Manager)?
|
|
|
|
|
Yes
Why dont you simply *hide* P1 as if it was closed?
Another option is to inject the window into explorer.exe this way it wont die with P1.
Check CreateRemoteThread
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
Well, P1 will be taking up at least 40mb, so that's not an option 
Thanks, I'll check out that function.
|
|
|
|
|
|
We're trying to avoid that, making it as clean as possible. But, if there's no decent way around it, then we might end up doing that after all.
|
|
|
|
|
Sorry that Anonymous post was me... i timed out, had to actually do some work 
"Clean" is in the eye of the beholder. My first thought is that a Single Instance process for the special window would produce the "Simplest" solution. I always like simple. Of course I don't have the complete context of your problem so...
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
Well, basically I'm trying to force two different programs to appear as one program on the taskbar, but two separate programs in the alt-tab window. I'm currently doing it by making the two programs not show up on the taskbar, and using a special window and the ITaskbarList interface to make an entry on the taskbar that doesn't show up in the alt-tab window.
|
|
|
|
|
Probably a stupid question, but... Why not just One process that looks like One process because it is One process? 
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
Both apps are way too big to combine them both, that's why
|
|
|
|
|
Is that "Too big" as in the projects are too big, or in the process memory is too big?
If it's the later, then I wouldn't consider that an issue as both programs will have to be in memory regardless. In fact, it may be slightly less memory as there is no overhead for the second process (not mention code being used for communication).
If it's the former, then you may want to break up the application into dlls that are more easily managed.
--
Joel Lucsy
|
|
|
|
|
I mean the former; it would be a complete nightmare to combine them, and definitely not worth it.
|
|
|
|
|
Dear Friends,
I have a source code in which there are 2 socket classes i.e. CSocket & CAsyncSocket for both server and client.
Codes on the both classes are almost same i.e. having same message handlers of having same code.
I would like to know
1. if server or client program can be written by only one class then what is the use of CAsyncSocket together with CSocket?
2. Although CSocket is derived by CAsyncSocket, but if possible please let me know the benifits and uses of AsyncSocket over CSocket.......
Thanking you in advance.......
Billar
|
|
|
|
|
Check here[^]
Basically CAsyncSocket is the base class of CSocket.
A CSocket object represents a higher level of abstraction of the Windows Sockets API than that of a CAsyncSocket object.
CSocket works with classes CSocketFile and CArchive to manage the sending and receiving of data.
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
But what Billar mean is that there is CAsyncSocket while there is already CSocket-class. So he wants to know why CAsyncSocket is also included?
And actualy I want it to know too.
By the way, if you want to use CSocketFile and CArchive, do you have to declare them too on a certain way, for using pointers to those type of class? Or isn't that necessary and just typ: CScoketFile *p_mSockFile //for example
Thanx!!
|
|
|
|
|
The CSocket is a higher level class than the CAsyncSocket.
It is easier to manipulate to serialize the data over the network. You dont have to care much about socket notifications, it does all the work for you.
But you also lose some flexibility.
You can use whatever you need for your application.
In order to use CArchive and CSocketFile with an CSocket you just need to create a CSocketFile object (on the heap or on the stack, as you wish)and give it a pointer to your CSocket object.
Then when needed you create a CArchive and you map it to a CSocketFile via its constructor and now you are ready to serialize your data on the network by just passing the archive to your serialize function.
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
|
Billar wrote:
2. Although CSocket is derived by CAsyncSocket, but if possible please let me know the benifits and uses of AsyncSocket over CSocket.......
A CSocket object is harder to shut down than a CAsyncSocket object. It is harder to send and receive data, because the thread which is doing the work is tied up. Also a CAsyncSocket object does not require a separate thread.
Search the microsoft.public.vc.mfc newsgroup for the pros and cons of both.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Why are you implementing the client and server using two winsock wrapper classes?
Kuphryn
|
|
|
|
|
Both of them were written to encapsulate the old 16bit WinSock API. The API was primarily developed to provide non-blocking windows message based mechanism for socket IO since 16 bit windows was a non-preemptive multitasking OS. CAsyncSocket encapsulates the basic API while CSocket provides a blocking version of the same.
Today probably the only benefit in using them is to communicate across two MFC applications using serialization of MFC SERIALIZABLE classes. For any other socket use models you are better of using the Winsock2 API.
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
