Hi Scott,

Yes this area does need some work but is better in the most recent version. Which version of vm are you running? You can find the version in "tools>options>visual Micro>version"

This might help for now: The temp version of a .pde/ino will be .cpp. So that is one thing to watch for. Also when the document opens for edit it should also highlight the document name in the solution explorer. So if an item in the solution explorer isn't highlighted when you are editing code you will know it's in the wrong place.

If you do have temp files open and you compile vs will give you a warning to tell you the code has altered outside of vs. This is a good indicator of the problem and you can always select no to the "reload" option which will prevent your changes from being lost.

For errors in library sources you can use "Project>Show All>Arduino Files". This will include all the lib sources in the project and thus it will be very obvious if a temp or real source file is open.

Finally the next version due soon fixes a bug in the compiler cache. VM was not detecting changes to #defines when  compiling projects with libraries that depend on #defines. Arducopter certainly has this type of syntax so I would set "Tools>Options>Visual Micro>Compiler>Optimise Libraries" to False in the current release to avoid additional confusion.
 
A final alternative is to open the arduino ide and set the "External Editor" to ON, in the preferences. Then open the arducopter sketch in arduino and will notice it opens in readonly mode. You will be able to edit in VS and compile in Arduino. The external editor option forces arduino to reload before compile, so the changes you make in vs will be automatically detected and used. The arduino errors might be better for nwo?It's up to you.

Let me know which options you go with. Thanks

Thanks for the message it is good to hear that.

I also gave up with arduino for a while for the same reasons then I decided to have a go at making an addin.

I'll try to add a switch on the next version that optionally shows you the actual errors that are returned from the gcc compiler. I might need some help working out how to read the errors whilst preserving the line numbers. It would be nice to get this right, I also find it a pain!

Making the addin and running the sites has taken a lot of time. To fund the project I was faced with charging $10 or making an optional upgrade that might cost a little but not much more. So I decided to try creating a "sort of" debugger to help speed up arduino development. So it will probably be sold at a small charge when it is released.

I'm not looking to get rich from it and I am happy for people who can help or communicate ideas to beta it and if its any good then to tell others about it  

I'll send you an email, the video on the vm site is boring but the best overview so far. There are also some crude documents on the visualmicro.com wiki "debug" section.

I'm keen to hear how you get on debugging arducopter and which transport method you end up using (project properties). The default is HardwareSerial on Serial. For Arucopter you would at least need to set the Transport to FastSerial. 

I've been meaning to try the SoftwareSerial on some spare apm pins. Hint hint.

I have to say this...

Don't forget that it's an early beta and that it attempts to add breakpoint and trace commands to the temp source code files just prior to compilation. You should become very familiar with what it is doing before using it with props on any flying vehicle. Obviously, it's provided without warranty or responsibility on my part.

ps: Don't switch on break/pause until you have experimented with the difference trace and expression watch options.