#1367 Double clicking on error/warning build messages do not move the text editor to the relevant line in header

[Elena]

To me this really seems a bug, in case it isn't I apologize in advance. Strangely this is the first time I notice it. I was compiling a source which included a c++ header where a class and its functions are defined. Since it is a long a complex class, I am still getting tons of errors and warnings, mostly typos, and having to locate the indicted lines by hand is bothersome. Because if I double click on the error/warning messagesin the Build Messages tab as I usually do, the editor is NOT moved automatically to the indicted line, as it instead happens with .cpp files. Is it a bug or I failed to configure some preferences properly ? Thanks

[bluehazzard]

Can you post a example compiler error output from the build log tab?

[Elena]

Yes but I can say the error or warning does not matter.
My project is quite complex and made by several sources btw, including externsl (shared) ones. Anyway I am compiling main.cpp which includes Shape.h. Shape.h contains the definition of the class Shape (inside a namespace it belongs to, not sure it matters). Now for example inside a class public function I have written by mistake "exp_pos" while the variable name is "ext_pos". When compiling main.cpp I read in the build messages:
shape.h In member function 'bool ed::Shape::loadShape(std::wstring&)':
shape.h 263 error: 'exp_pos' was not declared in this scope; did you mean 'ext_pos' ?

If I double click on this error, the tab for Shape.h is not opened and the editor is not scrolled to line 263, as it happens when the error or warning is in main.cpp.
I must specify that Shape.h is included in my CB project (inside a folder in the project list tree called "ED_Shared" which corresponds to headers located outside the physical project directory, being them part of a shared SDK, in fact Shape.h is included as

include "../ED_Shared/Shape.h"

Perhaps this is the reason why the error line is not automatically located ?
Unfortunately I can't check right now if this "bug" is caused by the fact a source or header is an external dependency or not. Maybe it is not a bug ? Really no idea!
Thanks

[bluehazzard]

I created a minimal example with:
- header in same as source and both in project
- header in sub folder, not in project, with relative path in source file
- header in folder above source file, not in project, with relative path in source file
and the jump to error works. So it has to be something more complicated in your project.
Without (minimal example) or (full build log and file structure) it is hard to reproduce and fix...

[Elena]

Thanks for investigating, I am sorry you could not reproduce the bug.
Give me some days and I will then try to do more tests in the hope I can provide more info and details or in the worst case if I can prepare a simple example project for replicating

[Miguel Gimenez]

The double click does not work if the path has non-ASCII characters, this is a known problem yet to be solved. Is there any non-ASCII char in your project?

[Elena]

Thanks Miguel. No I really can't see where there may be non ASCII chars in my project (or there are and I am missing them ??)
Anyway I have prepared a very minimal CB project where the problem can be replicated perfectly (at least here...)
If I put a typo or error in the Header.h, it gets located without troubles. If the error instead is in the external header (as in the example, 'floap' instead of 'float') double clicking has no effect.
Please let me know if you need further data.
In case it's just me who made some mistake I apologize in advance of course!

[bluehazzard]

I just tested your project... sadly i can not reproduce it. i can put an error in Header.h and MyClass.h and both can be addressed by double klick on the error message in build messages.
i still think this is possible a parsing error, can you post the full rebuild log of the example project?

[Elena]

Thanks for testing. I selected Rebuild and here is the log (I suppose you mean that). But it doesn't seem to contain anything so interesting... if you think I can do more specific tests please let me know

[Elena]

Sorry for insisting, but to date I keep suffering this bug (it is very frustrating) and really without any further feedback I don't know what else to check in order to supply more clues on its cause... It really looks like on my machine all the extrrnal sources aren't opened when double clicking on the error messages

[bluehazzard]

I think i found something:
If you go in Settings->Compiler->Other settings->Advanced options->Yes->Output parsing
add your compiler output message:

e:\_inbox\test_cb\shared\myclass.h:12:17: error: 'floap' does not name a type; did you mean 'float'?

and hit test you get myclass.has filename
if you test my error message:

C:/Users/usr/Downloads/_TEST/Shared/MyClass.h:12:17: error: 'floatd' does not name a type; did you mean 'float'?

i get C:/Users/usr/Downloads/_TEST/Shared/MyClass.hso it is indeed a parsing error

[bluehazzard]

The difference is / and \ ...
but why....

[Elena]

OH... interesting ! That surely is related to the fact that Windows uses '\' where Linux and most operating systems use '/'s instead (Afaik)... so there is likely something to be investigate there... Maybe this is actually a MinGW problem ?! I have still to test...

[Elena]

I had finally some time to test better. I discovered two things.
1. If the external header contains capitals it will not work. Eg ../ESD_SDK/DeleteMe.h does not work. ../ESD_SDK/delete_me.h WORKS instead and if it contains errors It gets opened automatically on compiling and the indicted line located and marked in red. Not sure if any official guideline states that headers and source names have to be in lower cases, fact is I always used mixed case filenames (but I am not a linux gal lol)
2. The external header must be added to the project for it to be automatically opened - but here I am not sure this behaviour is the intended one or not, if it is that's still OK for me

Thanks for your attention