In at least one case, the "goto" button in the compiler error dialog
box goes to the wrong line. If you have an angle-bracket #include,
e.g. #include <Table.h>, which is a syntax OBC apparently doesn't
understand at the moment, you will get an error like "include must be
followed by a name" with an accompanying line number (which is
correct). If you hit the goto button in that dialog, you will be taken to
the file in question, with the insertion point *two lines above* the line
in question.
Logged In: YES
user_id=583634
Gah. Thought we'd got rid of the last of these. Really need to
revisit some of the file reading code, tidy and improve it,
possibly refactor into one common place.
Anyway, second this.
Logged In: YES
user_id=191980
I've subsequently discovered lots more bug cases. If you seriously
overload OBC with #includes, the "goto" button may do all sorts of strange
things. Often, it will miss the relevant .h file entirely and go to the end of
my main code file. Sometimes, mostly when dealing with nested
#includes, it will go to the end of the .h that #included the problematic .h,
rather than the problematic line itself. Note that, AFAICT, the line number
in the dialog is always correct. Of course, without a filename, it's not
always that useful.
Logged In: YES
user_id=574706
Originator: NO
I second! And move this to tasks.
Also I have this observation:
// MySource.c
#incude "Window.h"
#include <VFSMgr.h>
Will produce a "Goto Bug Dialog" with correct line #
but when tapping on trhe 'Goto' button you are taken to the very last char of Window.h.
It will not Open the MySource.c.
Please fix asap.
Logged In: YES
user_id=574706
Originator: NO
Attached a .c wich will generate this BUG.
File Added: GotoErrorLineBug_c.PDB
Logged In: YES
user_id=574706
Originator: NO
Steve, This one has a .c file attached!
Logged In: YES
user_id=583634
Originator: NO
Thanks for adding that, John.
Is there supposed to be a .h file as well?
Logged In: YES
user_id=574706
Originator: NO
No, that's not needed...