Break points set in an included script during debugging sporadically jump to the last line of the included script

[ledz]

As I stated in the title, I use the ScriptInclude command quite extensively, because we have at our company a policy of maintaining one large-ish (roughly 7k lines) function library which is included by various individual evaluation scripts. Debugging this with break points is often the only (useful) way to see into the state of the script, so I depend on them. My problem is that often when I debug a script calling the function library, setting a break point in that library and running into it during debug mode will not transport the cursor to the location of the current break point, but instead to the very end of the included script. I have noticed this with a separate pair of scripts, as well, which includes a similar size script to call functions from (roughly 2k lines). Now I wonder if this has to do with the size of the scripts included, or if it is dependent on something else. It seems to not be affected by restarting DIAdem, and sometimes it works as intended, but I have not been able to reliably replicate indivdual occurrences one way or the other. Has anyone else had this problem happen to them?

[Pesmith8]

Leo

I also use scriptincludes extensively, Most of mine are in the range of 500 to 2000 lines.  Usually I organize them in logical code topics,  I like to use them to hold one class most of the time.  When I debug these I can set a breakpoint, and it will stop at that location.

I also use custom log class as well, I find this quite helpful, in the applications that are unattended.

The only thing I can think of to try is to separate the 7k file into 2 2k line files and then script include them separately.

Paul

ps. I sometimes need to have intellisense work from a file that was scriptincluded, this requires copying the file into the end of the main script.  (you most likely already know this 🙂  )

One other note, Are you talking about debuging code in a SUD, that is whole different problem to deal with.

[RussellSenior]

I have the same problem.  Even putting a breakpoint in the included script doesn't work for me.  I have the added benefit of Diadem causing an access violation error in the ntdll process if I stop the debugger while it's in the included script. 

[RussellSenior]

Actually, it seems related to code folding.  In my VBS library, code folding will work with Function or function.  BUT, if I create a new blank library, code folding only works with function and not Function...  if i use Function to create some dummy functions, this debugging problem does not occur.  Hope that helps NI find the problem....  

[RussellSenior]

I may have found a work around.  It's worked a few times for me.  Go to file->Change coding, then select unicode to ansi.  Like I said, my debugging works as expected now.  Try it, let the group know. This should go without saying, but backup your library first, this command overwrites it.

EDIT: Never mind.  It workd for about 4 or 5 times, but now it's back to highlighting the last line.. 

[ledz]

First of all, thank you Pesmith8 and RussellSenior for your replies.

Unfortunately, I do not have the option of splitting the function library into multiple files, since I am not the owner, just a contributor.

However, I seem to have found a way to mitigate the problem:

Set a break point at the line where you call a function in the included script. Then, step into (F8) the called function, which should transport you to the corresponding line in the included script file. After that, you can set further break points in the included script so you don't have to slog through a lengthy function tail or such.

I will keep testing this, but it seems to be a functional  workaround. Hopefully, this helps others, as well.

[ledz]

Update: It seems to only work if no unsaved changes are present in any script file involved.

EDIT: It seems that the script file you jump into needs to be at the end of the queue of open files.

EDIT2: Nothing I have tried seems to have a lasting effect. Very annoying.

[Brad_Turpin]

Hi Leo et al.,

Would one of you please take the time to submit a code example that NI could use to reproduce and debug this behavior?  It could be your full 7k lines of code or some subset or something entirely different, but we need to be able to explore this issue on R&D computers in order to fix it and/or find lasting workarounds.

Brad Turpin

DIAdem Product Support Engineer

National Instruments