Program command and parameters with SDL 0.25a

[mavison]

Now that a SDL 'Compile' is available (thanks Richard!) I have been trying to access the command line within a program on both Windows and OSX versions, so I can read the command and parameters from the IDE, plus non-compiled and compiled runs.

Is there an SDL equivalent of the BB4W SYS "GetCommandLine" TO cmdline% ?
Should @cmd$ hold the 'command tail' ?

Is it true that a version compiled for a platform can only be generated on that platform?
I was hoping I could Compile a version for OSX on Windows - but I can see why that might be difficult.

[guest]

I have been trying to access the command line within a program on both Windows and OSX

Reading the 'command line tail' is not currently supported by BBCSDL (it is used internally by the IDEs to pass the name of the program to be executed to the run-time engine). I could consider adding that capability in a future release, but the specified parameter would need to have the form of a 'switch', i.e. be prefixed by a hyphen:

Code: Select all

myapp -my switch 

It would also need to avoid clashing with the built-in switches '-fixedsize', '-fullscreen' and '-hidden'.

[mavison]

Reading the command tail with a hyphen would be fine for my purposes, if the whole command line is not available. Indeed, '-parm xxx' would also be ok.

I had also thought about setting an OS variable and reading the value in the program, but I have not investigated if that could or would work in Windows and OSX.

[mavison]

I have tried adding '-t' to the end of a command to run an exe program compiled with v0.26a in Windows to check the new ability (thanks Richard) to use @cmd$.

However, although the -t does appear in @cmd$, it seems to change the value of @dir$ from the directory the program was loaded from, to the directory the command file was in that contained the appdir\app.exe -t command.

Is this expected behaviour? - it causes the program to fail because the INSTALLed files can no longer be found.

I have not yet had chance to try on a Mac.

[guest]

Is this expected behaviour?

Unlike BB4W, there is no capability in BBCSDL of creating a 'true' standalone application such as a PE (.exe) file. There is just one 'executable': bbcsdl.exe (in the case of Windows) and when the Create Application facility builds an 'application bundle' the executable contained therein (for example myapp.exe) is the very same file, simply renamed!

This 'dual purpose' nature of the BBCSDL executable leads to the behaviour of @dir$ that you observe. When SDLIDE (or BBCEdit) runs the BASIC program listed in the editor (or when you do so manually), it executes a shell command such as:

Code: Select all

bbcsdl myprog.bbc

Obviously in this situation @dir$ needs to point to the directory containing 'myprog.bbc' (the 'program') - the 'current directory' in this case - not to the directory containing 'bbcsdl.exe' (the 'run-time engine'). Only that way will the program 'myprog' be able to find its resources stored in @dir$. You are running the identical executable (albeit renamed, in the application bundle) but now you want @dir$ not to point to the current directory but to the directory containing the exe!

You can see where this is going: the preference for where @dir$ should be pointing is different in the two cases, but the executable that is being run is identical! All hope is not entirely lost; BBCSDL could in principle distinguish between the two cases: in one the 'command line tail' starts with the name (and optionally path) to a .bbc file, and in the other it doesn't.

Edit:
Unless and until such a change is made, as a workaround you could change your batch/script file to include the path and name of the .bbc file:

Code: Select all

\path\to\myapp.exe \path\to\myapp.bbc -command line parameters

I have not yet had chance to try on a Mac.

I'm not sure whether there's any way of passing command line parameters on a Mac, since what you are 'executing' is the .App bundle. Unless MacOS is clever enough to 'forward' the command line tail to the actual executable it will be lost; maybe it is, I have no idea. Or maybe your script can run the true 'executable' within the bundle. This is all way outside my area of knowledge.

[mavison]

Because it seems that with SDL and/or MacOSX it is impractical to pass a parameter in to a program when started, it would be useful to be able to detect within a program whether it was running a 'Compiled' version or normally, as wll as Windows or Mac. (Although I understand that Compiled and normal versions should behave the same!)

The only ways I have found to detect a 'Compiled' version is running are:
- In Windows when @lib$ contains the app program name;
- In MacOSX when @dir$ = "//"

Is there a better way than these nasty hacks?

[guest]

Because it seems that with SDL and/or MacOSX it is impractical to pass a parameter in to a program when started

I suggested executing the program within the app bundle (which in MacOS is just a directory) rather than executing the app bundle itself; in principle that should allow you to pass command-line parameters in the usual way. Have you tried that?

it would be useful to be able to detect within a program whether it was running a 'Compiled' version or normally

As I explained before, the Run Time Engine used by the IDE is the identical file to the Run Time Engine used in the app bundle. You can tell how it was called easily enough (just examine @cmd$) but there's no foolproof way of determining whether the program was 'compiled'.

- In MacOSX when @dir$ = "//"

Any technique which relies on the value of @dir$ is likely to break in the next release, because you asked me to change the way it behaves! Specifically, @dir$ will point to the directory containing the Run Time Engine, which is what you requested.

Perhaps if you explain what it is you are trying to achieve I might be able to suggest an alternative approach.