#PB_Compiler_ExecutableFile

[User_Russian]

I propose add the constants stored path to the compiled executable. This is useful for working with files in a folder with a compiled executable.

[Little John]

I propose add the constants stored path to the compiled executable. This is useful for working with files in a folder with a compiled executable.

Huh? You want the path where a compiled executable is, to be stored as a constant in that executable?
That does not make sense, since executables can and will be moved from one folder to another.

Or do you mean something else?
That please explain it more detailed, in understandable English.

[User_Russian]

That does not make sense

This makes sense during debugging (run in IDE PB).
Assume that the source code is in the "C:\folder_1\folder_2\".
The executable file is compiled into "..\" that is in "C:\folder_1\".
In the folder with the executable file is located a configuration file, etc. files. Is necessary know the path to the compiled executable file for use these files.

[Keya]

can you not use ProgramFilename() at runtime?

[User_Russian]

ProgramFilename() returns the path to the temporary executable file that is located in a temporary folder or in a folder with the source code. It's not that is necessary.

[Little John]

Assume that the source code is in the "C:\folder_1\folder_2\".
The executable file is compiled into "..\" that is in "C:\folder_1\".
In the folder with the executable file is located a configuration file, etc. files. Is necessary know the path to the compiled executable file for use these files.

Code: Select all

Debug #PB_Compiler_FilePath + "..\"

or

Code: Select all

; Compiler Options > [v] Create temporary executable in the source directory
Debug GetPathPart(ProgramFilename()) + "..\"

[User_Russian]

Not known in advance where there will executable. Its location may change at any time and can forget to change the source code by specifying the correct path to the executable.

[Little John]

Not known in advance where there will executable. Its location may change at any time and can forget to change the source code by specifying the correct path to the executable.

And where exactly should the path to the executable be stored??
Storing it in the exectuable itself doesn't make sense.
And when the location of the executable may change at any time, how could then PB know where it is?

[User_Russian]

Storing it in the exectuable itself doesn't make sense.

This makes sense during debugging (run in IDE PB).

[juror]

In that case make it #PB_Debug_ExecutableFile

[Little John]

Storing it in the exectuable itself doesn't make sense.

This makes sense during debugging (run in IDE PB).

For the reasons that I wrote, up to now it doesn't make any sense to me (regardless how often you repeat some short sentences).
How exactly could this feature be used in debugging?

And when the location of the executable may change at any time, how could then PB know where it is?

When you believe that your suggestion makes sense, then why don't you explain in detail how it should work?

[User_Russian]

When you believe that your suggestion makes sense, then why don't you explain in detail how it should work?

I already wrote why this is necessary.

This makes sense during debugging (run in IDE PB).
Assume that the source code is in the "C:\folder_1\folder_2\".The executable file is compiled into "..\" that is in "C:\folder_1\".
In the folder with the executable file is located a configuration file, etc. files. Is necessary know the path to the compiled executable file for use these files.

[Little John]

Sigh ... last try.

When you believe that your suggestion makes sense, then why don't you explain in detail how it should work?

I already wrote ...

Yes, you already wrote this and that.
But you still did not explain in detail how such a constant could help solving the problem -- although I have asked repeatedly.

Not known in advance where there will executable. Its location may change at any time and can forget to change the source code by specifying the correct path to the executable.

So how can a changing path be stored in the constant #PB_Compiler_ExecutableFile?
And how exactly can it be used for debugging?

[User_Russian]

So how can a changing path be stored in the constant #PB_Compiler_ExecutableFile?
And how exactly can it be used for debugging?

Code: Select all

CompilerIf #PB_Editor_CreateExecutable
  Path.s = GetPathPart(ProgramFilename()))
CompilerElse ; Debug mode.
  Path.s = GetPathPart(#PB_Compiler_ExecutableFile)
CompilerEndIf

OpenPreferences(Path+"Setting.ini")
; Other code.

Thus, the program will use the same files.

[TI-994A]

I propose add the constants stored path to the compiled executable. This is useful for working with files in a folder with a compiled executable.

I'm assuming that you're proposing the addition of a pre-defined target for the executable, as is normally found in other programming IDEs, where debug and release folders are implemented.

PureBasic provides this limited option for the temporary (debug) build, but not for the release build:

Create temporary executable in the source directory
With this option turned on, the temporary executable file for running the program from the IDE will be placed inside the source directory. This can be useful if the program depends on files inside the source directory for testing. With this option turned off, the executable is created in the systems temporary directory.

With such an option for the release build, the paths of the various dependencies within the code could remain relative to that folder instead of the folder of the temporary build.

That does not make sense...

That please explain it more detailed (?), in understandable English.

But you still did not explain in detail how such a constant could help (in) solving the problem -- although I have asked repeatedly.

So how can a changing (changeable?) path be stored in the constant #PB_Compiler_ExecutableFile?

It's truly bad form to disparage the language aptitude of our international friends; especially when you are clearly no grammarian yourself, Herr LJ.

In any case, when did you become the sheriff of the Feature Requests and Wishlists forum.