New inline FBC code block (GoRC) for resource script ?

[fxm]

Why create this new inline FBC code block for resource script ?
- In order to avoid to waste one individual resource-definition script file (*.rc) that describes rudimentary resource(s) used by the program (or in case of resource editor not necessary), it may be possible to insert the specific script directly in the source program (*.bas) inside this new code block.
- Similarly principle as for Asm code block.
- FBC may compile the included resource script with GoRC and embed it in the application, as for external *.rc file.

Proposition of syntax with elementary example :
. . . . .
GoRC
FB_PROGRAM_ICON ICON fblogo.ico
End GoRC
. . . . .

or
. . . . .
GoRC FB_PROGRAM_ICON ICON fblogo.ico
. . . . .


What is your opinion ?

[Fox]

What is your opinion ?

+1

Every time I need to add an icon to my program at compile time, I'm wondering "wow, how easier it would be if I could simply add the icon-ressource definition right into my source code!"

[dkl]

Understandably this would be useful, but what should fbc -c make of it? It would have to create one .o and an additional file, like .rc.o. That's not nice for build systems (e.g. makefiles). And this construct would be Windows-only. Do we want a Windows-only FB language element?

[fxm]

See below a very rustic example of proposed implementation

Until now:

source file "Main1.bas":

Code: Select all

Print "Hello!"
Sleep

resource file "Script.rc":

Code: Select all

 FB_PROGRAM_ICON ICON fblogo.ico

fbc command-line:

Code: Select all

fbc [options] Main1.bas Script.rc [other files ]

in [other files], there may be other files *.bas or *.a or even *.rc


Changes proposed:

extended source file "Main2.bas" (including the resource script block):

Code: Select all

GoRC
   FB_PROGRAM_ICON ICON fblogo.ico
End GoRC
Print "Hello!"
Sleep

fbc command-line:

Code: Select all

fbc [options] Main2.bas [other files]

in [other files], there always may be other files *.bas or *.a or even *.rc

The compiler could then:
- first create a temporary resource file "Main2.rc" (for example) with the content of the block GoRC ... End GoRC,
- then compile as though the command line was:

fbc [options] Main2.bas Main2.rc [other files]

no more taking into account the content of the block GoRC ... End GoRC in the file "Main2.bas".

Understandably this would be useful, but what should fbc -c make of it? It would have to create one .o and an additional file, like .rc.o. That's not nice for build systems (e.g. makefiles). And this construct would be Windows-only. Do we want a Windows-only FB language element?

- Options in the fbc command-line:
See proposed solution above.

- Windows-only FB language:
There are already instructions are not supported by all platforms (eg, dynamic link libraries are not available in DOS, multithreading is not supported by DOS).

[marcov]

Why create this new inline FBC code block for resource script ?
- In order to avoid to waste one individual resource-definition script file

What is exactly "wasted" ?!? I'm not really sure what problem this solves.

Instead of stuffing the whole program in one file, maybe strengthening the project concept of FB is a better direction? Now the only options seem to be to manage your project manually and externally (make) or to do stuff everything in one file, which is not exactly elegant for anything but trivial projects.


dkl: many projects support .res on other systems. Not the nicest solution, but no existing resource system is truly portable, and at least the windows one is integrated into the file and still editable (and not requiring a special filesystem provision like e.g. the Mac equivalent)

All non-trivial file formats provide custom sections to stuff some form of resources into, and then using windows structures is compact and easy, and source for editors and compilers can be found.

Of course it only gets important when you go in the direction of a designer or want in-file translation options. (e.g. we can integrate gettext files into the internal resource system)

[fxm]

Why create this new inline FBC code block for resource script ?
- In order to avoid to waste one individual resource-definition script file

What is exactly "wasted" ?!? I'm not really sure what problem this solves.

In the worst case, spend a file.rc for just one line of script.
See my second post.

[dkl]

It's tempting, I think there are no technical problems with it. I wanted to note a few things:

• Preserving block "scope"? Put each such block in a separate temporary .rc script.
• Compiling/linking separately? Use fbc's objinfo functionality to compile the resources at link-time. That also means FB libraries can be made to add resources to your executable when used.
• Preprocessing? Should then be done by fbc's preprocessor, so the blocks are compatible to both GoRC and binutils' windres.
• Do the resource blocks conceptually belong inside your program's source code? Is this a question of project management, or are resources rather something like global variables? I could live with the latter.