CompuServe Messages

Rick, I think you misunderstood what I was saying. In a section of source code like this: inline void AddOneTo (long &value) {value++;} … long a; StringToNum ("\p123", &a); AddOneTo (a); … you can set a breakpoint on the "NumToString" line (it has a diamond next to it in the debugger), but you *can't* set a breakpoint on the "AddOneTo" line (no diamond). This means that you can't stop and find out the value of 'a' just before the "AddOneTo" call. My point was that the original code is equivalent to: StringToNum ("\p123", &a); a++; and so there is a piece of code ("a++") that *could* be marked with a debugging line number, enabling breakpoints on the line. I never asked for the ability to step *into* inline functions. Regards, Robin BTW, it occurs to me that using "StringToNum" makes a good contrast. Since it's a trap, it's implemented as an "inline" assembly macro and yet there's no problem setting a breakpoint on that line. Wouldn't it upset you if you couldn't set a breakpoint on any toolbox call?