Home AMX User Forum NetLinx Studio

Debugger is bugging me.

Does anyone else have a problem with the Debugger when debugging modules?

Breakpoints don?t break where you put them and when you step through code you can step on blank lines and comments which makes things confusing.

It looks like the debugger is always one line off. If I need to set a breakpoint I have to set it one line ABOVE the line I want to break at ? even if that means putting the breakpoint on a blank line. And when I do break and step through code, the line of code that runs is the line BELOW where the current break is marked.

Placing breakpoints and stepping into code in a main source file or include files seems to work fine. It?s only modules that I?ve always had a problem with. Is it just me?

Don?t know if it?s any different in Netlinx Studio 2.5, I haven?t upgraded from 2.4 yet.

Comments

  • viningvining Posts: 4,368
    That usually only happens if your not working on the same exact code as the master is running. Possibly you've made changes to the codes without re-compiling and uploading?
  • DHawthorneDHawthorne Posts: 4,584
    vining wrote:
    That usually only happens if your not working on the same exact code as the master is running. Possibly you've made changes to the codes without re-compiling and uploading?
    Oh no, there is a bigger problem than that. The compiler is inconsistent what it considers the end of a code block. I don't use breaks, but it shows up in error highlighting as well. Sometimes it willl bring you to the line before, sometimes to the line after, and sometimes several lines away, even with a fresh compile. Long comment blocks confuse it utterly (but at least, it's easy to figure that one out). Sometimes includes throw it off as well. The debug tokens are simply not always accurately marking what place in the code the compiled tokens point to. It also shows up when watching a variable that has more than one instance. I've tried to watch a variable that appears in different scopes, and have had the debug window suggest four different code blocks, none of which actually contain the variable (they often suggest an include rather than where the variable really exists) and all four wind up pointing to the same variable anyway if you watch all four ... even though the other 3 are different variables.

    It's a bit of a pet peeve with me, the troubleshooting tools. Many of them are very good, but some are useless. My very biggest gripe is the run-time message that says you have a problem, but not what file or variable name is generating it. Got to love it when you have 10K lines of code, and a repeating error that says "null index" and nothing else.

    Include handling needs work; I use them extensively, and just put up with the quirks. Better debug tokenization needs to be implemented too. I have long had the impression that they just don't use the debug tools the way I do over at AMX, and therefore haven't run into the same issues. Every new release I hope to see an improvement, but it hasn't happened yet.
  • alexanboalexanbo Posts: 282
    When I compile a source file with debug info turned on it will give me a line number where the error occurs. Of course since I use a lot of include files and modules I have to track down which exact file it's in but it is a little better then having nothing.
  • viningvining Posts: 4,368
    The error msg in the compiler window usually show the file name as well and if you double click it it takes you to that line.

    I also have many issues with the debug but not quite like yours, I only get that problem when I delete a line or add a line to my code and forget to re-compile and upload.

    I find that the debug does not like structures, even if I'm working on a small source code file. I tend to work on my includes seperately and then insert into the main code after it's working because in the final program with all the includes and modules I can't even use debug any more it just doesn't run. The compiled file is over a meg in size, probably 20k lines with spaces but just can't debug. Works fine but if I want to work on something I have to isolate it and run it in a small seperate main axs file on a different master.

    But with structures I find that I constantly drop my internet connection to the master during debug and I believe that's only when I'm debugging a structure, a fairly large structure with structures in the structure. Is it very annoying because I have to use an NI-700 to run my small files for debugging purposes while the entire code runs on an NI-4000. Switching back an forth is a pain but I'm getting used to it.
  • DHawthorneDHawthorne Posts: 4,584
    This is clearly the kind of issue that is dependent on how one structures their code. I always compile with debugging on, yes, most of the time I get line numbers with errors, but that is useless when your program has 20 files (no exageration, I really have projects that large), and often they are off a few lines. And there are still times wehn I don't even get that.

    In my quest to make my programs as modular and reusable as possible, I use modules and include files extensively. If I have two discreet systems running on one master (multi-room audio, and a local theater, for example) they are going to be modules instead of mixed code running both systems. I suspect it is the large number of files and includes that throws it off for me, and those who take a more straightforward approach probably just don't see it as often, if at all.

    But there is a definite problem; there is nothing worse than having to do a job with flawed tools, and the debugging tools are in fact flawed. I have workarounds for most of the situations I come across, but it would be much easier if they weren't necessary.
Sign In or Register to comment.