How to handle a file that opens the program?

Question

3.00/5 (2 votes)

See more:

hi all,

i have come across a problem, and i am not sure how to solve it Google is useless for this! (i use VB.net by the way and anything other than that right now will confuse me).

So i need to be able to double click on a file, this file opens the program and the program in turn opens the file.

now, the file association and the program opening a file is sorted, not an issue...but how can i get the directory of the file that is being used to open the program, after all it could be anywhere!

any input will be greatly accepted,

thanks for your time!

i finished the program but now (after I've published it to my server and then installed, when running as a default program it doesn't read the directory correctly using getcommandlineargs any more ideas?)

thanks again

Posted 15-Nov-13 5:21am

Allw

Updated 16-Nov-13 4:40am

v2

Add a Solution

Comments

Sergey Alexandrovich Kryukov 15-Nov-13 11:48am

Not being able to read C# means getting very little help. Most of good materials on .NET is on C#. You just need to learn at least a bit of it.
—SA

Allw 18-Nov-13 4:05am

I can read C# so get off the high horse...I choose to write in vb, because any other language confuses me when I have a lot of vb to code

Sergey Alexandrovich Kryukov 18-Nov-13 12:15pm

I already knew that the rudest people are also most illiterate; and this correlation is quite strong, so thank you for giving me yet another evidence of it.
It's not acceptable to talk to people in this manner on this site.
—SA

Allw 19-Nov-13 8:40am

And you think that people appreciate hijacking of questions in order to market your product?

Bernhard Hiller 18-Nov-13 4:00am

" it doesn't read the directory correctly" - what does that mean? Does it show a different folder? None at all? Did you happen to remove the file association from the registry? ...?

Allw 18-Nov-13 4:04am

Yeah, what I did was create a string variable to store the directory and upon creation it has the value "did not work" and then this variable contains the command line arguments when they're read, however they're only read when I drag the file over the program to open it, not when I open it with the file extension after publishing,

Thanks!

Bernhard Hiller 18-Nov-13 4:08am

That means: the file association is broken. Create it again (e.g. by right click on the file - open with - select default program); and also create the association in your setup package.

Allw 18-Nov-13 4:09am

I'll try it again, and it's already set in the setup package, like I say I'll try it all again and get back to you, thanks!

Allw 19-Nov-13 11:09am

hi, yeah that didn't work I am wondering am I using the correct manor for extracting this information, the line that should read the command arguments reads,

dim str as string = environment.getcommandlineargs()(1)

and I am using a console app, don't know if that is an issue.

I feel like it is strange that it works when I drag a file over the program to run it, but doesn't if I associate the program with it? (and to confirm I have now re-associated the film extensions and still no luck!)

thanks again!

Allw 20-Nov-13 6:30am

i replaced the file association, and tried it on a different pc to my devbox, and by doesn't read i mean that the string contents i enter at the start when declaring the string ("this didn't work") is still the contents at the end and indeed after the command arguements should've been read into the sting, the only other thing i could think of is maybe the way that i am distributing it?

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Ron Beyer · Answer 1 · 2013-11-15T05:25:00

Solution 1

The full path of the file that "opened" the program is available as the second (index 1) argument on the command line:

Environment.GetCommandLineArgs[^]

So the full path of the file is Environment.GetCommandLineArgs()(1)

(Index 0 is the executable name/path).

Posted 15-Nov-13 5:25am

Ron Beyer

Comments

Sergey Alexandrovich Kryukov 15-Nov-13 11:47am

5ed.
—SA

Sergey Alexandrovich Kryukov 15-Nov-13 11:55am

The real problem of OP is not command line, but also a problem with C#. I addressed both in my answer, Solution 2.
—SA

Sergey Alexandrovich Kryukov · Answer 2 · 2013-11-15T05:54:00

Please see my comment about VB.NET vs C#. Here is the good news: you can easily and automatically translate one into another with 100% accuracy. There are on-line and off-line/stand-along solutions, so, first of all, pay attention for the open-source stand-along tool, ILSpy, which can easily translate the whole project from C# to VB.NET and back. Please see my past answers:
Code Interpretation, C# to VB.NET[^].

Now, armed with all that, you can easily use C# projects as well. First, you can simply build available projects, references the assembly in your VB.NET project and just use in exact same was as it was in VB.NET. In this approach, you simply won't see any difference. And you also can translate, it you need it for better understanding.

That said, not you can use my work on command-line parameters, which is extremely easy to use (and one more, more complicated, is recommended in my article): Enumeration-based Command Line Utility[^].

Good luck,

—SA