Skip to content
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

SendTo links not working for "limited" (i.e. non-admin) accounts #7

Open
GoogleCodeExporter opened this issue Apr 15, 2015 · 1 comment

Comments

@GoogleCodeExporter
Copy link

I received the following e-mail report from a user:

"I am a limited user. When I install Winhasher, I run it as Windows 
Administrator and enter Admin password. However, then the in the limited 
account I always use, I do not see the 'send to' commands in windows explorer.

"To avoid this, when I install Winhasher to a computer, I have to give my 
limited account temporarly Admin power. This is not convenient I believe."

I haven't been able to follow up on this, but it sounds like the installer is 
setting up the SendTo links for the admin account but not for non-admin 
accounts. Either that, or it's forcing the user to run WinHasher as an admin 
user in order to get it to work. I don't know what operating system the user is 
operating under; the user wrote from a GMail account, so there are no clues in 
the message headers about the client OS. Presumably, he/she is using Windows 7 
or 8.

I'll try and run some tests on my non-development Windows 7 machine, which 
should have WinHasher installed in the same manner as a typical user would.

This may or may not be related to closed Issue 5.

Original issue reported on code.google.com by [email protected] on 19 Dec 2013 at 7:47

@gpfjeff
Copy link
Owner

gpfjeff commented Jun 30, 2015

OK, now that I've had a bit more time to look at this, I have some bad news. There's no such animal as a common Send To folder on any version of Windows. This means that the best the installer can do is to add shortcuts for the "currently active" user, and if a limited user bumps themselves up to admin temporarily to install the app, the shortcuts will be added to the admin user account, not the limited account. The only way for this to work as the app stands right now is for the installing user to switch their account from a limited account to an admin account, install WinHasher, and then switch them back to a limited account. This option, of course, is not always available. The only other alternative is to manually create the shortcuts.

So it looks like I'm going to have to rip the Send To shortcuts completely out of the installer code. The only "automated" alternative I can provide is to put an option within the WinHasher code itself to create (and optionally remove) the Send To shortcuts. The best approach I can think of is to put a new Options button (perhaps between the About and Close buttons) that will open a new dialog for additional options. Then I can build a UI to add the shortcuts. I'm not thrilled about this, but it doesn't look like I have any other choice. I know I personally use the Send To shortcuts a lot, so I imagine other users will find them just as useful. I'd hate to abandon them altogether.

gpfjeff added a commit that referenced this issue Jun 30, 2015
Took some time to overhaul the InnoSetup script. Added the Bouncy Castle
library and the PathTweaker console app, both of which were accidentally
omitted. I also removed all the Send To shortcut icons, since I found
out there's no way to address Issue #7 within the installer. (I'll
probably need to update the app to give the user the option to add those
shortcuts.) I'm removing the md5 and sha1 executables and replacing them
with batch files that call the hash console app behind the scenes, then
added additional batch files for the other hashes as well.

In the main app, I'm restructuring the registry settings a bit and
switching the hash and output type settings for an index value to a
string. This will future-proof the drop-downs a bit when we add future
hashes, as we'll no longer be dependent on the order the hashes are in
the drop-down. This means changes to the UpgradeSettings() method, the
MainForm constructor, and the MainForm_FormClosing() method; basically
anywhere the settings are written to or read from the registry.
gpfjeff added a commit that referenced this issue Jul 10, 2015
Added the new Options Dialog to (a) give the user the ability to disable
automatic update checks and perform update checks on demand, and (b)
replace the Send To shortcuts that were created by the installer with an
option to let the user create them via the app itself. This second
option should let any user on the system create their own Send To
shortcuts, regardless of who runs the installer. (See Issue #7.)  The
options dialog is not available in portable mode.

Tweaked portable mode to actually display in the title bar that the app
is actually running in this mode.  Also fixed the default options to
correctly default the hash and output type drop-downs when there's no
existing preferences (or the user is running the app in portable mode).

Also added the GPF Update Checker XML schema definition file, which I
previously forgot.  The update checker won't run without it.  Oops...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants