>The NT Event Log logging :) requires a special type of resource in a resource file and this cannot be done from VFP directly. So, a wrapper dll in C/C++ is mandatory. There some good articles (step by step) in MSDN on how to use NT's Event log. In fact, you can create entries in the log event using only the basic log related API functions, but you cannot attach your own messages to each entry.
>
>Vlad
>

Thanks - I made some assumptions based on reading the API call definitions, and assumed that ReportEvent would be doable after performing a RegisterEventSource(), and it looked fairly trivial aside from two of the parameters.

After a quick look, it turns out that it's a nearly trivial task in VB, since the VB App object has a LogEvent method, so a VB-created ActiveX control would be the QUAD method to implement it. I sat down with our office VB wizard, and we knocked out a control in a half-dozen lines of VB that wrote strings into NT's event log; it even handled the situation where you called it under Win95, writing into a file called vbevents.log without having to add any added code to handle the situation.

I guess this means there is a reason for VB to exist!

>>I haven't tried using them from VFP, but you might look into implementing LogEvent() or ReportEvent() from the API. My guess is that you'll have more success with ReportEvent(), although there's more to the API call, it doesn't rely on having a valid resource handle. You'll need something like POINTERS or CLSHEAP to manage the *lpStrings and lpRawData members passed to the API call, and you'd probably be better off writng a C-style .DLL as a wrapper, or implementing an OLE Automation object in C++ or Java (I'd look at VJ++, because of some of the native WFC classes available to access the event log there.)