[RESOLVED] File Association in Win7 - looks like my App is not getting data in Command$ param

[jcis]

This could be easy to solve just testing in Win7, but I have Windows XP.

The problem: Users having Windows 7 told me that when they double click my App file, my App opens but the Form is empty (no data is loaded). I'm just assuming the Command$ parameter is empty.

So, anybody found a workaround for this problem for Windows 7?, this is the code i use for associating my App extension:
http://www.vbforums.com/showthread.php?t=241188 I've been using this for many years, the problem appears just when using this method in Win7.

Thanks!

[Doogle]

The fact that your Application is executing when the file is double clicked shows that the File Association is working (?) I have never heard of any problems with Command$ in W7, my guess is that there's something else that the Application is trying to do and, perhaps, UAC is getting in the way. Have you got comprehensive error checking in your Application or may there be one or two things (like return values from APIs) that may not be being checked?

I don't have W7 myself, but have had to do quite a lot of Application installs on the platform and have found UAC to be 'less than helpful' on many occasions. Perhaps if you can get one of your users to set UAC to the minimum level, reboot and try your application again you could at least eliminate that.

Also, W7 enforces some 'control' as to where data files can and can not be placed. I don't pretend to understand it but Dilettante's post here: http://www.vbforums.com/showthread.p...hlight=windows might help.

[jcis]

The fact that your Application is executing when the file is double clicked shows that the File Association is working (?)

Exactly, when double-cliking my App's file my App opens ok, but data in the file is not loaded. If the user opens my App and then opens the file from my App then the file loads ok, that's why i assume the problem could be the command$ not contaning the path to the file or contaning a wrong path.

Have you got comprehensive error checking in your Application or may there be one or two things (like return values from APIs) that may not be being checked?

The code is in the link in my first post, in that code Aaron's is not reading return values from API Functions, he is using Call FuncName(...) instead.

Perhaps if you can get one of your users to set UAC to the minimum level, reboot and try your application again you could at least eliminate that.

I'll try that, I just asked someone using Win7 to deactivate UAC and try if it works, let's see what happen.

Thanks.

[westconn1]

did you modify the code to add %1 (needed for command string) at the end of the string sEXE?

are the registry keys being written correctly in w7, are you using elevated privileges in to write to hkcr?

i will test the code later in w7, but that machine is busy at present

[jcis]

Now the user opened properties, and under "open with.." selected my App, after doing this everything works fine. This could be enough for now, anyways i still have doubts, maybe this will always happen when my app is installed on Win7 or maybe this user just tempered my App's file Extension or something, if this is the case then there is nothing to worry about. I'll keep this thread unresolved for a while until I (or anybody) can test Aaron's code in a computer with Win7 and see what happen, thanks to everybody, reps to everybody too.

[westconn1]

i tested on w7 (hprem)
as limited user
the code failed (without error) to write to HKCR

running as limited user, run as administrator, the file association worked correctly and the command string was then processed correctly
the only change i made to the original code, you linked to, was to add %1 to the reg value

[jcis]

Yes, i'm also using %1. My App's Installer needs to be run as administrator so it should work fine. I conclude something happened in this specific computer, the code is ok. Thanks for testing this code westconn thread resolved.

[Doogle]

Westconn1: As you performed the tests I wonder if it's worthwhile posting your results in the original thread in the codebank, just in case anyone else tries to use it under W7

[si_the_geek]

My App's Installer needs to be run as administrator so it should work fine.

I'm not sure about that... I presume the AssociateMyApp code is part of your program rather than the installer, in which case it will not have admin permissions, and will therefore fail (and due to ignoring the API return values, you wont know about it).

Most installers have built-in functionality to register a file type, so I would recommend using that if you can.

If you do want to run it on-demand after installation, you should re-run your app (or just a mini one to do just this) as an admin, which you can do using ShellExecute with a command of "runas" rather than "open".


Note that for this kind of issue you can easily test on earlier versions of Windows too, you just need to create a "limited" user in Control Panel, and then log in as that user (or just run the program as them).

[westconn1]

@ doogle
on your suggestion
done that

[jcis]

..I presume the AssociateMyApp code is part of your program rather than the installer, in which case it will not have admin permissions..

Your presumption is correct, my mistake, this code is part of my application, not the installer, moreover: it runs every time my App is open (executed from Form_Load event).

But this user has administrator rights so I assume the problem is not related to this, and considering this App has never shown this behavior before (from 2003 to now it's been used under Win98, WinXP and Vista) i think the code is ok and this user has been tempering with my app's file Extension, or at least, if there was a problem, it had to be something related to using it under Win7, but Westconn already tested and it also works fine under Win7.

[westconn1]

even when running as administrator it may still require elevated privileges to write to some reg hives

if you want to run the association from within your application every time it is opened, which should not be necessary at all, probably you should do it on a per used basis, by writing to HKCU hive
HKEY_CURRENT_USER\Software\Classes

this should avoid any issues with permissions and also not affect any other users unless they use the same program

[dilettante]

I agree, this program is probably creating a virtualized per-user entry when it attempts to write to HKCR (which itself isn't a "real" hive anymore starting as early as Win2K I think). Why it seemed to "break" (not pass the file as %1) for some user or users I can't determine.

HKCU\Software\Classes would be the right place for this if an application really needs to create per-user entries.

This really ought to be done by your installer though as si_the_geek suggests.


My PathLinks idea at the link posted above doesn't address registry relocation, only files under App.Path. It just attempts to relocate files in folders under App.Path by using symlinks.