Recently, I installed AutomatedQA's TestComplete (TC) in preparation for a training session I’ll be giving on October 29th. TC requires the Microsoft Script debugger (MSD) for debugging so installing that is a requirement. The problem I ran into was that after installing the script debugger I started seeing MSD popping up on an exception in a routine called "ParseDoc". Unfortunately, there was no filename and no indicator of where the message came from. At first, I tried checking the Disable script debugging (other) option from IE’s Internet Options which unfortunately, that made no difference. I figured it must have something to do with my installed add-ons and after perusing the list I immediately guessed it was IE Developer Toolbar. Bingo.

After a bit of spelunking it turns out there are essentially four options:

1. Uninstall IE Developer Toolbar
2. This post with a hack to edit IE Dev Toolbar with a resource editor and add a blank try catch block around the line in question.
3. Disable the IE Developer Toolbar BHO as follows:
   1. From IE7 select Tools|Manage Add-ons|Enable or Disable Add-ons
   2. Select IE Developer Toolbar BHO in the list, click Disable then OK
4. My personal favorite, use Firefox.

Of course, the last option renders the add-on practically useless but it’s quick and painless. I’m using version 1.00.2188.0 of IE Dev Toolbar which has been out for awhile which makes even more annoying this problem hasn’t been addressed.

Btw, if you or your company is looking for TestComplete training give us a call. In fact Lino, Falafel's CEO is in New York for TC training this week.

There are a number of reasons Delphi's debugger might fail to stop at a breakpoint you set. I've seen this issue mentioned time and again on the public newsgroups and I thought it might be worth posting a quick list off the top of my head:

• The .pas file you're debugging has is missing line feeds. Be sure that your file has correct CRLF characters at the end of each line.
• You have compiler optimizations turned on. Occaisonally, compiler optimizations may cause your code to execute in an unexpected order. Be sure to turn optimizations off and stack frames on.
  
• You're looking at a source file that's not actually compiled/linked into the active project. This can happen as a result of copying a file from one directory to another and your project desktop reopens the file from the old location. One quick way to tell is add a syntax error and compile the code, if it doesn't stop on the error then you're looking at the wrong file.
• You turned off Debug Information and Local symbols options. Of course, these are a lot less likely but still possible.
  

Ok, that's all for now. Let me know if you think of anything else and I'll update the list.

Since I work on Diamondback (the next release of Delphi) and ASP.NET specifically I thought I'd begin to mention some of the ASP.NET improvements that have been made now that we've “given out the bits” at Borcon.  One area that can be problematic in D8 is debugging ASP.NET applications on IIS.  While it's possible to use Cassini as an alternative development server, using IIS frequently encountered problems.  In D8, we made our best attempt given the time we had and the fact that MS uses an undocumented debugging mechanism for ASP.NET applications in VS.NET.  Regardless, now that we've had the time to research the issues more our debugger gurus have come up with a mechanism that works much better and enables much more consistent debugging of ASP.NET applications running under IIS from Diamondback.