Mysterious DEBUG issue

[WSinc]

My understanding is that when I get an out-of-range subscript it is supposed to put me in the routine

where that occurred so I can look at variables in the same routine.

What is actually does: is put the little blue arrow in a place that has NOTHING to do with the routine,

so I cannot look at any variable in the routine. The call stack is completely wrong as well, so I cant use that either.

so - - I have to go back and insert a breakpoint(F9) near where the problem occurred, and/or stick in print statements, etc.

and run it again.

The text in the output is correct, BTW, it does tell you what line number, etc.

Ths problem seems to come up when the breakpoint is within an internal routine, i.e. one that comes after a CONTAINS statement.

Its a minor annoyance, but still I cant help but wonder why they did not test this ?? VS has been around for a long time, right ?

[Steven_L_Intel1]

This forum doesn't allow you to attach HTML files. In Windows you can right click on a file and select "Send to > Compressed (zipped) folder". But I like using 7-ZIp which is freeware (Note that it creates .7z files by default, but you can select .zip.) WinZip is a popular commercial Zip tool, but it's not free.

[JohnNichols]

This comment has been moved to its own thread

[WSinc]

OK, I used 7-zip to create this file.

This is a build I did only yesterday, so I dont understand about "out of date" builds.

As I said before, I can display the variables, and get the little green arrow, no problems.

right up until the time I hit the Out-of-range subscript, then everything turns to ****.

Like its getting lost somewhere (").

Well, take a look at this buildlog, maybe you see something suspicious there ?

I could always try a later version of VS, who would I contact about that ?

[Steven_L_Intel1]

Ok, Bill. Now zip up your entire project and attach that.

[Steven_L_Intel1]

I made this comment earlier, moved it to another thread, but it belongs here too...

You need to make sure the executable has been rebuilt in a Debug configuration. It is not enough for "debug to be turned on". I'm wondering if many of your debug problems here are due to out-of-date builds - it would fit many of the symptoms you report.

In Visual Studio, select Tools > Options > Projects and Solutions > Build and Run. For "On Run, when projects are out of date", set it to "Always build" or "Prompt to build". This will make sure that you're always running the latest executable.

[mecej4]

billsincl wrote:

This is a build I did only yesterday, so I dont understand about "out of date" builds.

With regard to the build process, "out-of-date" has the following meaning: If item A depends on B, and the time-stamps on A and B show that B is newer than A, then A is out-of-date and probably needs to be rebuilt or, in some cases, "touched". The file-time structure used by the Windows OS has a resolution of 0.1 microsecond, which is tiny compared to a second, let alone a day. Thus, if you have two files aa.f90 and bb.f90, and compiling aa.f90 produces a module file that is USEd in bb.f90, as soon as aa.f90 is compiled or bb.f90 is changed, bb.obj is "out of date" and needs to be recompiled.