jamesm@sco.COM (James M. Moore) (11/30/89)
Ran into a strange problem with the Think 4.0 debugger last night. I was
working on a styled text edit class as a subclass of CEditText, and had
several stub routines that did nothing, declared like so:
void BStylEditText::InsertText(Ptr data, long length) {};
with the entire function on one line.
The problem was that when I stepped into the InsertText routine, the debugger
indicated I was at a totally different point in my code, and then proceeded
to crash in various mysterious ways. Taking a closer look, I saw that the
debugger wasn't putting triangles next to the one-line procedures. Adding a
return in between the curly braces made the problem go away, and the
code now seems to be working fine.
I'm not entirely convinced myself that this is real; it's possible that
something else I changed is actually responsible for solving the problem.
But it sure looks like this is the cause. In any case, if you're having
bizarre problems with calling the wrong method, and you've got one-liners
like this, toss in a return and see if that solves the problem.
--
James Moore | Nil aon .sig maith agam anois -
Santa Cruz Operation UNIX Tech Support | B'fheidir an tseachtaine seo
jamesm@sco.com | chugainn.tim@hoptoad.uucp (Tim Maroney) (12/05/89)
In article <7726@viscous.sco.COM> jamesm@sco.COM (James M. Moore) writes: >Ran into a strange problem with the Think 4.0 debugger last night. I was >working on a styled text edit class as a subclass of CEditText, and had >several stub routines that did nothing, declared like so: > > void BStylEditText::InsertText(Ptr data, long length) {}; > >with the entire function on one line. > >The problem was that when I stepped into the InsertText routine, the debugger >indicated I was at a totally different point in my code, and then proceeded >to crash in various mysterious ways. Taking a closer look, I saw that the >debugger wasn't putting triangles next to the one-line procedures. Adding a >return in between the curly braces made the problem go away, and the >code now seems to be working fine. I know it's a problem in THINK C 3.0, so I wouldn't be surprised if they didn't fix it in 4.0. (I've *got* to send in that registration card one of these days!) I frequently write routines that have executable C text on the first post-parameter line of the routine, e.g., void foo() { bar(); ... } and the THINK C debugger refuses to put a triangle on the bar() line. I don't like the way the white space looks when I put the bracket on a line by itself, but it seems that THINK C wants to force me to use their preferred coding style. This appears to be the same thing that is biting you. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "I see little divinity about them or you. You talk to me of Christianity when you are in the act of hanging your enemies. Was there ever such blasphemous nonsense!" - Shaw, "The Devil's Disciple"