AutoRun LWMenu

If you are currently developing portable freeware or planning to do so, use this forum to discuss technical implementation, seek out like-minded developers for partnership, or solicit interested users for beta testing.
Message
Author
User avatar
sl23
Posts: 84
Joined: Fri Jan 02, 2015 6:25 am

Re: AutoRun LWMenu

#256 Post by sl23 »

Sorry, your suggestion? You mean with asking the dev about it? No response yet, as he said, he's busy for next couple weeks, so just have to wait for now.:(

I won't be using that section as I won't be using this launcher in that way. So that means I can actually remove the whole [AutoRun] section then, yes? :)
Latest X-Launcher_x64 update - Compiled with Aut2exe_x64.exe v3.3.16.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1

User avatar
sl23
Posts: 84
Joined: Fri Jan 02, 2015 6:25 am

Re: AutoRun LWMenu

#257 Post by sl23 »

lwc wrote: Tue Jun 04, 2024 10:27 am There's 1 potential rule I think is worth to try out - full paths. Create c:\something\appdata and then use full paths in setenv:

Code: Select all

[BUTTON1]
buttontext=Stem Roller
closemenuonclick=1
relativepathandfilename=App\StemRoller\StemRoller.exe
setenv=USERPROFILE|c:\something
setenv=APPDATA|c:\something\appdata
Ok, so I found this after re-reading the last page!
Well, this works!!! :shock: :roll:
Why do absolute paths work, but relative paths don't?

Would it be difficult for you to change how the AutoRunMenu works? So instead of working from the App\StemRoller\StemRoller.exe directory to look for and run the app, could you change it to the AutoRunx64.exe folder? I just think it's a tidier way of working whilst keeping user data separate from the app data directory.

I also attempted more variations for the relative path, using the current User folder, so, MyApps\StemRoller\User\AppData and also, MyApps\StemRoller\App\stemroller\AppData. Tried loads of variations nothing works. Trying as I type this...

OH...MY...GOD!!! Seriously? The reason relative paths aren't working is because you have to specify the USERPROFILE path with a bloody '..\' even though it's in the same directory! :lol: :lol: :lol:
This works:

Code: Select all

[CUSTOM CD MENU]
skiptobutton=1
singlerun=1

[BUTTON1]
buttontext=Stem Roller
closemenuonclick=1
relativepathandfilename=App\StemRoller.exe
setenv=USERPROFILE|..\User\
What I don't understand, is why I have to specify '..\' when the User folder is actually within the 'App' directory?

If I set the User\AppData directory at the same level as the App\StemRoller.exe directory, This code doesn't work: setenv=USERPROFILE|..\..\User\

But setting the the AppData directory as App\User\AppData then this works: setenv=USERPROFILE|..\User\ very odd!

Btw ONLY setenv=USERPROFILE works. setenv=APPDATA does not work. At least this is how it works for StemRoller. Other apps may be different. Some aren't so stubborn in my experience.

Edit:
At first I thought it was a trailing '\' as that seemed to work, but after removing that I found that it indeed is the '..\' at the beginning of the path. Which seems really weird when you aren't going up a folder!
Latest X-Launcher_x64 update - Compiled with Aut2exe_x64.exe v3.3.16.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1

lwc
Posts: 284
Joined: Tue Jun 26, 2012 10:40 pm
Contact:

Re: AutoRun LWMenu

#258 Post by lwc »

Glad my theory worked! I had a hunch it would when it popped up in my head.

You should be able to remove the [AutoRun] section if you want, as it's for Windows, not for my launcher. The original concept was to just "ride" on that file since it exists anyway and also thus get the menu to open up automatically when the device hooks up. Who knew a few years later external devices (especially CD-ROM/DVDs) will be a thing of the past...

