Misleading "start on login" in settings using portable

[chucic]

I'm using portable version running from my flash drive (currently K:\PortableApps\SyncTrayzorPortable\SyncTrayzor.exe). When I go to settings, "start on login" and "minimized" are checked, but HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\SyncTrayzor says "C:\Program Files\SyncTrayzor\SyncTrayzor.exe" -minimized, because I'm using non-portable on this pc too.
This can cause confusion, because:

1. I don't want my portable version start on login, but
2. when I uncheck this in portable, registry key is deleted and my non-portable won't start.

I guess that when you check for this setting, you check if there is this key and if there is -minimized. Could you also check which actual binary key contains? So that in my non-portable "start on login" is checked and in my portable it isn't?

Don't know if this is real issue, because if someone is able to run portable and non-portable at the same time then he probably can also figure this out, but that's your decision.

[canton7]

Yeah, the start-on-login stuff assumes there's only one SyncTrayzor instance present on that computer, otherwise it's going to get quite confused.

I'm going to have to have a think about how best to tackle this. I don't want to be able to end up in a situation where we end up with keys that won't be deleted by SyncTrayzor and end up sitting there for ever. Or worse, two keys which point to the same exe, but only one of which can be deleted.

There's another bit of behaviour which you probably haven't noticed: on startup, SyncTrayzor will update the registry key to point to its current location. This will presumably need a rethink as well...

[chucic]

on startup, SyncTrayzor will update the registry key to point to its current location

Yeah, that is unfortunate. I thought I only need to remember not to touch "start on login" in settings next time I come across it in portable, but now I will have to manually uncheck and check it or restart non-portable SyncTrayzor...

[canton7]

My current thoughts are along the lines of:

• Each SyncTrayzor instance assigns itself an ID (stored in its config)
• Autostart registry keys use this ID (e.g. "SyncTrayzor (HD12BEF)")
• On startup, any keys pointing to the location of the current executable which do not contain its ID are deleted
• Otherwise, SyncTrayzor only manipulates the registry key containing its ID

[chucic]

Each SyncTrayzor instance assigns itself an ID (stored in its config)

In this case, what is considered as SyncTrayzor instance? Will it be bound to SyncTrayzor config in data (and therefore stored there config.xml) or SyncTrayzor binary (therefore stored in SyncTrayzor.exe.config)?

[canton7]

Actually, I ended up with a different approach.

Keys are named "SyncTrayzor", "SyncTrayzor (2)", "SyncTrayzor (3)", etc. On startup, SyncTrayzor attempts to find a key pointing to its location, if found, this is the key that will be manipulated. If one is not found, then it will pick a new key and use that.

[chucic]

Sweet 😉

[canton7]

What architecture are you using (32-bit/64-bit)? If you want, I can put together a couple of intermediate builds for you, since there's no way to workaround this issue.

[chucic]

I'm using both, but don't bother, I'm not using flash drive on my own pc too often and even less often I run SyncTrayzor from it, mostly I do on other computers (in school and such). So I have no problem to wait week or month for new version...

[ranolfi]

Hey @canton7 , I just moved from "normal SyncTrayzor" to the portable version, but before actually extracting and running the portable package, I uninstalled SyncTrayzor from the Windows control panel and then went to check the registry.

I found that the auto-start registry key was stil there, even after restarting the computer. The Inno-based uninstaller should take care of that, shoudn't it?

Just to be sure I repeated the install - start - config - uninstall procedure on a virtual machine to confirm this.

[canton7]

This is a really annoying issue, and I struggled with it for a while. Basically, the installer runs as Administrator (necessarily), and so doesn't have access to the user's registry hive. Common practice seems to be to just leave the keys there: they're not doing any harm or taking any noticeable space. This, of course, is where the Registry Cleaner Tool craze came from: to remove keys which uninstalling applications couldn't get rid of.

[ranolfi]

Running as Administrator (UAC virtualization OFF) doesn't mean that the process does not have access to the HKEY_CURRENT_USER hive. I just created a test Inno Setup project and checked. I added the following line to the end of the uninstaller project:

[Registry]
Root: HKCU; Subkey: "SOFTWARE\Microsoft\Windows\CurrentVersion\Run"; ValueType: string; ValueName: "this_is_a_test"; Flags: dontcreatekey uninsdeletevalue

The "key" (pun not intended) is to read from HKCU instead of HKLM (contrary to the examples from the documentation).

Of course you'll need to replace "this_is_a_test" with the name of the actual registry key which the uninstaller will have to delete. I think it's possible to add a few conditionals to determine which one is the right one, when there are multiple.

Let me know if you need any help. I would implement and commit it myself but I don't (yet) know how to use Git.

Link to the docs

[canton7]

I used to do exactly that, and I removed it just over a year ago in this commit because it added the key to the admin user's hive, and not the user's. As far as I can see, I did exactly what you're suggesting, but with minor differences in the flags (which shouldn't make a difference here).

I can't remember the exact details, but I definitely followed your approach, then had to backtrack and tidy up my mess.

[ranolfi]

Damn, that's right! My mistake was testing from my Administrator account, instead of a guest one. Sorry for bothering you about this.

I'll let you know if I can find a way to overcome that.

[canton7]

No worries! I had to trawl through my memories and logs to see what I'd done...

Cheers.