$INCLUDE

[krovit]

Good morning

$INCLUDE does not support variables.
Is it very difficult to predict this in one of the next versions?

It would be very convenient to be able to assign a variable more or less like this:

var$="path-file-include"
'$INCLUDE: var$

[krovit]

Sorry if I insist... I know it's easy to talk... but just to know...
Is it a possible thing or can never exist?
And if it were possible one day we could see it realized?

[SMcNeill]

Sorry if I insist... I know it's easy to talk... but just to know...
Is it a possible thing or can never exist?
And if it were possible one day we could see it realized?

It’d probably work with the precompiler, if someone wants to take time to add the functionality it.

$LET var$=“path/include/file.bm”
$INCLUDE:var$

The only real issue would be finding someone who has time and nterest in making the necessary changes to qb64.bas.  ;)

[krovit]

Well... then there is at least one hope... (it would be really useful), thanks

[FellippeHeitor]

Included file path must be known at compile time. Making it a “variable” would just get you to type more to achieve the same we currently have. The above doesn’t look any more practical.

[krovit]

When writing standard code parts that are good for many programs it would be convenient to be able to include them when needed.

For example, it would be possible to write an application "variable" that now includes code A now code B and now the C code turns into as many different applications in a few moments and without the possibility of error.

It would be really useful but if it is a complication too demanding patience.

:)

[FellippeHeitor]

You’d still have to recompile the application each time, changing the line of the “variable” to point to a new file path.

What is it I’m not seeing?

[SMcNeill]

For example, it would be possible to write an application "variable" that now includes code A now code B and now the C code turns into as many different applications in a few moments and without the possibility of error.
:)

Isn’t this possible with the precompiler, such as how the saveimage library chooses between 32 and 64 bit DECLARE LIBRARY statements, and how the ColorAll library changes color values per screen usage?

$LET KOLOR = 32

$IF KOLOR = 0 THEN
    $INCLUDE:’Color0.BI
$ELSEIF KOLOR = 32 THEN
    $INCLUDE:’COLOR32.BI’
$ELSE
    $INCLUDE:’COLOR256.BI’
$END IF

[krovit]

Every time I marvel at your willingness to speak and explain!

I have a fixation for the code "parametric" that provides almost everything and makes the necessary choices according to the situation. it's hard to write code that needs to be modified here and there to fit new needs.

I then write "modules" which I then assemble by passing only a few parameters.

It already existed with QB45 (MAK files). For example, I could write a TXT file where I list the modules you need. Then I load the main program into the editor, he reads it and simple to compile it without touching anything. Done!

If a module inside, though, loads a piece of code to include I have to do so many versions of that module: one for each piece to include. If I could pass a variable at the beginning it could do it by itself.

Alternatively load even a lot of useless code: it works the same but getting lost in thousands of lines is easy!


Anyway thank you very much for the work you do!

[krovit]

QB64 is not as appreciated as it should!

Being productive in earnest is not easy: QB64 is reserved for those who want to be damned by writing line by line everything! Perfectionists, usually, theoretically, have nice ideas but realizing them is something else..

The applications we all know are written by computer science geniuses that use semi-automatic development systems designed and made by even larger genes than them.

QB64 is for "artists", small craftsmen who spend the night "creating" and developing small big ideas... without seeing the end (usually!)

In a word: masochists! (... I speak for myself, of course). Or idealists (which is better...).

;)

[krovit]

Here's an example where the variable would be convenient:
'$INCLUDE: 'path' works differently if the file is in one location or another.

In other words, you can't always navigate forward or backward or parallel in the path because it can't find the file to include even if the address is formally correct.

Depends on where it is $INCLUDE.

Works only if the absolute path is supplied, including the root (for example, C:). But this forces us to always work on C: rather than carrying everything on D: or other relative path.

We would write, for example and for go up in the path: "..\Folder2\Subfolder\file.bi". With $include no: we must write "c:\Folder2\Subfolder\file.bi".

And this can create some problems.


I wonder if I could explain myself...

[FellippeHeitor]

$INCLUDE does accept relative paths as is.

[krovit]

Thank you Filippe,

but let me give a concrete example (see attached folder with 2 BAS files)

[FellippeHeitor]

Exactly. These relative paths all work.

Code: QB64: [Select]

1. '$INCLUDE: 'Folder2\fileA.txt'
2. '$INCLUDE: 'Folder3\fileB.txt'
3. '$INCLUDE: 'Folder2\Folder2A\file2A.txt'

  [ You are not allowed to view this attachment ]  

Notice that the link with "Double click to open" only shows when the file is found and properly included.

For what it's worth, I did not place your files in my QB64 folder. Are you saying you get an error message using relative paths?

What version of QB64 are you using in what OS?

[krovit]

no... look at file2B.bas in Folder2A.

The relative path works yes, but it just looks forward... back or sideways no