C / C++ / MFC

11-Jun-04 4:50

I have two programs, and I need to have a special window open whenever one or both of them are loaded. It's working pretty well, but I've run across a problem: if I load program 1, then program 2, then close P2, then close P1, it works fine (the window isn't destroyed until the last program exits), but if I load P1, then P2, then close P1, the special window is destroyed (because P1 was the program that spawned it). Is there any way to pass the special window from P1 to P2, so closing P1 doesn't close the that window? I can't just recreate the special window, because then it loses its position on the taskbar (moves to the end of the list of open programs).

Thanks!

David Crow11-Jun-04 5:16

David Crow

11-Jun-04 5:16

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

IGx8911-Jun-04 6:00

11-Jun-04 6:00

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).

David Crow11-Jun-04 6:12

David Crow

11-Jun-04 6:12

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

IGx8911-Jun-04 6:45

11-Jun-04 6:45

No; let me show you some psuedo-code to illustrate:

P1_OnExit()<br />
{<br />
   if(!exists(P2))<br />
      close(specialwindow) //window is closed, like it should be<br />
}<br />
//P1 closes<br />
//The special window is closed, even if P2 still exists<br />

David Crow11-Jun-04 7:17

David Crow

11-Jun-04 7:17

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

palbano11-Jun-04 5:34

palbano

11-Jun-04 5:34

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

IGx8911-Jun-04 5:58

11-Jun-04 5:58

If I did that, would the new process be visible to the user (listed in Task Manager)?

jmkhael11-Jun-04 6:06

jmkhael

11-Jun-04 6:06

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 ) ;

IGx8911-Jun-04 6:41

11-Jun-04 6:41

Well, P1 will be taking up at least 40mb, so that's not an option Smile | :)

Thanks, I'll check out that function.

Anonymous11-Jun-04 6:44

Anonymous

11-Jun-04 6:44

sure is that a problem?

IGx8911-Jun-04 6:47

11-Jun-04 6:47

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.

palbano11-Jun-04 7:02

palbano

11-Jun-04 7:02

Sorry that Anonymous post was me... i timed out, had to actually do some work Laugh | :laugh:

"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

IGx8911-Jun-04 7:11

11-Jun-04 7:11

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.

palbano11-Jun-04 7:43

palbano

11-Jun-04 7:43

Probably a stupid question, but... Why not just One process that looks like One process because it is One process? Big Grin | :-D

"No matter where you go, there your are." - Buckaroo Banzai

-pete

IGx8911-Jun-04 8:03

11-Jun-04 8:03

Both apps are way too big to combine them both, that's why Smile | :)

Joel Lucsy12-Jun-04 14:18

Joel Lucsy

12-Jun-04 14:18

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

IGx8912-Jun-04 15:23

Dialog Based Server-Client

12-Jun-04 15:23

I mean the former; it would be a complete nightmare to combine them, and definitely not worth it.

Billar11-Jun-04 3:50

Billar

11-Jun-04 3:50

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

jmkhael11-Jun-04 4:03

jmkhael

11-Jun-04 4:03

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 ) ;

Anonymous11-Jun-04 4:45

Anonymous

11-Jun-04 4:45

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!!

jmkhael11-Jun-04 4:54

jmkhael

11-Jun-04 4:54

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 ) ;