Hi there..
i want to start an application which name and path is stored in my.settings.
so i use
Process.Start(My.Settings.pfadname)
when i execute my program and the filename in my.settings contains any command-line-parameters, vb tells me that the file doesnt exist.. so how can i make the programm start any other app using parameters
Greetings
Jan "JeriC" Eric
starting another application with parameters
WallStreetVH
OK David,
I’ll answer your questions because there are answers.
What would happen if the system ran out of memory and an OutOfMemoryException was thrown You would then catch this error and state that the file could not be found. What would happen if the system ran out of memory and an OutOfMemoryException was thrown You would then catch this error and state that the file could not be found.
No…. I wouldn’t catch this error.. or if I did, I couldn’t do anything about because system is out of memory which is a pathological condition. Engineers do not write applications to run in zero memory. Even though I used to be involved in fault tolerant systems, we realize that if someone had taken up all of non-paged pool there wasn’t much we could do about it and those conditions were outside of our design parameters. The answer if to find the person with a bug.
What would happen if the file could be found but no application was registered to open it You would also catch this and state that the file could not be found.
This application only accepts .EXE files. This was a design decision to preclude the scenario you just described. Therefore your objection is a non-issue dealt with by good design.
What would happen if a ThreadAbortException occured if the thread was aborted Once again you would also catch this and state that the file could not found.
Where david In between the setting up of the exception and the next line of code. Empirically none of these conditions have occurred in many thousands of operations.
You should only catch errors that you know you can handle. Otherwise, you should let other exceptions propagate further up the stack.
I'm interested in how long you have been working with .NET for You need to be careful about pushing information you clearly do not have a full understanding of.
David, that’s really none of your business,David. You are being pushy, abusive and behaving as if you (Editted for Inappopriate Language).
What’s true is that you are dealing with “What if’s” – fantasies actually that cannot happen. It would be equally appropriate for me to ask questions about you intrusiveness.
There are a few words… you might learn:
1.) I’m sorry. I apologize.
2.) I was wrong.
3.) I apologize for (Editted for Inappopriate Language)
One more thing.
Stop playing God. OK You see, I don't think you've demonstrated much in the way of competence in considering everything you've said. You certainly haven't bothered to learn of the parameters of this application prior to making an unrequested, unwarranted, negative, ill mannered, critque. I think it's you who should back off. I am not accountable to you and will not be. Is that clear
(Editted for Inappopriate Language 9:44 PM EST - ReneeC)
suppechasper
Protected Sub CreateProcess(ByVal Filespec As String, ByVal Switches As String)
Dim startinfo As New System.Diagnostics.ProcessStartInfo
Dim Proc As New System.Diagnostics.Process
startinfo.FileName = Filespec
startinfo.UseShellExecute = True
startinfo.Arguments = Switches
Proc.StartInfo = startinfo
Try
Proc.Start()
Catch e As Exception
MsgBox("You have requested to run file:" & vbCrLf & Filespec & vbCrLf & vbCrLf & _
"However that file is not in that directory. You may either delete this button" & vbCrLf & _
"or replace the effected file.", MsgBoxStyle.Critical, e.Message)
End Try
End Sub
Well yes, I cut this out of an existing piece of code and I did miss the removal of on piece in the error message.
Now then David, I agree with you about Byrefs.
That's a very old piece of code. There was a complex datastructure instead of strings for input and the first Byref was definitely. definitely necessary. This was one of those very rare occasions where it was needed. I just didn't update it today because I am working on something very intensively now.
Yes the code didn't compile because I removed most but not all of that datastructure to simplify it for the user.
You aren't correct about the catch at all.....
This code is from a toolbar that stays in memory for months at a time. Files are stored in a database and if the user doesn't update the data after a deiinstallation, there will be an error that is a system admin error rather than a coding error. The catch is quite apropriate as well as needed there.
qdewolf
Renee,
There are a couple of things I would change with that code:
- The code doesn't actually compile
- You don't need to pass Filespec, nor switches by reference. You should rarely, if ever, need to do that
- You should dispose of the Process instance as it implements IDisposable
- Never, never catch Exception, there are certain exceptions that should never be caught and if someone passes an empty file name (which would indicate a bug), you are going to show a MessageBox to the user rather than throwing the exception back to the caller.
- The error message doesn't actually make sense
You can actually replace the above code with the following:
Dim fileName As String = "notepad.exe"
Dim arguments As String = "TextFile.txt"
Dim application = Process.Start(fileName, arguments)
application.Dispose()
However, in saying that, Renee's, nor my code, actually solves Troy's problem.
Troy, perhaps you could store the filename and the arguments in separate settings properties, or you could find the find first space in the command-line and split the string based on that.
DSATISH
"However, the question asked wasn't regarding your application, but rather on how to solve a particular problem (which you didn't answer correctly - even though you post was somehow marked as an answer)."
That's also interesting David, because I didn't mark it as an answer. Either another moderator marked it, or the OP did.
The reason XP gives this user a File-not-Found error in the App is handing XP a request in a manner where the command parameters are being confused with the filespec.
The subroutine I supplied does manage switches and command arguments so I disagree with you.
Yes, I used explicit language to address your ill considered behavior because I thought that would be the only way to get through to you, David. There are times that you don't leave human beings much room. It was my intention to get you attention and create some room.
That you care is acknowledged, it's just that at times... it's gets WAY out of balance.
JHB
David i would like to ask a question about exceptions but i'll creat anothing thread for it i hope you answer me
thx
SoftwareAndWhy
what should we do with exceptions then or do you mean process exceptions
best regards
sbodla
hmm, and what is if the programm is for example in the directory "C:\dokumente und einstellungen\Jan\eigene dateien\programm.exe" (I dont know how this folders are called in the english versions of windows, i think they should be called "documents and settings"..) - how to indicate wether a space belongs to the filename or not
BahKoo
Sorry, I should have made that point a little clearer. ;)
You should only catch the type of the exception that you can recover from, for example lets take a method that attempts to delete a file, if it fails, it does nothing, you might go about implementing like so:
Public Shared Sub TryDelete(ByVal path As String)
Try
File.Delete(path)
Catch ex As Exception
' Silently fail
End Try
End Sub
However, then John Doe comes along and writes the following code that calls it:
Dim fileName as String = "" ' TODO: Must remember to add filename
FileUtil.TryDelete(fileName)
This code will compile find and run without error, however, TryDelete is hiding a bug, that is that John Doe is passing an empty string to TryDelete instead of a file name. When File.Delete is called with a path that is empty, an ArgumentException is thrown, however because TryDelete catches Exception, ArgumentException and all other exceptions are being ignored.
Instead, TryDelete should be changed so that it only catch exceptions that it knows it wants to ignore:
Public Shared Sub TryDelete(ByVal path As String)
Try
File.Delete(path)
Catch ex As IOException
' File is in use, or the path couldn't be found
Catch ex As UnauthorizedAccessException
' User doesn't rights, file is readonly or trying to delete a directory
End Try
End Sub
Now when John Doe passes an empty string to TryDelete, the ArgumentException will be propagated up the stack and the bug will be found the first time the code is tested.
RichardSw
David,
There's another hole in your argument. If you notice in the error message in the first place where I posted my code.......
Try
Proc.Start()
Catch e As Exception
MsgBox("You have requested to run file:" & vbCrLf & vbCrLf & packet.sFileSpec & vbCrLf & _
vbCrLf & "However that file is not in that directory. You may either delete this button" & vbCrLf & _
"or replace the effected file.", MsgBoxStyle.Critical, e.Message)
End Try
The filesspec was part of the error message. The absense of a filespec would have immediately been apparent. There was no potential for a silent error here.
Chris the badger
Can you please explain to me how ByRef was necessary Was the type of the packet variable a reference type or a value type
The catch Exception is wrong, it hides bugs. It actually breaks the CriticalError FxCop violation Do Not Catch General Exception Types.
Hannoman
ShaneBattrick
Protected Sub CreateProcess(ByRef Filespec As string, ByRef Switches As string)
Dim startinfo As New System.Diagnostics.ProcessStartInfo
Dim Proc As New System.Diagnostics.Process
startinfo.FileName = FileSpec
startinfo.UseShellExecute = True
startinfo.Arguments = Switches
Proc.StartInfo = startinfo
Try
Proc.Start()
Catch e As Exception
MsgBox("You have requested to run file:" & vbCrLf & vbCrLf & packet.sFileSpec & vbCrLf & _
vbCrLf & "However that file is not in that directory. You may either delete this button" & vbCrLf & _
"or replace the effected file.", MsgBoxStyle.Critical, e.Message)
End Try
End Sub
Arthas_cool
Renee,
What would happen if the system ran out of memory and an OutOfMemoryException was thrown You would then catch this error and state that the file could not be found.
What would happen if the file could be found but no application was registered to open it You would also catch this and state that the file could not be found.
What would happen if a ThreadAbortException occured if the thread was aborted Once again you would also catch this and state that the file could not found.
You should only catch errors that you know you can handle. Otherwise, you should let other exceptions propagate further up the stack.
I'm interested in how long you have been working with .NET for You need to be careful about pushing information you clearly do not have a full understanding of.
steve thorn
Renee,
There is no reason to get abusive or make use of swearing, it is not a good example to give as a moderator.
You're right I don't understand the parameters of your application. However, the question asked wasn't regarding your application, but rather on how to solve a particular problem (which you didn't answer correctly - even though you post was somehow marked as an answer).
Any answers you give, need to be relation the problem at hand, don't just copy and paste any code you have lying around (which I hope you have rights to).
My concern is that as you are a moderator, you need to be sure that you any information you are giving is correct. I'm not saying that I'm right all the time, but when I am wrong, I make tracks to correct myself.
I care about these particular issues as I work on a team that designs software (FxCop) for developers to make sure they don't make these kind of mistakes.
A ThreadAbortException can be thrown at any time, between any IL instruction.
By catching the generic Exception type, you are catching everything that derives from it, including OutOfMemoryException and ThreadAbortException.