REM!Icon

[mavison]

I have a png file for my application which I can select on the Create Application Bundle page for SDL v0.25.
However, it has to be re-selected for each compile.

I have also tried including compiler directives:
REM!Icon xxx.png
REM!Icon @dir$+"xxx.png"
but neither seem to have any effect.

Have I got the syntax wrong, or does this not work for the SDL version?

[guest]

Have I got the syntax wrong, or does this not work for the SDL version?

It does not work in SDLIDE. Something else to add to the 'wish list'.

[mavison]

Thanks.

In the same Compile area, if I need to use Add @dir$ to include a text file in the application, it works fine.
However, when repeating the compile, the file is not automatically included so have to use Add @dir$ each time. I could use REM!Embed, but I would also have to add in many libraries that are INSTALLed (and ensure they are kept in step).

REM!Crunch does seem to work!

[guest]

However, when repeating the compile, the file is not automatically included so have to use Add @dir$ each time.

Yes, as documented and explained in the thread announcing v0.25a.

I could use REM!Embed, but I would also have to add in many libraries that are INSTALLed (and ensure they are kept in step).

You no more (or less) need to "ensure they are kept in step" if you use REM!Embed than with the BB4W-style facility of extracting the information from an existing executable. In neither case will additional libraries be automatically embedded, nor will no-longer-needed libraries be removed - you must do it manually. Of the two methods, using REM!Embed is preferable because it's tied to the program's source code - where it should be - rather than to an executable that might have been deleted or moved.

In my opinion there is already adequate flexibility in the way that embedded files can be specified. You can either use REM!Embed which overrides the automatic program scan (so only files specified in REM!Embed directives are included), or you can list the files in regular (non-directive) REMs so they are picked up in the scan:

Code: Select all

      REM!Embed @lib$ + "socklib"  [will embed only socklib and other files included in REM!Embed directives]
      REM embed @lib$ + "socklib"  [will embed socklib plus any other files found in the automatic scan]

[mavison]

Thanks. I had missed the 'REM Embed' facility, but I have decided to use 'REM!Embed' as it seems to give most consistent results - though I did have to remove them to find the font file that I also needed to manually add.

[guest]

I had missed the 'REM Embed' facility

The "Embed" part is ignored (it could be anything, or nothing). It's simply leveraging the fallback program scan which looks for references to @dir$ and @lib$ in any context on any line, as in BB4W.

I have decided to use 'REM!Embed' as it seems to give most consistent results

Both methods are "consistent" (or at least they should be!) but using REM!Embed avoids the inclusion of embedded files which you don't want to be embedded. For example your program might refer to @dir$+"image" in a context where the extension defaults to '.bmp' at runtime but the auto-embed scan assumes the extension '.bbc'.

I did have to remove them to find the font file that I also needed to manually add.

I'm not sure why you would ever have to "remove" them. If you omit a file that should have been embedded you will (unless your error handling is broken) receive an error message at run-time alerting you to the fact, at which point you can simply add it.

[mavison]

Thanks Richard for v0.26a, which says it now supports the REM!Icon directive.
However, I have tried both

Code: Select all

REM!Icon   @dir$ + "cvs.png"
REM!Icon   @dir$ + "cvs.png" ,0

but it just seems to display a blank icon in the Create Application dialogue.
Manually selecting it displays (and uses) the png correctly.

[guest]

However, I have tried both

Code: Select all

REM!Icon   @dir$ + "cvs.png"
REM!Icon   @dir$ + "cvs.png" ,0

I'm puzzled that you evidently expected the REM!Icon compiler directive to work differently from how it does in BB4W. That was never my intention; indeed my assumption has been that one might want to write a 'BB4W-BBCSDL agnostic' program that can not only run in both interpreters but which includes compiler directives that are understood by both IDEs. That's why if you specify the target as a .exe (which you would in BB4W) the extension gets changed to .zip or .dmg in BBCSDL. Similarly if you specify the icon as a .ico (which you would in BB4W) the extension gets changed to .png.

So you should find that if you use compiler directives as you would in BB4W that they will work correctly in BBCSDL. Directives that refer to a file that is used at compile time (such as the target application or the icon) take an ordinary relative or absolute path. Directives that refer to a file that is used at run time (such as an embedded resource or library) expect @dir$ or @lib$. That seems consistent to me, but I will not be surprised if you disagree.

[mavison]

I had not expected the SDL version to work differently, and I agree the versions should behave the same where possible.
However, a manual specification requires the selection of the file cvs.png, and the BB4W help just refers to 'a file' ehich is either an EXE or ICO file. I was unsure if BB4W handled PNG files, but SDL does.
For the SDL version, I tried many variations on cvs.png with no success, assuming that I had specify the PNG file as selected manually.
From your post and the BB4W help I tried cvs.ico,0 and cvs,0 neither of which show the icon in the Create App dialog.

Sorry, but I am obviously misunderstanding.
What should be used in REM!Icon for a PNG file in the same directory as the program being compiled ?

[guest]

Sorry, but I am obviously misunderstanding.

No, you're not. It turns out that the REM!Icon compiler directive doesn't work as intended, sorry. My testing led me to believe that it was working, but it was doing so only because of a fluke. Currently the only way to make it work is to specify an absolute path to the icon file (the same is true of the REM!Exefile directive which must also be specified as an absolute path).

I'm not currently sure how or if I can fix it so that a relative path works, but fortunately BB4W also accepts absolute paths so it's still possible to use compiler directives in a cross-platform way.