[Gambas-user] Gambas script gbs Application.Path Args
bsteers4 at gmail.com
Mon Nov 2 18:31:55 CET 2020
On Mon, 2 Nov 2020 at 16:45, Benoît Minisini <g4mba5 at gmail.com> wrote:
> Le 02/11/2020 à 17:30, Bruce Steers a écrit :
> > Hi Benoít.
> > Would you consider this simple modification to gbs3?
> > I've made the scripter set up 2 Env variables as it runs as script.
> > Env["Application.Path"] and
> > Env["Args"]
> > I've tested it and it works great :)
> > Cheers
> > BruceS
> As I said, converting a normal application to a script is a non-sense.
> Just provide the source of the application and a little script that
> compiles and runs it.
I disagree. I see great potential for scripting here. It could well replace
bash scripting for me.
To have an easy to edit text script written in basic with all the gambas
bells and whistles that quick launches without having to load IDEs,
comipie, move exe's to dirs etc, just have a gambas script in a dir and
This is great.
I think you are underestimating the potential of what you have created here.
As for converting i see many reasons for doing so , say i have an app that
i would like to be slightly different depending on certain circumstances, i
could create many different gambas projects, or code the app to set up
differently depending on said circumstances or even simpler, create a base
app using the IDE and convert it to a script and copy the script to each
folder and modify as required.
another reason is to create/test the application using all the features of
the IDE, something you cannot do writing a script until the IDE also
supports script editing/debugging/etc. once the app is made (that you want
to be a script for whatever reason) then convert it.
I'm not sure of the exact purpose you have for making the scripter but I
see many many uses for it. with a few minor adjustments it could be perfect
for so many things. (I say a few, this Args thing is the only fallback
> As for your proposal (which does not depend on my previous remark), even
> if it works great, it's awful in my opinion. Instead there should be a
> way of overriding Application.Path and Args.
Well yes that was my initial thought when looking into seeing what could be
done but from examining the code i see it just creates a temporary project
folder and makes a project then uses "*standard*" launching method of the
so it does not really create it's own app to be able to modify
Application.Path property it's just using standard gbr3 to launch an app in
a temporary location thus rendering Application.Path and Args pretty
So i figured gbr3 would need to be modified somehow to be able to tell it's
the scripter launching it to modify Application.Path?
If you have a better idea I have the time to look into it if you point me
in the right direction.
My solution there I wouldn't call "awful" to be fair, I'd say "not ideal,
but a suitable workaround" ;)
but by the nature of how the scripter works there seemed little alternative?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the User