Scan includes files for autocomplete

[Kurzer]

It would be great if PureBasic could scan "manually included" files for the autocomplete feature.

I know, that there is a switch in the project options dialog (scan file for autocomplete), so I do not need to open the file in the GUI. But the file have to be assigned as a project file.
Sometimes I use generic procedures which are not explicit part of the project file list (understand it as a kind of library). This files are located at a completely different directory and I include them via IncludeFile "...".

Regards, Kurzer

[Kukulkan]

+1

Kukulkan

[KJ67]

+1

[jamba]

I agree

[freak]

Its impossible to accurately know which files are included until you compile the code. This is why projects exist, so you can tell the IDE which files belong together.

[Kaeru Gaman]

@Kermit

is it a problem to add "..\..\AllIncludes\myInclude.pbi" to the Project...?

[Kurzer]

@Kermit
is it a problem to add "..\..\AllIncludes\myInclude.pbi" to the Project...?

No, its not a problem, even if it contradicts to my project-philisophy.
But, you have to assign every single file to the project, because the scan did not work recursivley.

Example - Imagine the following situation:
MyOwnGadgets.pb -> this file includes the following files:
- MyOwnButton.pb
- MyOwnRequester.pb
- MyOwnImageGadget.pb
- MyOwnWhatever.pb

So MyOwnGadgets.pb acts as a library and the files it include are the 'functions' of the library.
But if I assign the MyOwnGadgets.pb to my project, I still have no autocomplete for all the procedures it includes.
Maybe my include/library-philisophy is bullsh**, but the desired feature request would also be an advantage for non-project based files.

@freak: Thats right, but what speaks against an internal include filelist for the IDE, which is updated every compile run?

[Kaeru Gaman]

Maybe my include/library-philisophy is bullsh**

you know I normally don't hasitate for harsh words, but this time you said it clearer than I would.

I'd like to say, your concept calls for reconstruction.

the desired feature request would also be an advantage for non-project based files.

@freak: Thats right, but what speaks against an internal include filelist for the IDE, which is updated every compile run?

indeed, at least an idea worth concidering.

[Kurzer]

Maybe my include/library-philisophy is bullsh**

you know I normally don't hasitate for harsh words, but this time you said it clearer than I would.
I'd like to say, your concept calls for reconstruction.

*sigh* Frogs!

Yes, I could place the code for all the own Gadgets in one include file... but behind this philisophy stays an idea (of course)
If I want to code an app with own Gadgets, but with minimum overhead, then I include every "own-gadget file" seperate if I need it.
In projects, where this overhead is not relevant I include the complete "library file" which includes all the own gadgets.

Do you have other suggestions?

[Kaeru Gaman]

to my knowledge, Procedures that are not called at all are not included.
one limitation: Procedures that are called from uncalled Procedures are included.

I'm not sure if it was improved meanwhile....

so I would concentrate on keeping the Call-Tree clean to make the compiler not include the not needed Procs, instead of splitting it into uncountable many single includes.

[Kurzer]

so I would concentrate on keeping the Call-Tree clean to make the compiler not include the not needed Procs, instead of splitting it into uncountable many single includes.

Hmm, it is worth thinking about.

[freak]

> @freak: Thats right, but what speaks against an internal include filelist for the IDE, which is updated every compile run?

That would just be an heuristic method as well. If it sometimes works and sometimes doesn't then it is of no real use. (Not speaking about all the bugreports we would get by people who think it does not work right)

[Kurzer]

That would just be an heuristic method as well. If it sometimes works and sometimes doesn't then it is of no real use. (Not speaking about all the bugreports we would get by people who think it does not work right)

Hm, now I'm confused and I dont undestand the problem. Let's start from scratch.
Both, the sourcecode which is opened in the IDE and the source files which are assigned to a project have to be scanned for new procedures at a certain time.

Why not extend this scan to the files which are included in this files? Actually you have to scan the included files only the first time except they are open in the IDE.

[freak]

Example:

Code: Select all

CompilerIf #DEBUG = 1
  XIncludeFile #DebugDirectory + "Debug.pb"
CompilerElse
  XIncludeFile "Normal.pb"
CompilerEndIf

Which one would you scan? And how do you find the first file at all?
Keep in mind that constants can be defined on compilation via the commandline or the Compiler Options. The information about which file to use may not be in the code at all.


Lets say you have a solution to that problem. Consider then the following configuration:

FileA.pb (main file)
FileB.pb (included from FileA.pb)
FileC.pb (included from FileA.pb)
FileD.pb (included from FileC.pb)

• First you edit FileA
  From a recursive search the IDE could find/display info from all files correctly.
• Now you edit FileB
  There is no information inside FileB that tells the IDE that it is included into FileA. So all you get is stuff from FileB itself.
• Now you edit FileC
  Still, no way to reach FileA but FileD can be found. So you get the stuff from FileC and FileD here.

If the information you get from the Autocomplete varies that much depending on which file (in the same program) you edit then it will just be frustrating to use and not help productivity at all. This is why the project feature exists where you can define exactly which files you want scanned so you get consistent results every time.

[Fred]

Remember than having a 'mostly' working feature is useless, as you will not trust it anymore once you will hit an issue.