VS 2010: Editor is write protected in debugging after ifort 15.0.0.108 installation

[Johannes_Rieke]

Dear all,

I installed recently the new Visual Fortran Compiler XE 15.0.0.108 including the corresponding VS integration. After that my VS 2010 prof. (10.0.402019.1 SP1 Rel.) behaves different in debugging. I.e. during the debugging the editor don't let me write/change anything into my source files (neither the one with the breakpoint nor any other source of the solution opened). This was not the case from ifort 12.1 up to 14.1.3.

The documentation unfortunately says nothing about this and I did not find anything in the deep VS options menus. Can I turn this 'feature' off?

I find it a little bit annoying, because if you debug a huge project and have to change some e.g. not so important format issues, you cannot do it anymore during debugging. You have to stop debugging or writing the changes down in another editor, which I like to avoid.

Has anybody made the same experience? Any help will be welcome.

Best regards, Johannes

[andrew_4619]

Yes I experience that also. I thought it was a good idea I either want to change code or debug not both at the same time which can lead to problems.

[Johannes_Rieke]

push up...

No one else, who is annoyed by the 'edit' protection during debugging in editor? No comments from the Intel team?

It would be wonderful, if the users could have the choice to deactivate the 'feature'.

Best regards,

Johannes
 

[Andrew_Smith]

Yes it can lead to problems but those are not difficult to understand and are taken in preference to the slower procedures mention by the op.

[jirina]

I discovered this new feature too and I would appreciate an option to disable it. I sometimes find it useful to change the code during debugging, even though, and I hope I understand correctly, it is then necessary to stop debugging and compile the project with changes in the code.

[Steven_L_Intel1]

Sorry, missed this. Yes, we know about it and expect it will be fixed in Update 1. It was an attempt to solve the problem that some users were expecting any code changes to be immediately applied to the current debugging session - something we don't support. But the cure was worse than the disease.