When using the GO button, for example, often a tab is opened with the cpp version of the ino file. Because there are 8 or so other files open with tabs in the editor, I too often wind up changing the cpp instead of the ino. Those changes are then lost.

Any way to avoid this?

Hi,

The temp .cpp build file is not opened as a result of the build process. It is more likely that you double clicked (drill down) a compiler error and Visual Micro incorrectly opened the .cpp file instead of the correct line of the respective .ino file

If you see an error that behaves in this way please post your error so we can tighten up the error translation routine.

All .ino files are combined into the .cpp during build so Visual Micro has to translate line numbers from .cpp to a valid .ino. Hence the opportunity for this error.

Thanks

Tim@Visual Micro wrote on May 3^rd, 2014 at 1:46pm:

Hi, The temp .cpp build file is not opened as a result of the build process. It is more likely that you double clicked (drill down) a compiler error and Visual Micro incorrectly opened the .cpp file instead of the correct line of the respective .ino file If you see an error that behaves in this way please post your error so we can tighten up the error translation routine. All .ino files are combined into the .cpp during build so Visual Micro has to translate line numbers from .cpp to a valid .ino. Hence the opportunity for this error. Thanks

I will look.

I think it's not based on an error.. but rather clicking on something like a function name and then clicking the GO button - that takes me to the cpp of the same root name as the ino file.

Indeed, I think it's possible to not use an ino file, with VM/VS, right?

No, you have to use .ino (at the moment)

The .cpp is only ever created in the temp build folder and is unknown to atmel studio. It can only appear as a result of clicking an error but should never appear if visual micro does it's job properly!

Tim@Visual Micro wrote on May 6^th, 2014 at 7:23pm:

No, you have to use .ino (at the moment) The .cpp is only ever created in the temp build folder and is unknown to atmel studio. It can only appear as a result of clicking an error but should never appear if visual micro does it's job properly!

Ah, if error. That's probably the issue. I do a compile, get an error in the output window. Of course, I click on that to see the errored code. That takes me to the cpp rather than the ino from which the cpp was produced.

I edit the cpp as I'm concentrating on the error, not the IDE. Alas, this correcting work is lost.

This seems to be a VM issue at the root, due to the dumb ino file convention.

It's hard to remember to avoid this trap. Wish VM could deal with it.


Flaws yes, but infinitely better than the Arduino IDE

Thanks. As mentioned previously please give an example of an error that is not being re-formatted correctly by Visual Micro.

Most errors are handled correctly and we can correct any examples that fall outside fo the current conversation rules.