Do absolute paths also not work on APPDATA? If so, in the case of Stem Roller it seems to indicate the author accidentally looks for %USERPROFILE%\appdata\roaming\ not caring it could be a different folder (it's probably very rarely a different folder, which is why the author never got complaints).

Anyway, to continue my theory my guess is that the ..\ part tricks it to think it's an absolute path. Maybe Windows automatically translates paths with ..\ to absolute paths.

BTW, you can use programpath= "to define an alternative starting folder than the launched program's one". It can be relative.

As for setenv, I guess I can behind the scenes translate relative paths to absolute ones, but that means blocking users that really do want relative paths.
I can limit it to just when it's USERPROFILE though, but maybe other too? No one knows which ones, unless you can find documentation...
Alternatively, I can add a command like "setenvExpand=1", so only if you use it, I will turn relative paths to absolute ones.
Last edited by lwc on Thu Jun 06, 2024 1:13 am, edited 1 time in total.

User avatar
sl23
Posts: 84
Joined: Fri Jan 02, 2015 6:25 am

Re: AutoRun LWMenu

#259 Post by sl23 »

Sorry if that last post was a bit of a mess! Was tired!

I'll try to explain better...

ROOT folder is called ARM-StemRoller to differentiate from my other, X-Launcher, version of the installation. ARM = AutoRunMenu. If I fail to specify, I'll say it now... I always use the x64 version of ARM.

AutoRunx64.exe is renamed here:
ARM-StemRoller\ARM-StemRoller.exe
ARM-StemRoller\Autorun.inf

StemRoller App is here:
ARM-StemRoller\App\StemRoller.exe

If I set up stemroller's appdata folder like this:
ARM-StemRoller\App\User\AppData\Roaming\stemroller\(config files here)
It works correctly by using this ARM code:

Code: Select all

[CUSTOM CD MENU]
skiptobutton=1
singlerun=1

[BUTTON1]
buttontext=Stem Roller
closemenuonclick=1
relativepathandfilename=App\StemRoller.exe
setenv=USERPROFILE|..\User
You have to specify ..\ in the path to the User folder as it won't see it otherwise!
Why do you need to do that if ARM works from the ARM-StemRoller\App directory?

I would prefer to use these paths to the App and AppData folders:
ARM-StemRoller\App\StemRoller.exe
ARM-StemRoller\User\AppData\Roaming\stemroller\(config files here)
ARM-StemRoller\ARM-StemRoller.exe
ARM-StemRoller\Autorun.inf

But every attempt to make that work fails. Do you have any idea why?
Last edited by sl23 on Thu Jun 06, 2024 1:24 am, edited 1 time in total.
Latest X-Launcher_x64 update - Compiled with Aut2exe_x64.exe v3.3.16.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1

lwc
Posts: 284
Joined: Tue Jun 26, 2012 10:40 pm
Contact:

Re: AutoRun LWMenu

#260 Post by lwc »

Does my previous reply help?

User avatar
sl23
Posts: 84
Joined: Fri Jan 02, 2015 6:25 am

Re: AutoRun LWMenu

#261 Post by sl23 »

Thanks for the speedy reply! :D

Tbh, I think if there were some documentation, ie a help file, that includes the information on certain circumstances such as this, that you need to specify ..\ that would suffice. I don't think overcomplicating the usage, as you are suggesting, is the answer. I'd leave as is.

About programpath=... does this then mean that ARM starts from a different folder, ie the one specified? Also, does it matter the order of the code? ie, if I put programpath at the end of the Button 1 code does it matter? Is there a certain order the code is read, or does the ARM.exe automatically sort the code as X-Launcher does?

How do I specify a relative path using programpath=? I'm not sure what the starting point is. Does it mean this path needs to be absolute?
Do absolute paths also not work on APPDATA?
No, Absolute paths don't work, StemRoller runs, but uses the system folders, not the app directory User\AppData. All my efforts failed, but I'm no expert, so maybe I missed something?
Latest X-Launcher_x64 update - Compiled with Aut2exe_x64.exe v3.3.16.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1

lwc
Posts: 284
Joined: Tue Jun 26, 2012 10:40 pm
Contact:

Re: AutoRun LWMenu

#262 Post by lwc »

programpath indeed does just that - it can be relative and the starting point is the launcher.
programpath=. means to start from where the launcher is.
programpath=.. means to start from a folder above from where the launcher is.
programpath=thisfolder means to start from a folder called thisfolder under where the launcher is.
Be careful though, some (many?) programs might not work if you don't launch them from their own folders, because they will look for their DLL files, etc. inside programpath instead.

The order doesn't matter at all. It's not about sorting, it's about my launcher reading everything before it decides what to do.

Regarding Stem Roller, it just sounds like it expects appdata to be a hardcoded folder inside %USERPROFILE%, which only its author can fix.

User avatar
sl23
Posts: 84
Joined: Fri Jan 02, 2015 6:25 am

Re: AutoRun LWMenu

#263 Post by sl23 »

I was just about to let you know that I tested programpath=ARM-StemRoller and it worked. First run was a bit odd though as StemRoller window started but was empty, no text or buttons, just the blue background for about 10 seconds. Subsequent runs work fine, haven't tested a PC restart to see if this would repeat though.

Absolute path worked too, as does programpath=. the single dot at the end works. All these methods make StemRoller portable using your launcher. :D

I have only come across a few apps that seem to struggle with these methods. IObit software completely ignores all attempts, I had to set commands to actually copy data on [Runbefore] and move data back on [RunAfter] with X-Launcher!

Thanks for your help! It's a great little program! Always good to have another portable launcher that's easy to use, once you figure it out :D

Just wondering, during my searching the web to find answers, I found that .bat files can do much of the same things: Launch, move files and folders, setenv, all sorts of stuff. I thought about looking into it, but I was unsure about things like RunBefore and RunAfter the app. I suppose having a dedicated launcher is easier to edit the file for additons changes if you convert a BAT to EXE. What's your take on it? The reason I ask is that if windows can do this stuff natively, why not just use BAT file and convert to EXE? Then there's zero reliance on out of date software!
Latest X-Launcher_x64 update - Compiled with Aut2exe_x64.exe v3.3.16.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1

lwc
Posts: 284
Joined: Tue Jun 26, 2012 10:40 pm
Contact:

Re: AutoRun LWMenu

#264 Post by lwc »

.bat files basically just run other programs in sequence, so if the other programs change, the bat files will break.
A classic example is the choice (command). It allows bat files to present menus, but caused such bat files to be broken in Windows XP, which removed this command (it got back in later versions). So the more programs bat files rely on, the more chance for bat files to become obsolete too.

Even if you decide the risk is low, it means you become the programmer yourself. Instead of tweaking settings, you'll need to tweak code.
And I think bat code is not that friendly, probably has no dedicated development forums, and people who still program in bat (and thus can assist you) probably will be harder and harder to find.
Not to mention bat files might be hard to share as browsers might block them due to many illegitimate uses.

But the biggest downside in my eyes is the constant flashes of black screen that will eventually cause you to ask like others Any way to Hide the command console? and find out the answer is not without an external program, which gets you back to square one.

If anything, use VBS or PS1 files since they're pure Windows' code, but you'll have to do everything in code (and not have advanced features like menus), and they're also likely to get blocked when shared.
Last edited by lwc on Fri Jun 07, 2024 4:36 am, edited 1 time in total.

User avatar
sl23
Posts: 84
Joined: Fri Jan 02, 2015 6:25 am

Re: AutoRun LWMenu

#265 Post by sl23 »

Ok, seems more hassle rather than a better solution! Thanks for the clarification.
Latest X-Launcher_x64 update - Compiled with Aut2exe_x64.exe v3.3.16.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1

User avatar
sl23
Posts: 84
Joined: Fri Jan 02, 2015 6:25 am

Re: AutoRun LWMenu

#266 Post by sl23 »

Hi lwc,

I hope you don't mind, but I have a few suggestions:

1. Ask a moderator to edit the link in the first post so it goes straight to github. Or, perhaps better, add both the GitHub link and the PortableFreeware Listing to your Signature. You could also have the Latest version linked in your signature too. :)

