C / C++ / MFC

If I remember corrctly, you don't pass the message to Event Viewer directly, but you pass an application name and message id. You need a DLL that contains the texts to the ID (don't ask me in what format). And you need a specific registry key (in local machine I think) pointing the Event Viewer to the path of the DLL. We also used this approach long ago in one of our applications but aren't using it anymore because it's so complicated. I would suggest the user needs to at least one directory where he/she has write permission. You could then enter the directory into some kind of ini file, read it on application start and write the log file into that directory. The good thing about pessimism is, that you are always either right or pleasently surprised.

Falconapollo wrote: The final goal is Interfacing C++ member functions with C libraries. If you want your C++ code to call C libraries then you use extern "C" { ...// C code and/or declarations. } If you want C libraries to call your C++ code then you must provide a C interface to it.

What is the net value of Path? "One man's wage rise is another man's price increase." - Harold Wilson "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons "You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

Are you sure that your project configuration includes that directory in its search path?

In C, you cannot define a function inside another function. All functions must stand on their own. The difficult we do right away... ...the impossible takes slightly longer.

maibam debina wrote: in function after writing return(); is it possible to continue process... Not in that same function. "One man's wage rise is another man's price increase." - Harold Wilson "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons "You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

ya it is actually i was planning to make entire program as function and create another main.c that display only the output of the function..

The short answer is between very difficult and you can't do this because not all of MFC is thread safe. There are specific parts of MFC designed for threading general background http://msdn.microsoft.com/en-us/library/975t8ks0%28v=vs.90%29.aspx[^] The tips page will give you the specific problem http://msdn.microsoft.com/en-us/library/h14y172e%28v=vs.90%29.aspx#_core_accessing_mfc_objects_from_non_2d_mfc_threads[^] QUOTE: If you have a multithreaded application that creates a thread in a way other than using a CWinThread object, you cannot access other MFC objects from that thread. In other words, if you want to access any MFC object from a secondary thread, you must create that thread with one of the methods described in Multithreading: Creating User-Interface Threads or Multithreading: Creating Worker Threads. These methods are the only ones that allow the class library to initialize the internal variables necessary to handle multithreaded applications. In vino veritas

You wont be able to access anything in other.dll declared in such a way from Run.dll because they will have different instance handles. The only thing preventing a big crash in try to do so will be MFC's safe pointers because it is an access violation to allow it. There are two ways around the problem provide a function that returns the status on a standard DLL interface function something like int OtherDLLStatus (void) { return (OtherDLLStaticVar); }; Then publish it on the DLL interface and get the static variable status via that call. I think that is probably all you need. However Option 2 is use shared memory mapping http://msdn.microsoft.com/en-us/library/ms810613.aspx[^] In vino veritas

Just another homework, no effort from poster, just "I can't do it" and a link. We're supposed to invest time and effort to offer you solutions for free, in our time, so you can get an A and forget about C++ or something? RTFM.

that confused me too，have you got the answer?

:laugh: :laugh: :laugh: You are welcome. It is a pretty basic solution and you might end up expanding on it to handle certain cases, but if your requirements are as simple as you have described, it should work just fine. Soren Madsen "When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty

Glad I could help. :-D The difficult we do right away... ...the impossible takes slightly longer.

Member 10125032 wrote: We have deployed a kit ...My first task is to write a c or c++ program which can parse those received frames and format ... in xml format to our own event handler Steps - Get the spec for the 'kit' to determine what it stores. - Read the data. - Parse it according to what you learned from the spec. It is unlikely that any complex solutions would be required for this (hopefully, but the spec is the source.) - The parser will create an internal format (list of structs probably) of your own devising. Probably very close to what you want to put into the xml. - Determine what the xml looks like. Either find out what it already expects. Or design it. If the latter then someone needs to tell you what data they expect. Otherwise you have no idea what you need to get. - Write the internal format out to xml form based on the previous step.

So have you stepped into Update(), using the debugger, to see where the exception is being thrown from? "One man's wage rise is another man's price increase." - Harold Wilson "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons "You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

If you're using this in C++ only, seems ok (let alone the preferences). However, I'd do this: - no namespace exports; be wary of linker decorations - export just the needed functions, not all (i.e. the "public" interface) - separate helpers from actors (i.e openConfigFile, isDefined vs getBool, getInt) - do not return std::string or others from functions; rather, return just simple testable values (int, bool) and change to bool openConfigFile(const std::string& filename, std::string& result); (or std::string* result) - if you'll get this used in other places, favor a C-like interface and do the plumbing code, such as BOOL WINAPI OpenConfigFileA(LPCSTR fileName, LPSTR* result); or use VARIANTs is needed in VBS. - or favor the COM-like exports with just structs with virtual pure functions and DllGetClassObject-like creators. There are many things to consider. I'm using sometimes even paper and pen to weight all these.