Hi, Robert: Thanks for the post about JvDebugHandler.
I, too, am a newbie with Delphi (7). Just released my first commercial application and am finding that users have errors that I can not duplicate on my system. (We're all XP.) My question is: Can I set this up to run as part of the compiled app that the initial users (they know that the program is still in beta and understand the need to track down the errors--there are 60 of them) can then send that exception log file back to me when they run into something? Right now all I have is a simple log file of the immediate error only. Most users do a screen shot which is more helpful since it tells me where in the program they were, but even that at times misses the subtle actions that a user can take up to that point of the bug. Right now, I'm pretty much stuck on "if I can't reproduce the bug, I can't fix it." There are definite differences in computer environments, especially between lap tops and desk tops, and most users are not aware of their actions up to the bug. Thanks, Chuck Belanger > Hi Alan, > I asked the same question more than a few times years ago, and never > got an answer that was applicable to every situation. I finally realized > that this was because every error is different and there's no real > systematic way of dealing with them! The best I can offer is to make sure > you first find out where the error is. I never used MadExcept so I don't > know what kind of information it gives you. I've had the most success > tracking them down by having the Jedi JCL installed. It provides an option > that appears under Delphi's Project menu that you turn on called Jcl Debug > Info and automatically sets your project options up to provide the correct > information. Then turn your MAP file on to detailed, which is under the > Linker section of your Project options, and add the JvDebugHandler component > I and another guy first wrote together for Delphi 6. I've kept it updated > and it still works even with D2007. It can be found under the JvSystem Tool > Palette. > Turn all its properties on and then double-click it's OnOtherDestination > event and add code as below: > > procedure TMainF1.JvDebugHandler1OtherDestination(Sender: TObject); > begin > > JvDebugHandler1.ExceptionStringList.SaveToFile(IncludeTrailingPathDelimiter( > AppPath) + 'Exception Log.txt'); > end; > > In about 90% of the cases this has not only given me the exact line > on which the error occurred but also provides clues to its cause, as it > traces thru each event leading up to it. Just make sure you turn this > option off, get rid of the event and the component, and check your Linker > options again before making the final compile! > In the few instances where I am still unable to figure it out, I > usually put a breakpoint on a line in the Delphi editor, ( click in the left > margin ), somewhere before the error occurs and then run the app from the > IDE. When it stops at the break, I then move thru the rest of the app line > by line using Step Over, ( f8), until I again hit the error. And if that > doesn't clue me in, then I do the same but move thru it using Trace Into, ( > f7 ), because this will take me thru the source as well and many times > that's where the culprit is! And if it is, sometimes youcan find another > way to do the samething, or at least find out if the problem is coming up > because you need to use it differently due to version differences. A nice > thing about using breakpoints too is that you can check the value of > variables anywhere preceeding the break by moving the mouse over them. HTH > > > > from Robert Meek dba "Tangentals Design" > e-mail: [EMAIL PROTECTED] > Freelance Windows Programming for XP and Vista > Also proud to be a Moderator of the "Delphi-List" at elists.org > > "Reality cannot be explained...only enjoyed or endured as your current > perspective allows!" > > _______________________________________________ Delphi mailing list -> [email protected] http://lists.elists.org/cgi-bin/mailman/listinfo/delphi