2. I have revised the entire default Autorun.inf in the hope to make things easier to read and added some note from the forum to help newcomers. It's not quite finished yet, so I'll add it here once it is. I've split this into two files. One for the default INF and one as a kind of reference/instruction which you could add to the Help menu.

3. About 'deletefolders' and 'deletefiles' - I would think about changing this to make it easier to understand the logic of programming it. Currently to create a file/folder, you need to use 'deletefile=+' which is a bit confusing for newcomers. Two suggestions:
  • Either remove the 'delete' part and just use 'folder=' to delete and 'folder=+' to create
  • A much better way though would be to add two more commands: 'createfolder=' and 'createfile='
4. If you intend keeping this open source, remove Registration code from source to reduce app size/complexity. Easier for those new to AutoIT to read the code. Or at least have a separate version without the Registration code.
Latest X-Launcher_x64 update - Compiled with Aut2exe_x64.exe v3.3.16.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1

lwc
Posts: 284
Joined: Tue Jun 26, 2012 10:40 pm
Contact:

Re: AutoRun LWMenu

#267 Post by lwc »

  1. Okay, I've reported my own post to request that. Although the old link still points to the new one.
  2. Thanks, but why not the README instead?
  3. The problem as always is backward compatibility. It's either not respecting old settings or keep having to check endless duplicated settings and even clashes.
  4. I think you're mistaking open source to free. Open source programs can be commercial if they want. Anyway, it's just about 100 lines out of 1,500+. The major pain was 2 external libraries which were already commented out a long time ago.

