|
I have tried this creating a client/server architecture. I have created a server program on the PC on which I would like to run the programs and then used a client program on another PC to send messages to the server to start/stop a program. The problem is, from the time I disconnect and reconnect the client, the server doesn't recevie any messages from the client untill I reinitiate/rerun the server side program. I am using Ethernet to communicate. I am not having any COM ports left to use on client system, so the remaining are USB, parallel and ethernet ports.
Is there anyway to overcome this. I would like to run the server program all the time listening to the client requests no matter whether the client connects/disconnects. In other words, I would like to run the server program when windows boots and closes at windows shutdown and keeps listening to the client requests.
thanks,
-Pavan.
|
|
|
|
|
OK, you can do what you suggest but it is a little different than what I was thinking. I see two basic ways to do this, both of which are perfectly reasonable:
1 - Use a COM server and client, as we have already discussed.
2 - Use a SERVICE program running on the server, which is continually listening to a specific port for incoming connections using Windows sockets.
Your statement above indicates that you are thinking in terms of the second approach.
Let me clarify the first approach a little. A COM server typically only resides in memory when a client has requested its service, and therefore has a REFERENCE to the COM server. When the client closes down, it releases the reference to the COM server, and when the COM server realizes that there are no "open" references to it, it shuts itself down. This is typical behavior in the COM world. This is OK, because with the proper registry entries on both the server and client machines, the Windows COM system will automatically locate and launch the COM server when a client requests its services. It seemed to me that your client would simply invoke the server, getting a pointer to the server's interface, then invoking an interface function that would launch a specific program on the server.
Because the Windows COM system handles launching the COM server, you don't need to worry about whether the COM server is always on and always "listening" for incoming client requests. It will get started up as soon as a client requests one of its interfaces.
Now, for approach number two...I have done this type of thing as well, using a SERVICE program, which is NOT the same thing as a COM server. Not too long ago, I wrote a service program that I set up to start every time the operating system was started. These programs show up in the "Services" program under "Administrative Utilities" in the control panel. There are a number of articles that discuss how to write a service program. In my case, my service program was designed to "listen" on a user-selectable port for incoming socket connections. When a connection was established, it would spin off a thread to process bi-directional communications between the service program and the client. This was all done using the WinSock API. In this case, the service program was always running and listening for incoming connections.
I wish I could help you more, but it seems to me you will need to first decide which of the above approaches you wish to take (or yet another approach if someone else has made any additional suggestions).
Also, please note that I don't use MFC or ATL, nor have I dabbled too much yet with C# and .net. All of my code is straight C++ with direct calls to the Windows API. So, I will be unable to help you with code snippets if you're looking for MFC or C# stuff, etc.
I need to get back to work now. I'll check back this evening.
Scott
|
|
|
|
|
Thanks for explaining in detail. I think I would go with the second approach. I am not worried about the server side program as its a basic c++ console application (I can even end up executing exe files depending on the message it receives), but on the client side, I have to send messages from both MFC based application and also from basic c++ application DLL. But I can try both of the approaches that you suggested and see which one is more feasible within my application.
thanks,
-Pavan.
|
|
|
|
|
Google for Remote Procedure Calls (RPC).
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Good People,
Two quick questions:
1) Can I put texts and graphics in one CView?
2) Are there any tools to layout a CView graphically? For example, supposed I want a layout that is similar to the Code Project homepage. Is there a tool that can help me do that or do I have to write that myself.
Thanks,
BP
|
|
|
|
|
1 - of course, you can put anything you like
2 - only if you use a CFormView, in which case you get a dialog template you can lay out.
Christian Graus - C++ MVP
|
|
|
|
|
I'm beginner ,and I've got a exercise .I want to create a text box so we can input text in a rectangle.And the rectangle is created by moving mouse.
Thanks
|
|
|
|
|
You might want to start with capturing the mouse. When the user holds down the mouse button and drags, you can compare the POINT at WM_LBUTTONDOWN to the POINT at WM_LBUTTONUP. This will give you a rectangle. From there all you need do is create an EDIT control.
|
|
|
|
|
This is pretty advanced for a beginner. Do you know any MFC at all ? Are you using MFC ? Is this homework ? Are you sure you've got it right ?
I've done this, it's far from impossible, but I wouldn't assign it as a 'beginner' task.
Christian Graus - C++ MVP
|
|
|
|
|
I have an MFC exercise . In my application , i have 2 text box , user will fill there. after that , i must get data from 2 text box and write it to file ( Not important there are textfile or binaryfile ) . at the end, i must read data from this file (i have made) , fill it in to 2 another text box. Who can help me . I'm waitting for you reply. my email:rit116@yahoo.com
|
|
|
|
|
I'm not going to actually write code for this since it sounds much like a homework assignment. However, you might want to check out MSDN and also check out the CDocument save procedure.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Apart from beeing nonportable. Is there any benefit from using #pragma once over the standard include guards on a modern compiler like VS2005?
There used to e the argument that it is faster because the copmpiler does not have to reopen the include file multiple times. Is this still the case?
I would expect a state of the art compiler to automatically detect include guards which is the case in gcc but the sole existance of pragma once implies this it not the case with MSVC 8.x.
Am I right? What are your best practices?
|
|
|
|
|
|
Do the words "Implementation-Specific" or "platform dependant feature" mean anything to you? Please do yourself a favor and get a copy of the ISO 14882. Then find out why claiming any pragma directive has to be supported by any compliant compiler is complete nonsense. Any compliant compiler has to ignore pragma directives it does not know thats all.
|
|
|
|
|
No #pragma is "C++ compliant". The sole purpose of #pragma is to provide a hook for compiler specific control.
--
Now with chucklelin
|
|
|
|
|
MSDN
Presently, #pragma once is NOT portable, so if you are writing code that might be compiled on another system or for another compiler, it is best to stick with include guards.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
I know it's not supposed to be portable. But do you actually know any significant C++ compiler not implementing it? GCC has it and in fact they invented it, although it is commonly blamed on Microsoft, BCC has it, and MSVC has it. I would bet the Intel C++ compiler supports it too. So the non portability is just a theoretical issue. But thats not my question here. My MFC application is not portable by definition. So the question remains: Does it compile faster? If so and the code must be portable using both would be an option.
|
|
|
|
|
iberg wrote: I know it's not supposed to be portable. But do you actually know any significant C++ compiler not implementing it? GCC has it and in fact they invented it, although it is commonly blamed on Microsoft, BCC has it, and MSVC has it. I would bet the Intel C++ compiler supports it too.
Sun's compiler doesn't support it. Last I checked, Intel's didn't either. There are several that do, but it is not a standard extension, and it behaves differently on each compiler that does support it.
iberg wrote: My MFC application is not portable by definition.
Then you have nothing to worry about. Every MS compiler after VC6 has supported it.
iberg wrote: So the question remains: Does it compile faster? If so and the code must be portable using both would be an option.
According to Microsoft's documentation (the link I provided in the previous post), it does compiler faster since the preprocessor has to do less work. Though, a faster compilation is almost a pointless argument for using it in most cases. If you are writing your code for VS.Net (any version), it doesn't matter which you use. Chances are pretty high that you won't notice a significant increase in compilation time for 95% of the apps you write.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
iberg wrote: GCC has it and in fact they invented it,
Actually, with GCC it is not that simple. They first introduced it, then removed it (or at least there was a warning it was obsolete) and relatively recently re-introduced it.
|
|
|
|
|
With #pragma once you can't test whether a header has been included. If you use #ifndef FOO/#define FOO as your include guards, you can use #ifdef FOO elsewhere to see if foo.h has been inclded.
EDIT: I didn't answer the speed question but unless you have really slow outdated hardware, I doubt you'd ever see any noticeable difference in compile times. Also, the ability to test whether a header has been included is nice, which is why I prefer guards to #pragma once even if there is a speed penalty. As with any perf question, you have to measure to be sure, otherwise you're just guessing (like I am right now  )
Last modified: 4hrs 33mins after originally posted --
|
|
|
|
|
That was not the question. I'd like to know if there is any compile time benefit to use #pragma once as implied by MSDN. Theoretically there could be an advantage since the header files do not have to be opened multiple times which would be the case whan using defines. But since gcc detects include guards (which makes pragma once obsolete) i'd like to know if VS 2005 has such a feature too.
|
|
|
|
|
It may not have been the question but it certainly is an important and related observation. In fact most code that uses #pragma once has include guards first then the #pragma once for this exact reason.
Steve
|
|
|
|
|
I thought that was for portability.  I mean, what's the point of having include guards and #pragma once? If you just want to know if a file has been included already this would suffice:
#pragma once
#define __FOO_H__
--
Mr. Bender's Wardrobe by ROBOTANY 500
|
|
|
|
|
I stand corrected. I don't know what I was smoking when I wrote that.
Steve
|
|
|
|
|
As Mr. Dunn has mentioned you would need to measure it, and I don't think any of us have.
However, using precompiled header files REALLY does produce noticeable results. That is where I would focus my attention.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
