|
Hello,
I try for this:
<br />
try<br />
{<br />
<br />
<br />
System.Diagnostics.ProcessStartInfo psi =<br />
new System.Diagnostics.ProcessStartInfo(@"ftp -s:c:\config.ini");<br />
Process ggh = Process.Start(psi);<br />
ggh.WaitForExit();<br />
<br />
}<br />
catch (Exception ex)<br />
{ Console.Write(ex.ToString()); }<br />
<br />
i have an exception : {System.ComponentModel.Win32Exception: Le fichier spécifié est introuvable
à System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo startInfo)
à System.Diagnostics.Process.Start()
à System.Diagnostics.Process.Start(ProcessStartInfo startInfo)
à FTP.Program.Main(String[] args) dans C:\Documents and Settings\Bureau\FTP\FTP\Program.cs:ligne 104}
Thank you verry mutch.
|
|
|
|
|
abbd wrote: @"ftp -s:c:\config.ini"
|
|
|
|
|
Hello,
When i put this command in cmd console, its work, the file config.ini conatins the parameters of connection to the ftp file, how i can excute this command in c#, thank you.
|
|
|
|
|
is it ftp.exe or config.ini that isn't found? try changing one or the other and compare results.
is the folder containing ftp.exe part of your PATH environment variable? why don't you use an absolute path here?
|
|
|
|
|
Thank you for your answer, i use command ftp of windows, it was not an exe, in console CMD, i succed to excute the same command, but in c# it don't work, help to resolve thise great problem, thank you verry mutch.
|
|
|
|
|
use C:\Windows\System32\ftp.exe in your Process statement, rather than just ftp .
It is a real exe, there is no built-in ftp command!
|
|
|
|
|
Is there a good source for documentation on COM libraries? Specifically, I am looking into Faxcomlib.dll, such as the possible values for QueueStatus (for example). Thank you!
Also, I have read this article and it was helpful as a start:
Faxing with XP and C#[^]
|
|
|
|
|
The vendor who wrote the library is the best you're going to get. If they dont' have any docs, then the quality of what's out there goes down dramatically to what people have figured out and speculate on how to use properly.
|
|
|
|
|
You might want to try and open this dll in the API Viewer (that came along when you installed Visual Studio 6).
|
|
|
|
|
You realize that the API Viewer looked at a huge, and incomplete, text file for it's data? All it does is provide a VB6 header for calling WIn32 functions. It provides no documentation on anything and doesn't even inspect actual .DLL's for anything.
|
|
|
|
|
I see what you mean - maybe then OLE Viewer could at least help the OP see the QueueStatus values(if it is an enum)?
modified on Friday, May 7, 2010 11:23 PM
|
|
|
|
|
The API Viewer will only list the values defined in the text file. It will not tell you what they are used for nor if you can combine them, and again, only for Win32 functions. It will do nothing for any library outside of Win32 nor anything added to Win32 after about 20 years ago.
|
|
|
|
|
Yes thanks - I was simultaneously modifying my post above - can the OP use the OLE Viewer ?
modified on Saturday, May 8, 2010 6:30 AM
|
|
|
|
|
No. It doesn't supply anywhere near the same information. It only handles Object Linking and Embedding stuff, not COM or Win32 stuff.
|
|
|
|
|
I'm translating some C# code into VB. In several places, the author uses static on private functions. My understanding is that static methods are useful only if you are building a toolbox: the keyword tells the compiler to organize the code differently and allow programmers to call the method from the class itself rather than from an instance of the class. Fine and understandable, but what is the use if the method is not publicly available? Is the code better optimized? Or is it a matter of programming style?
|
|
|
|
|
Perhaps those methods are called by a public static method? They would need to be static also.
|
|
|
|
|
Trust me, I've hit that pothole before.
It was just that I've never seen private static methods before; if there was an efficiency reason to use them I was going to adopt the technique. I might anyway: self-documenting code is always good.
|
|
|
|
|
For me, it's all about usage.
If a method needs this it's non-static. If it doesn't, the the compiler will make it static if it creates it via Refactor, or I will if I realize.
If it is static, it doesn't matter when I refer to it - I can use it from static or non-static methods. If it isn't (but could be), then I will swear a bit when I want to use it from a static method (public or private).
If you can, make private methods static - or at least I do.
You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace
C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy
|
|
|
|
|
I write a lot of private statics -- most access private static data.
I see no reason to make a method non-static just because it's private.
|
|
|
|
|
As others already said, I choose static to indicate the method needs no data or has no state, other than static data fields.
|
|
|
|
|
It looks like static is being used to document methods that did not interact with the class' internal variables; I was just curious if there was any advantage that went with it. Thanks for the responses.
|
|
|
|
|
Gregory.Gadow wrote: It looks like static is being used to document methods that did not interact with the class' internal variables
I assume by "class" you mean "instance" here. Static methods can access class-level (i.e. static) variables. Although you then need to think carefully about threading issues if these static variables are being changed by different instances.
|
|
|
|
|
Yes, the instance's variables
The class has no static storage, and all of the static methods are along the lines of "perform a calculation on the parameter and return the result."
|
|
|
|
|
David Skelly wrote: think carefully about threading issues
Oh, yeah, there's that -- static methods are thread-safe, right? Maybe in some cases you don't need thread-safety, so making the method non-static will allow increased parallelism?
|
|
|
|
|
PIEBALDconsult wrote: static methods are thread-safe, right?
yes, if the documentation for a particular class says so. Otherwise no.
The typical .NET class does that, as you well know.
|
|
|
|