User avatar
sl23
Posts: 84
Joined: Fri Jan 02, 2015 6:25 am

Re: AutoRun LWMenu

#268 Post by sl23 »

1. Thanks.
2. The README is not included in the download or accessible from the menu. It is also very unclear on how to use the launcher. Much needs to be added for those with no programming language skills to use it. I am now trying it with Stremio and again suffering the same issues as with StemRoller. Again, X-Launcher just works. What I'm doing is remaking the default INF, just reducing it to essential operation, very similar to what it was, but without all the comments. Then creating an instructional file with all the text from the default INF, this forum post and the GitHub page, all merged and easy to find and read. This instruction file can then be added to the zip package for users to open and read.
3. Then why not make a version2.0 that changes it and the name of the 'Custom CD Menu' text to 'General' or 'Global'. If you state these changes break backwards compatibility then I'm sure people will get over it. I have around 300 portable apps. Most are SyMenu, a few are PA.com and the rest are updated manually. Out of all the apps I've tried and tested, only a handful require this type of launcher to fully portablise apps. So it wouldn't be hard for people to adapt current set ups.
4. Ok, didn't know OS apps could be commercial.
Latest X-Launcher_x64 update - Compiled with Aut2exe_x64.exe v3.3.16.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1

User avatar
sl23
Posts: 84
Joined: Fri Jan 02, 2015 6:25 am

Re: AutoRun LWMenu

#269 Post by sl23 »

So again, I am having issues creating an AutoRun launcher for Stremio.
Same set up as with StemRoller:
; User AppData folder in ROOT\User:
; ROOT = the main folder where the Autorun EXE is contained.
ROOT\App\Stremio.exe
ROOT\User\AppData\Local\Smart Code ltd
ROOT\User\AppData\Roaming\stremio
ROOT\Autorun.exe
ROOT\Autorun.inf


As far as I am aware, the only system folders created for Stremio are:
AppData\Local\Smart Code ltd
AppData\Roaming\stremio

Procedure for testing:
1. Adjust AutoRun.inf settings.
2. Delete any Stremio folders left behind.
3. Launch AutoRun.exe as admin.
4. Repeat.

