Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

several issues with "open #include file ..."

<< < (6/7) > >>

killerbot:
Yiannis,

Might be a good idea, for the multiple hits to provide as a list.
I'd have another look for the 'single file' case. For example in this case it should be the default compiler set, etc ..
I know it might be over-complicated  :P.
I just tried to think of nearly every situation without bothering the user, well in each solution we bother the user, either have the user set the correct target or have him select from multiple hits.

Does your remark also apply to the compiler ? Because there it is for sure a bug, don't think we should allow for selection here. Your target (or your single file) is using 1 and only 1 compiler. Allthough we again end up at the same problem when the target is 'all'.

What if the target is a dedicated one, we make sure we are using the correct compiler include dirs set, and in the case of 'all' we allow the selection out of multiple hits ?

Lieven

mandrav:

--- Quote ---Does your remark also apply to the compiler ? Because there it is for sure a bug, don't think we should allow for selection here. Your target (or your single file) is using 1 and only 1 compiler. Allthough we again end up at the same problem when the target is 'all'.
--- End quote ---

And I ask you again: what if the target is "all" (which is frequent), or we 're talking about a file without a project?
I often double-click a file in explorer, it opens in C::B and I start following #includes. The way it is now, it is working. And it's a simple piece of code to debug, if it wasn't working as expected.
If we did the modifications you 're suggesting, we 'd have some complicated code (harder to debug) and it wouldn't work in many cases.

So, I still think a selection list might be the best option here (only if we have more than one match). It's the only user-input we 'll ever need.

killerbot:
I do agree with your arguments.
Just let me show some example where 'both' might be usefull.

The situatio at our company, is we use several compilers. We create code that should work on different 'embbedded' platforms. Therefor we use the WindRiver compiler, the TI compiler. We have a pc model of the code also, so we also use, gnu, digital mars, Microsoft ...
Also good coding practices advice using several compilers (they all come up with different errors/warnings).

Most of the time we work in one specific environment for development and compile early/often with a specific compiler. And then after some time, we build the code with all compilers (if cbp, you can think as every target of the same code using a different compiler). That means each time we want to open include a c++ header (I agree here, this does probably not happen that often, one more argument for Yiannis I have to say), we get the list (probably every compiler set will have a hit), so we select from the pop up list.
This WORKS, so Yiannis you are right !

Might get irritating after a while (depending on the rate of open including c++ headers).
Might be nice that there might be another way of doing things (user selectable).

Again I agree, more code, more chance for bugs, less easier to debug.
Thoug I noticed that in RC2 rebuild all, always had a nag screen, and in the current cvs, excuse me, svn code, you can tell CB to stop the nagging and just rebuild all. --> More code ...  :D
Off course the frequency of rebuilding all is way higher thet open include c++ headers.

So we agree on adjusting with a pop-up list or something like that (might need some help here, but I'll do my best) and we can always see after that.

Yiannis, how do we solve the problem when the compiler has been changed for the project or for a target that the retriggering happens for the AddCompilerDirs() ??

Lieven

MortenMacFly:

--- Quote from: killerbot on November 27, 2005, 12:21:02 pm ---Yes you are missing a little thingy  :)

--- End quote ---
Aaaah! Now I got the whole picture (sorry for taking so long... :? ). So it was still about the includes - I tried and can confirm. I never did such things. My full respect that you take your information about the C++ API's and stuff directly from the header files... :shock:
That I'm reading this topic was because in fact I was thinking more in a different direction: Locating the C++ header files for code completion and stuff... A big sorry for the confusion.

Morten.

killerbot:
Yiannis,

just discovered another issue.

Make sure you close every project in CB, through the windows explorer double click a cpp file (with next to it (== in the same dir) it's header file).
Now in the cpp file (make sure it includes it own header), try to open include that header --> FAILS.
You can however do a successfull swap header source !

If you open a project (which does not include the 2 files from above) then it does work.

Things go wrong in CodeCompletion::OnOpenIncludeFile() :
In the first case (no project open), we get NULL back from m_NativeParsers.FindParserFromActiveEditor(), so we try to get it from the m_NativeParsers.FindParsersFromActiveProject() call.
In the first case there's no project -> NULL -> function returns.
In the second case we get a valid pointer. Then we try to find it by searching all the parsers include paths, no result for this, and then we try in the same dir --> bingo, found it.


So the problem is when there's no project, how do we get a valid parser.

I think , the swap header source should be looking for it's header/source buddy also in the includ dirs (is this correct?). If so : how comes that one can find it.

Can you give me a pointer to the solution, then I can add to my other fixes.

greetings,
Lieven

Navigation

[0] Message Index

[#] Next page

[*] Previous page