I was thinking that it might be a good idea for an add in to view Dr Watson log files. Unfortunately I have only my log to work with so I have put together a test program for people to try on their machines. It requires Win2K (maybe XP, I am not sure if that uses DrW). Just run the executable and it should locate your exception log and do some simple highlighting. I have never use RichEdit before so I am sure that I am attacking the parsing problem badly but it will improve as I learn more. This is a first draft, the eventual addin will only show the exceptions for the project that is loaded.

Please tell me about any problems (attaching your log file) and any ideas that you think should be implemented. Please don't just download it and keep it, I need some feedback, not just 50 downloads and no comments.
Posted on 2004-02-28 10:32:47 by donkey
I have added a button to launch the Event Viewer to the toolbar. This will allow you to view events that would not be trapped by Dr Watson. It also provides a good example of how to open a document with ShellExecuteEx and force the main program to wait until it is closed before continuing. The document is opened by a thread so that the main window can be repainted while the doc is open.
Posted on 2004-02-28 13:27:26 by donkey
Small suggestion: use WaitForSingleObject to wait for process termination instead of the Sleep + GetExitCodeProcess hack.
Posted on 2004-02-28 19:11:49 by f0dder
Thanks fodder,

I should have been aware that WaitForSingleObject could use process handles :) Thinking about it I have used it before with hProcess, just one of those over thinking the problem things and not remembering the right API to use.

I also fixed up the search for the process ID so that it would not find false processes under some circumstances.
Posted on 2004-02-28 19:33:02 by donkey
Well, at least you used Sleep - I remember another certain piece of code :rolleyes: that didn't Sleep... and the author wouldn't listen to suggestions - he didn't close either pi.hThread nor pi.hProcess either, causing leaks (that turned out to be fatal on 9x... I wonder if people used his code, and this was the cause of certain IDEs having crash problems after a number of builds).

Btw, close the hProcess when the child process terminates :). This is a rather obvious thing to miss... "The process is closed, why should I close the handle"? The answer is, sorta, equally simple. You must be able to GetExitCodeProcess even after the process is done, so the kernel keeps a kernel object for this until the reference counter drops to zero - which it doesn't do until all open handles have been closed. The same goes for threads - you should CloseHandle when the thread is done (or right away if you don't need the handle).
Posted on 2004-02-28 21:06:37 by f0dder
Hi f0dder,

I remember why I picked that method but I was equally wrong in doing it from the test I just ran to make sure it would react as expected with the WaitForSingleObject. I had worried that the exit code might not be available because the handle would no longer be valid and used that to make sure that I got the exit code. I just tested and the exit code is still accessible even after it returns so there never was anything to worry about. Should have tested first, coded second :)

Yes, I have seen the type of thing you are talking about where people refuse to listen. It is a shame as everyone has alot to learn and shutting off your mind to new ideas and methods is always counter productive. I have always taken suggestions seriously if they are offered. It matters little to me whether they come from a newb or a guru, anyone can have a great idea

I did close hProcess (and hThread) for the CreateProcess function, I could find no reference that I had to do so for ShellExecuteEx. I had thought of it but as the API makes no mention at all of it I thought it was unnecessary. I will do a zero test and close the handle regardless of the docs, can't hurt anything by being cautious.

New upload
Posted on 2004-02-28 21:23:15 by donkey
Well, I think you really do have to CloseHandle even with ShellExecuteEx - otherwsie ShellExecuteEx would have to launch a thread doing WaitForSingleObject+CloseHandle, otherwise there *will* be a leak, for the same reason I described above (kernel mode object etc) - and I doubt ShellExecuteEx does this, even though the shell functions are generally on crack, acid, and every other bad drug you can think of ;)
Posted on 2004-02-28 21:38:53 by f0dder
My mistake, the process handle must be closed:

Use to indicate that the hProcess member receives the process handle. This handle is typically used to allow an application to find out when a process created with ShellExecuteEx terminates. In some cases, such as when execution is satisfied through a DDE conversation, no handle will be returned. The calling application is responsible for closing the handle when it is no longer needed.
Posted on 2004-02-28 21:57:54 by donkey
Heh, I missed that part too - even though I looked at the ref a couple of times, and the last time even looking for such a statement :P

But it makes sense, when you keep in mind that all kernel mode objects are reference counted, and that you have to be able to query stuff like processes and threads for status after they're done executing. And, especially for threads, it's very easy to miss this detail.
Posted on 2004-02-28 22:26:16 by f0dder