Example: In Google Chrome Portable with Portable Passwords enabled, if the user enters the wrong master password or hits cancel, the launcher should abort.
Right now this is only possible with the Abort keyword in the Init function. Anywhere else and you have missed cleanup work! The Init function of course runs before the splash screen, and before the checks for secondary launch and crash detection, making it less than ideal for some of the stuff you might want to do there (in my case, show a password prompt on the primary launch).
I suggest a function you can call that will do any needed cleanup and call Abort for you.
Ideally, if called from the Pre hook, it would not need to do any cleanup associated with the PostExec or Post sections, since the dev can be reasonably expected to not dirty stuff up in Pre until they do their checks for whether or not they want to abort. Similarly if called from PreExec, it's assumed you've cleaned up from PreExec already so you just need Post to be called.
In any event it should skip the Execute step.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
In NSIS, implementing this correctly (for use at any point) is hard. This is mainly because NSIS has only a single stack and no list or array support (there are plugins which make it slightly easier to work with, but in the past they didn't work properly; I see now that nsArray works with Unicode and is small enough—that leaves only the inconvenience of using it). In another programming language I would implement it correctly from the start, but at the moment I'm not interested in implementing it in NSIS. As I see it being implemented, it'd complicate the code too much.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
What about a global variable telling the launcher to skip execution? It's not ideal, but it's a beginning.
Previously known as kAlug.
How about if they enter it incorrectly (maybe prompting them a second time first) you store the current passwords as a backup, alert them that saved passwords are unavailable for the current session and allow it to start anyway, keeping the current set safe and restoring it on exit.
Sometimes, the impossible can become possible, if you're awesome!
I may end up allowing execution wo/Portable Passwords enabled. Right now the user can go and disable it by hand, I'm not sure how Chrome would react to "corrupt" passwords in its DB (caused by Portable Passwords failing to import). If Chrome removes the entries Portable Passwords, in its current form, would be unable to restore them (and in fact would abort with an error).
But I have made enough changes for this release I think, these tweaks and stuff to test/experiment can go on my "TODO" list. Portable Passwords wasn't even on my "mess with this" radar originally anyway...
Signature automatically removed for being too awesome.
Try it and see what happens. If the user enters an incorrect, backing them up should only take a few lines of code. And have the launcher check for those backups early in the launch and restoring them should only take a few more.
Sometimes, the impossible can become possible, if you're awesome!