Author Topic: Breakpoints, timestamp, Step Over, Step Out, and strings  (Read 2030 times)


  • Guest
Breakpoints, timestamp, Step Over, Step Out, and strings
« on: October 06, 2006, 07:42:48 pm »
Set a breakpoint on a line that does not generate code and hit Project Debug. Debugger complains "Unable to set breakpoint..." and starts the program somewhere else. This is a nasty time waster because I must stop the debugger and move the breakpoint. It would be better to block setting invalid breakpoints based on already compiled code, automatically move the breakpoint to the nearest code, or don't start the program and force the user to move the breakpoint. You might limit such handholding to freshly created breakpoints. Old breakpoints are probably not important enough to bother the user about.

Edit a file without saving. Hit Project Debug. Program asks to save, hit yes. Debugger complains "Source has newer timestamp..." and drops me into the assembler debugger. This condition will not clear until the file is altered and saved manually.

If you're tricky, you can get both bugs above to fire at once! ;)

When the debugger is active, the editor windows display (*) breakpoints but do not allow them to be set or cleared. Any breakpoint can be cleared via right click in the breakpoint window but no new breakpoints can be set in a file other than the one showing in the debugger window.

Step Over seems to disable all (*) breakpoints guaranteeing that the next line is the next stop. Since this can be desired behavior, another button is needed: "Step Over with Breakpoints Enabled."

Step Out seems to be useless. I have yet to find a case where it does anything except drop me in the assembler debugger at a random location. What I want it to do is to drop me at the nearest return statement where I can take one last look at variables then single step my way back to the calling routine. So far to step out I must set breakpoints on all return statements and hit GO.

Code: [Select]
 struct _TEST {
    char a[16];
    const char *b;
    int c;
    int d;
  } t;
  memset(&t,0,sizeof(t)); // t starts closed in "Locals", open to see problems
  t.b="Invisible"; // breakpoint here shows a as [...] when first opened, shows as "Invisible" when closed and reopened
  t.c=75; // breakpoint here b shows as "Invisible"
  t.d=50; // singlestep to here with t open for both to display correctly

String and array variable display is fairly inconsistent in the debugger.

... even more ...

Code: [Select]
 struct _TEST2 {
    int xyzzy;
    int ozzy;
  } cave;
  int xyzzy=5;

Set a breakpoint at SendMessage() then point to the variables. Both xyzzy will show 5 and ozzy won't show anything.

If I double click on a breakpoint an editor window will be forced onto the screen with the breakpoint in view. Why is this option not in the right click menu?