Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Debugging an Access Violation 1

Status
Not open for further replies.
Mar 17, 2005
44
US
Are there any good tips for debugging an Access Violation?

I have a form with a DBGrid on it. Users can click a button, be taken to a filters form, define filters and click OK. It then presents data according to the filter specification in the grid. This part generates dynamic SQL for querying against the database

There's also a quick lookup field where it basically does a quick lookup on name by re-executing "where name like "{entered string}%"

From time to time, it generates a randome access violation. If I'm in the IDE when this happens, of course it doesn't take me to the line I have a problem with.

Is there some way to track down Access Violations when they occur?

Thanks
Steve
 
Try Eurek Log you get 15 days trial which could be long enough to catch your bug.


Steve

Life is like a Grapefruit, sort of orangey-yellow and dimpled on the outside, wet and squidgy in the middle, it's got pips inside too. Oh and some people have half a one for breakfast. Ford Prefect.

Want to do more with TGML Download Star
 

From the menu, select Tools/Debugger Options...

Then select the "Language Exceptions" tab and tick "Stop on Delphi Exceptions"

That will get you closer to the problem area.

 
I'm going to try both suggestions, but if EurekaLog works well, for $24, I may just buy the darn thing. Always on the lookout for cheap, useful tools.
 
I did some more testing with this.

It looks like an Application.ProcessMessages is causing my problem. Is this possible?

Here's what I ended up doing.

I created a little procedure that does this:

Code:
procedure TfrmReview.WriteLog(s: String);
begin
  Writeln(outf, s);
  Closefile(outf);
  Append(outf);
end;

(Outf is opened via a rewrite in the FormCreate event).

Then, I place calls to WriteLog all through the code. One area of code looks like this:

Code:
    frmReview.Enabled := true;
    WriteLog ('form enabled');
    lblMsg.Caption := '';
    lblCardsShown.Caption := IntToStr(dmWarlord.qryReview.RecordCount);
    WriteLog ('Caption Loaded');
    Application.ProcessMessages;
    WriteLog ('Caption Loaded - Messages Processed');
    dmWarlord.qryReview.EnableControls;
    WriteLog ('Controls Enabled');
    dmWarlord.qryReview.Refresh;
    WriteLog ('Refresh Completed');

At the time of the Access Violation appearing I went and looked in the logfile and it stops as follows:

Code:
Base SQL Built
OrderBy Applied
Query Opened
if frmfilter stuff completed
form enabled
Caption Loaded

The only statement between log messages:

Caption Loaded
Caption Loaded - Messages Processed

is an Application.ProcessMessages

Is it possible for that to trigger an AccessViolation and if so is there anything I can do to get around it?

Thanks
Steve
 
Actually, I think I've worked out part of the problem. I have a DBGrid with a bunch of rows returned in it. I have a text field that has an OnChanged event that builds some SQL and based upon entry, filters the display.

If someone types fast, the previous OnChanged hasn't completed executing when the next one starts and they start running over each other and tripping up.

So it looks like what I really need is some way to single thread these calls to OnChanged - the next one can't start until the current one completes.

Can someone help me with that?

Thanks
Steve
 
in fact you are in a single thread,

however calling application.processmessages will process the message loop and so any pending events, so if this code is called from the onchange event handler, this is bad...

--------------------------------------
What You See Is What You Get
 
A ha! OK, I'll remove ProcessMessages from inside the event loop - and having done so, it looks much better.

Thanks.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top