burleigh@cica.cica.indiana.edu (Frank Burleigh) (09/08/90)
I've been happily using TC++ professional 1.0 for a few months now. All is basically well except for the debugger within the TC++ environment and some facets of the standalone debugger. I'm curious if others have noticed any of these and, if so, have a way to solve/improve them. I have a 20MHz 386 with 4mb, several MB of which is EMS memory. I start TC tc prjname /e The integrated debugger has two annoying characteristics: 1. Evaluate/modify is slow. With the cursor on a data item, press ^F4 to evaluate it. The pane comes up with that data item name in the evaluate window. It takes TC a long time to show the contents of the item. It sometimes takes maybe 10 seconds or more for the contents to be visible. Watching a data item is even slower! if you have a data item in the watch window, stepping through your code can be *excruciatingly slow.* [I also note that stepping in the standalone debugger involves a perceptable delay from one step to another.] 2. Sometimes TC cannot evaluate a data item, which it claims is unknown to it (message to that effect), even though the item is local. TC seems to get into a "mood" when it can't show me anything declared within a function. I must say that when I see this, it's always been in the same function of my current program... Some other bad things just popped into my head... 3. Last week TC would die and kill my pc (protection violation message from 386^max) every time I tried to compile even one module in my project. After a lot of horsing around I found that if I deleted the .prj file and built a new one, I could continue my work. Apparently TC can corrupt a prj file but does not recognize when the prj file is corrupted. 4. There is no documented way to clean out the history list on dialogs where down arrow (show previous choices) is allowed. The delete key will remove an item, but as soon as you press any direction key, the (deleted) text is restored. This is not a big thing, but is a little annoying to me. If anyone knows of ways around any of the above, I'd appreciate hearing from you. Thanks in advance. -- Frank Burleigh burleigh@cica.cica.indiana.edu USENET: ...rutgers!iuvax!cica!burleigh BITNET: BURLEIGH@IUBACS.BITNET Department of Sociology, Indiana University, Bloomington, Indiana 47405
poffen@sj.ate.slb.com (Russ Poffenberger) (09/11/90)
In article <4866@cica.cica.indiana.edu> burleigh@cica.cica.indiana.edu (Frank Burleigh) writes: >I've been happily using TC++ professional 1.0 for a few months >now. All is basically well except for the debugger within the >TC++ environment and some facets of the standalone debugger. >I'm curious if others have noticed any of these and, if so, have >a way to solve/improve them. > >I have a 20MHz 386 with 4mb, several MB of which is EMS memory. >I start TC > > tc prjname /e > [stuff deleted] > >Some other bad things just popped into my head... > >3. Last week TC would die and kill my pc (protection violation > message from 386^max) every time I tried to compile even one > module in my project. After a lot of horsing around I found > that if I deleted the .prj file and built a new one, I could > continue my work. Apparently TC can corrupt a prj file but > does not recognize when the prj file is corrupted. This is a known bug. There is a patch file available called (if I remember right) tcppt1.zip. It fixes the corrupted .prj file problem along with a few other problems. It is avaialble in the PROGB section of the Borland forum on Compuserve. Note that you must rebuild your .prj files after applying the patch before the problem goes away. This is documented. I believe that someone has uploaded the patch to simtel recently. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254