Event driven, blocking Pipe for MFC?
-
Hi, Is there a possibility to create a named pipe server within an (SDI) MFC app without using threads, maybe even with MFC classes? It would be great if I could just create a named pipe object and receive a message/notification (to my SDI client window) when a client connects. Connecting from other clients should be blocked until the first request is finished. (So no threads and critical sections are needed). Is there anything that can solve this? Thank you, Niki
On second thought, the absolute easiest way for you to do this is what you already mentioned: Use the WM_COPYDATA window message. Yes it requires you to create and manage a window for purposes of receiving the message, but it just doesn't get any easier.
-
It might be simpler to use a mailslot than a named pipe. You can send an alert to the client with a window message - like WM_COPYDATA, then the client responds by sending the data through the mailslot. This is about as simple as it gets in Win32. If you want hand holding, use .NET instead.
-
Thank you, I thought about Mailslots already. But the problem is the size: I need to request data up to a 1 MB.
I don't see anything in the docs that say that you can't send 1 MB messages to a mailslot. You just specify zero for the intended message size when you create the mailslot, and it then allows messages of any size.
-
On second thought, the absolute easiest way for you to do this is what you already mentioned: Use the WM_COPYDATA window message. Yes it requires you to create and manage a window for purposes of receiving the message, but it just doesn't get any easier.
WM_COPYDATA...hmm, the first problem is within my (ATL) DLL where I hav no MFC. I created a window and a handling routine with plain Win32. First problem: I have a completely different scope and control flow inside my WndProc. I can't get an easy way to access my (ATL) object within my WndProc. Global variables are very ugly too. Second problem: I tried it but it does not work. This is what I've done: In my IInternetProtocol Start routine, I create a WindowClass and create a dummy window with CreateWindow. After that, there is the normal event loop. Inside my WndProc, I use WM_CREATE to find the window of my MFC app and send WM_COPYDATA as a request. This request is processed successfully by my MFC app; and now I immideatly send back an answer to the dummy window with WM_COPYDATA again. But now I have a strange endless loop: There are tons of requests to my MFC app now. When I do not send back a WM_COPYDATA to the DLLs dummy window I get only one request. But anyway, I think this technique is very slow (too slow) and not very robust, isn't it? A third thought: What about sockets? Is there an MFC abstraction that works as mentioned? Regards, Niki
-
I don't see anything in the docs that say that you can't send 1 MB messages to a mailslot. You just specify zero for the intended message size when you create the mailslot, and it then allows messages of any size.
-
WM_COPYDATA...hmm, the first problem is within my (ATL) DLL where I hav no MFC. I created a window and a handling routine with plain Win32. First problem: I have a completely different scope and control flow inside my WndProc. I can't get an easy way to access my (ATL) object within my WndProc. Global variables are very ugly too. Second problem: I tried it but it does not work. This is what I've done: In my IInternetProtocol Start routine, I create a WindowClass and create a dummy window with CreateWindow. After that, there is the normal event loop. Inside my WndProc, I use WM_CREATE to find the window of my MFC app and send WM_COPYDATA as a request. This request is processed successfully by my MFC app; and now I immideatly send back an answer to the dummy window with WM_COPYDATA again. But now I have a strange endless loop: There are tons of requests to my MFC app now. When I do not send back a WM_COPYDATA to the DLLs dummy window I get only one request. But anyway, I think this technique is very slow (too slow) and not very robust, isn't it? A third thought: What about sockets? Is there an MFC abstraction that works as mentioned? Regards, Niki
nobaq wrote:
What about sockets? Is there an MFC abstraction that works as mentioned?
CAsyncSocket uses window messages for socket notifications by default, so I'd say yes.
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
"Size of message is limited to around 400 bytes. " from http://www.codeproject.com/KB/threads/Win32IPC.aspx[^] :-(
Read the MSDN docs for the CreateMailslot() function. http://msdn.microsoft.com/en-us/library/aa365147.aspx[^] Whatever that Win32IPC article is saying is wrong.
-
WM_COPYDATA...hmm, the first problem is within my (ATL) DLL where I hav no MFC. I created a window and a handling routine with plain Win32. First problem: I have a completely different scope and control flow inside my WndProc. I can't get an easy way to access my (ATL) object within my WndProc. Global variables are very ugly too. Second problem: I tried it but it does not work. This is what I've done: In my IInternetProtocol Start routine, I create a WindowClass and create a dummy window with CreateWindow. After that, there is the normal event loop. Inside my WndProc, I use WM_CREATE to find the window of my MFC app and send WM_COPYDATA as a request. This request is processed successfully by my MFC app; and now I immideatly send back an answer to the dummy window with WM_COPYDATA again. But now I have a strange endless loop: There are tons of requests to my MFC app now. When I do not send back a WM_COPYDATA to the DLLs dummy window I get only one request. But anyway, I think this technique is very slow (too slow) and not very robust, isn't it? A third thought: What about sockets? Is there an MFC abstraction that works as mentioned? Regards, Niki
nobaq wrote:
Second problem: I tried it but it does not work.
If it doesn't work, then there is something wrong in your implementation. Post the code and we can take a look.
-
Read the MSDN docs for the CreateMailslot() function. http://msdn.microsoft.com/en-us/library/aa365147.aspx[^] Whatever that Win32IPC article is saying is wrong.
-
nobaq wrote:
Second problem: I tried it but it does not work.
If it doesn't work, then there is something wrong in your implementation. Post the code and we can take a look.
My problem was that I have overwritten my hWnd variable and so these two handles were the same. And I was sending WM_COPYDATA to my own window. Stupid :-( But I have a much better solution now: http://www.codeproject.com/script/Forums/View.aspx?fid=1647&msg=2859334[^]