Attempts at portablising these two folders creates:
C:\User\AppData\Local\Smart Code ltd or C:\Users\USERNAME\AppData\Local\Smart Code ltd
and Roaming\stremio:
;setenv=USERPROFILE|User
setenv=USERPROFILE|User
setenv=USERPROFILE|\User
setenv=USERPROFILE|..\User
setenv=USERPROFILE|..\..\User


;setenv=APPDATA|User
setenv=APPDATA|User
setenv=APPDATA|\User
setenv=APPDATA|..\User
setenv=APPDATA|..\..\User


;setenv=LOCALAPPDATA|User
setenv=LOCALAPPDATA|User
setenv=LOCALAPPDATA|\User
setenv=LOCALAPPDATA|..\User
setenv=LOCALAPPDATA|..\..\User


;setenv=HOMEPATH|User
setenv=HOMEPATH|User
setenv=HOMEPATH|\User
setenv=HOMEPATH|..\User
setenv=HOMEPATH|..\..\User


Haven't tried combinations of the above yet, too many to go through.

Tried all of the above using each of these combinations:
programpath=.
programpath=X-Stremio
programpath=
;programpath=


These also don't work whether AutoRun Launcher Button is run as admin or not:
deletefolders=C:\User
deletefolders=C:\Users\%USERNAME%\AppData\Roaming\stremio
deletefolders=C:\Users\%USERNAME%\AppData\Local\Smart Code ltd

I changed the path using 'myusername', removing all % from both paths, then removed C:\Users\ from both paths. Still these don't get deleted.

Again, X-Launcher_x64 works where AutoRun doesn't. Now I understand why ElCoyote is having issues with this. Maybe it's worth you taking a look at X-Launchers source code to see how that takes care of these things? Might help you to make AutoRun work better and be easier to use. :)

If you decide to do that, I would look at the original, but also the source in my download too which seems to be made with a later version of AutoIT as it has a slightly different Main source file.

I also had a look at changing the buttonwidth= but the menu didn't respond. Didn't look into it too deeply, just out of curiosity. I did notice the buttons have left a smaller margin on the left compared to the right, the menu hasn't shrunk to fit buttons. Not really sure what's going on here tbh!

Here's my updated default AutoRun.inf and a separate help file, I just called it ARM Instructions.ini. I also added the EnvVar posted earlier, but changed some bits and the extension to INI for easier reading. Feel free to change anything or completely ignore it if you don't like the idea! ;)
Just thought it may help others new to this launcher. Obviously there's a lot to add yet regarding setenv= but hopefully that will get sorted out.
AutoRun Launcher Files.zip
(5.21 KiB) Downloaded 786 times
Last edited by sl23 on Sat Jun 08, 2024 2:54 am, edited 3 times in total.
Latest X-Launcher_x64 update - Compiled with Aut2exe_x64.exe v3.3.16.1
Latest X-Launcher_x64 v1.5.4 update - Compiled with Aut2exe_x64.exe v3.2.12.1

lwc
Posts: 284
Joined: Tue Jun 26, 2012 10:40 pm
Contact:

Re: AutoRun LWMenu

#270 Post by lwc »

Where is that source? But please do something much quicker - run Stremio via X-Launcher. But before you exit Stremio, go to %appdata% and %localappdata% and tell me if you see Smart Code ltd, stremio, etc.
If you do, X-Launcher doesn't beat it at all, and all it does is wait patiently, then copy the folders back to the portable location, which my launcher can do too.

Meanwhile, I've looked at Stremio's source code in GitHub, but I don't think it's up to date since it doesn't mention (link requires being logged in) any folder called Smart Code Ltd. But in one place it actually mentions using %SYSTEMDRIVE%%HOMEPATH% instead of anything else, if you wish to test %HOMEPATH% too.
Another theory is that since Stremio has multiple EXE files, which probably call each other, your changes of environment variables affect only the first EXE file in the chain, as it's either that or affecting your entire system.
Your reply about X-Launcher may answer that.

Post Reply