Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Made run on startup per user instead of per machine, and added a preference to control it. #88
Original report from Mark at 22:35:17 on 2010-01-30
I've tried stopping Radio Downloader running on start up using autoruns (as suggested).
When I next use Radio Downlader it resets the setting so it runs on start
Is there an easy way to fix this ?
Windows XP patched up to date, nothing unusual about it.
I like Radio Downloader but only want to run it on request not all the time.
Imported from Bug 190 in the NerdoftheHerd.com Bugzilla.
Original comment from Matt Robinson at 12:09:09 on 2010-07-11
I've pushed around various solutions for allowing better control over run on startup, and kept running into problems. However, I believe I've now found and implemented the best compromise in 404d437.
The installer now no longer adds a run on startup registry value in HKLM. Instead, the application now adds a value in HKCU when it starts up. This means that the behaviour is still the same for the user installing the application.
However, there is now also an option within Radio Downloader to control this, which causes the value to be added and removed as required.
Radio Downloader now won't automatically start for the other users of a computer it is installed on (which may be preferable), but once a user starts it for the first time, it then will start up for them.
The only downside to this change is that the startup registry value will be left behind once Radio Downloader is uninstalled. This is because Windows Installer doesn't appear to be able to remove a single registry value only on uninstall.
Original comment from email@example.com at 19:54:45 on 2010-07-17
I appreciate the effort you've made thus far regarding Radio Downloader startup issue.
I have other programs on my computer which can be successfully disabled on startup using Vista's msconfig program.
Is this still a work-in-progress or should I make another request for this feature to Bugzilla?
Original comment from Matt Robinson at 20:37:57 on 2010-07-17
When a bug is marked as RESOLVED FIXED this means that it is fixed / implemented in svn trunk, not that it is in the currently released version. Bugzilla does support a CLOSED status which bugs can be set to when they are in released code, but I don't currently use that (to keep things a bit simpler).
The target milestone field shows which version the bug was fixed against - in this case 0.16, which is not yet released.