New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Made run on startup per user instead of per machine, and added a preference to control it. #88

Closed
ribbons opened this Issue Aug 22, 2013 · 3 comments

Comments

Projects
None yet
1 participant
@ribbons
Owner

ribbons commented Aug 22, 2013

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
up again (it seems to re-install itself).

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.

@ghost ghost assigned ribbons Aug 22, 2013

@ribbons

This comment has been minimized.

Owner

ribbons commented Aug 22, 2013

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.

@ribbons

This comment has been minimized.

Owner

ribbons commented Aug 22, 2013

Original comment from chapman.dermot@gmail.com at 19:54:45 on 2010-07-17

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.

Hi Matt

I appreciate the effort you've made thus far regarding Radio Downloader startup issue.
I see that this request/bug shows as "resolved fixed" in Bugzilla eventhough you say that "the behaviour is still the same for the user installing the application".

I have other programs on my computer which can be successfully disabled on startup using Vista's msconfig program.
Why can't this work with Radio Downloader?

Is this still a work-in-progress or should I make another request for this feature to Bugzilla?

Thanks

@ribbons

This comment has been minimized.

Owner

ribbons commented Aug 22, 2013

Original comment from Matt Robinson at 20:37:57 on 2010-07-17

I see that this request/bug shows as "resolved fixed" in Bugzilla eventhough

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.

@ribbons ribbons closed this Aug 22, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment