You are here

require feature: assign the loader's parameter in appinfo.ini. -- ShellExecure(.., LPCTSTR lpParameters , ..)

4 posts / 0 new
Last post
freenod01
Offline
Last seen: 10 years 10 months ago
Joined: 2012-08-26 01:45
require feature: assign the loader's parameter in appinfo.ini. -- ShellExecure(.., LPCTSTR lpParameters , ..)

1. Detail:
the Platform-Menu use ShellExecute to run the loader, which is from appinfo.ini -> Control -> Start.
In the source we can see:
ShellExecute(0,'open', ###CommandLine, Nil, ###WorkingDirectory, SW_SHOWNORMAL);

the 4# parameter is "LPCTSTR lpParameters", and its value is nil.

What I want is that I can config the lpParameters in appinfo.ini

2. Why:

for me, the PortableSuite is not only an portable softwate collection, but also an GreenSoftware launcher.

there are too much Green Software.
sometime PortableApps.com Launcher or Installer is too heavy.

what I want here is only:
display an item in PortableApps.Menu. with icon, with ExePath, with ExecParameter, with StartDirection.

the ExecParameter is very important, ex: assign the DataDir while under NTFS ACL.

John T. Haller
John T. Haller's picture
Online
Last seen: 40 min 3 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Coming In Platform

The ability to assign a command line parameter is coming within the platform itself shortly, as well as assign an icon, working directory, etc, for custom entries. So you won't even need an appinfo.ini for non-PAF apps you want to customize.

Incidentally, the PA.c Launcher can be as lightweight as you'd like as it can simple pass a parameter to the exe to start it and then exit without needing to wait around, meaning that it would use no additional memory or resources other than a bit over 100KB on disk. You can even make use of PAL's abilities to adjust paths and such in this state as an app moves around to make it truly portable instead of just green.

Sometimes, the impossible can become possible, if you're awesome!

freenod01
Offline
Last seen: 10 years 10 months ago
Joined: 2012-08-26 01:45
I still want it

Thanks for replying.

This is important feature, and I still want it.

I don't know how Platform implement this, but any way, I still want this parameter was supported in appinfo.ini, only in the case that the appinfo.ini will be discarded.

1. It way so easy, maybe only one line code, and no any other problem like security. (of course, some document or generator of appinfo.ini need update)

2. For security. To me, any extra data from individual is untrused. So if I can show an appinfo.ini and tell other to download any binary from offical website, it seems not bad.

John T. Haller
John T. Haller's picture
Online
Last seen: 40 min 3 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Won't Be, Different Purpose, This is What It does

It won't be coming to the appinfo.ini. The reason is that it would violate the PAF spec. An individual needs to be able to use a PAF app *without* the platform. And only the platform would use that command line in the appinfo.ini. Part of the PAF spec is that there needs to be a single EXE in the root of each app that launches the app with all the necessary information. If part of the way an app worked was contained in appinfo.ini, then an end user could mess it up by running an app directly either in the root or buried somewhere in the sub-directories. The whole point of PAF apps is for them to be foolproof. Download, portable install, run the AppNamePortable.exe launcher. Easy as pie.

So, as a developer packaging said apps, you're best option is to use the PA.c Launcher. In the AppNamePortable.ini file within AppInfo\Launcher, there you specify the command line parameters and everything else. In fact, if you're just trying to package up a portable app that exists in App\appname\appname.exe and needs a command line parameter fed to it that points it to its data in the Data directory and the launcher doesn't need to adjust paths or clean anything on exit, your AppNamePortable.ini would be simple:

[Launch]
ProgramExecutable=AppName\AppName.exe
CommandLineArguments=--DataParameter=%PAL:DataDir%\
WaitForProgram=false
DirectoryMoveOK=yes
SupportsUNC=yes

With those first 3 simple lines, it will cause the PA.c Launcher generated in the root of your apps to act as a simple portable shortcut, launching the app with the appropriate command line and exiting. That way users get to easily use the app correctly with or without the PA.c Platform. The last 2 lines are to let PAL know if an app can be moved between directories without issue (otherwise it will warn you by default) and if it can properly run from a UNC path aka network drive (otherwise it will assume it can't).

The ability to add command line parameters in the platform is for end user use and so advanced users can do specific things within apps easily (like launch Firefox in safe mode) and be able to take non PAF apps that require a command line and be able to add them to the platform without having to use a launcher or bat file.

Sometimes, the impossible can become possible, if you're awesome!

Log in or register to post comments