Remote event/error logging question
-
Howdy, My company sells an MFC desktop application that is used to conduct various types of Radio Frequency testing by automating various test instruments and equipment. Our customers are all over the world. The application is a stand-alone product that runs on PC. We discourage our customers from allowing these computers to access the internet, although of our customers can do that if we need them to and ask really nicely. We would like to add some kind of remote event capture/error logging system to our application. It could just be a TRACE that writes to a text file, or it could be something fancier. We would have the user turn this logger on when he was having problems and we'd get a file back to help us understand what was happening. If it saves a support trip from Texas to China it'd sure be worth it. We could write something ourselves, but we'd buy an existing product if there was good a one out there. I've looked at products from Incert and Mutex. These seem really interesting, but are priced above my budget. Has anyone used or written such a system? If so do you have any reccomendations or product suggestions? thanks Jim
-
Howdy, My company sells an MFC desktop application that is used to conduct various types of Radio Frequency testing by automating various test instruments and equipment. Our customers are all over the world. The application is a stand-alone product that runs on PC. We discourage our customers from allowing these computers to access the internet, although of our customers can do that if we need them to and ask really nicely. We would like to add some kind of remote event capture/error logging system to our application. It could just be a TRACE that writes to a text file, or it could be something fancier. We would have the user turn this logger on when he was having problems and we'd get a file back to help us understand what was happening. If it saves a support trip from Texas to China it'd sure be worth it. We could write something ourselves, but we'd buy an existing product if there was good a one out there. I've looked at products from Incert and Mutex. These seem really interesting, but are priced above my budget. Has anyone used or written such a system? If so do you have any reccomendations or product suggestions? thanks Jim
*programming-question-sniffing-dog: "sniff, sniff"* Uh-oh! Sound the alarm -- a (gulp) programming question has been posted to the Lounge!! What say we tar and feather him, all? :-D :eek: :eek: :eek: Sincerely Yours, Brian Hart "And that's the news from Lake Wobegon, where all the women are strong, the men are good-looking, and the children are above-average." - Garrison Keillor
-
Howdy, My company sells an MFC desktop application that is used to conduct various types of Radio Frequency testing by automating various test instruments and equipment. Our customers are all over the world. The application is a stand-alone product that runs on PC. We discourage our customers from allowing these computers to access the internet, although of our customers can do that if we need them to and ask really nicely. We would like to add some kind of remote event capture/error logging system to our application. It could just be a TRACE that writes to a text file, or it could be something fancier. We would have the user turn this logger on when he was having problems and we'd get a file back to help us understand what was happening. If it saves a support trip from Texas to China it'd sure be worth it. We could write something ourselves, but we'd buy an existing product if there was good a one out there. I've looked at products from Incert and Mutex. These seem really interesting, but are priced above my budget. Has anyone used or written such a system? If so do you have any reccomendations or product suggestions? thanks Jim
Look at the VC++ documentation for _CrtSetReportMode(), _CrtSetReportFile(), and _CrtDbgReport() (and the _ASSERT, _ASSERTE, _RPT*, and _RPTF* macros). You can use _RPT*/_RPTF* similarly to TRACE, except that with _CrtSetReportMode() and _CrtSetReportFile() you can specify multiple destinations for the trace output (popup window, OutputDebugString(), and/or to a file) for each of three report classes: informational, warning, and error. It should be straightforward to set up your program to store flags for the CrtDbgReport mode and log filename for each mode in the registry (or specify them at runtime from a menu) and log debugging info to a file. This should do just what you want for the price of a few lines of code. Bomb our homes and threaten our children, and, as difficult as it is, we will still love you --- Martin Luther King, Jr.
-
Howdy, My company sells an MFC desktop application that is used to conduct various types of Radio Frequency testing by automating various test instruments and equipment. Our customers are all over the world. The application is a stand-alone product that runs on PC. We discourage our customers from allowing these computers to access the internet, although of our customers can do that if we need them to and ask really nicely. We would like to add some kind of remote event capture/error logging system to our application. It could just be a TRACE that writes to a text file, or it could be something fancier. We would have the user turn this logger on when he was having problems and we'd get a file back to help us understand what was happening. If it saves a support trip from Texas to China it'd sure be worth it. We could write something ourselves, but we'd buy an existing product if there was good a one out there. I've looked at products from Incert and Mutex. These seem really interesting, but are priced above my budget. Has anyone used or written such a system? If so do you have any reccomendations or product suggestions? thanks Jim
We're using the next strategy now in our desktop app. We supply two versions of the same executables/dlls to the client. One which logs tracing information to a text file and one which does not. The client works with the non-logging version until a problem occurs. To aid in locating the problem, the client has to reproduce the problem with the logging version of the application, which produces one or more text files. These text files are send to us. The source code contains Log.WriteLine("") statements at the appropriate places with tracing information. By defining "LOGGING" in code or project settings, the Log.WriteLine("") is either compiled into the executable or compiled not at all. It's a little more work, but eases locating problems a lot! Caught me an file attribute fetch problem with FindFirstFile on Windows 95 last week! Victor
