I've managed to develop my first app, but, I want to improve the compatability, so I was wondering if someone could possibly help me with my problem The problem I currently have is that if the target that I tried to launch isn't possible to launch (eg: the file or app isn't on the system) then I get a message saying 'unhandled exception has occurred in your application'. So I was hoping that someone could tell me if its possible to have some kind of "2nd Target" to launch if the "1st Target" fails heres an example the line of code I use to launch apps
Code: private void Button1_Click(object sender, EventArgs e) { try { // Attempt to start the process System.Diagnostics.Process.Start("explorer"); } catch { // What happens if the process doesn't start System.Diagnostics.Process.Start("explorer2"); } catch { // We can use catch more than once. This is only executed // if the statement above also fails ie if it succeeds this is ignored. System.Diagnostics.Process.Start("explorer3"); } } I'm not a C# expert, but based on other languages the above snippet should work.
[thread hijack] How easy is it to learn C#? I've been wanting to learn some programming for a while and I'm trying to find a language to start from. I was originally going to try VB but have been told by a few people to go for one of the C based languages. I'm talking learning everything from principles to hard coding. Did a little pascal in college but that's about it, and I've forgotton 99% of it. [/thread hijack]
@Bakes & Geoff: Thanx for your help. I'll try that stuff later! *sigh* The thread Jacker... Keep it up and you'll have your own channel 4 series lol Anyway... Yeah, I started with C++, and that was a little difficult, but with C# things are a little easier to understand, I started developing my app in about march, and I've nearly finished it now, its only a basic app but its good to do something basic to get an understanding of the C# language to start with!. PS, I use Visual Studio 2010 Seems easy enough to get used to as a noob to sw developing Anyway, Good luck!
Try...Catch would be the easiest way to handle it. That's what it's there for. For Brooxy: C based languages have their advantages. The biggest one being that the syntax is often similar. VB.Net vs C# is really mostly preference. They both run on top of the .NET framework, and as such can pretty much do the same things. I prefer C# simply because I use C-Based langauges a LOT, but others prefer VB.
Yes, as has been already stated you catch exceptions with a try....catch construct. Just to add one more thing to this, there is also the finally keyword. You can also catch the actual exception Code: private void Button1_Click(object sender, EventArgs e) { try { // Open a connection to a database string connectionString = "Data Source=myserver.com;Database=d"; SqlConnection cn = new SqlConnection(connectionString); cn.Open(); // Do something here with the connection...... } catch(Exception e) { // Exception handling Console.Writeline(e.Message); } finally { // The code in the finally block always executes regardless of what happened // in the try and catch block cn.Close(); } } In this case, you will always want to close your connection. The code in the finally block always executes whether you get an exception or not.
If you want to find a good language to introduce you to the basics of programming, try python. The manual is excellent with loads of examples, it's a well supported language, it's pretty easy to pick up and because of the indentation system it's easy to use. Furthermore, it can be both a procedural and object oriented language, so it's good in that respect. In terms of a language in the C family, I'd learn C++ or C itself. My reasoning is threefold. Firstly, they're well known languages and are both standards, as set by ANSI and ISO. Secondly, they're not covered by patents in the same way that C# is. Microsoft holds all the keys to C#, which means that it's generally quite hard to get your C# code to run on systems other than Windows. There are systems, such as mono, but some people fear that Microsoft could sue people who use it commercially. Thus, Mono is largely avoided. Finally, C++ is a language that is used across operating systems. If you want to write for Mac or iPhone, you can write in C++, whilst it's almost impossible with C#. You can write for Android and I believe WebOS with C++, again C# is difficult. They might be more difficult to pick up, but they're much more widely used languages.
C# is fairly multiplatform nowadays. Windows + XBOX + Windows Phone = win. Mono supports .Net 2.0 so if you stick to .net 2.0 and aren't creating graphics based applications, it will most likely run on linux. Plus C# is a much up to date language than C/C++. Supporting events, delegates, anonymous methods/types, properties, extensions, lambda expressions, etc. Some of these features are added by the new c++ standard and libraries such as BOOST. But C# has the advantage of the language being designed with these features and not being tacked on to a 20 year old language. Also, it's much faster to get stuff done in C#. The standard library that comes with .Net is fantastic. I find that when I develop with C# and .Net I just get stuff done much faster than I do in C++. There's so much built into .Net that I don't usually have to go search for a library that's implemented the functionality that I need.
I'm not going to bother talking about features here, I'm just making my argument on the basis of portability and the fact that C++ is a standard. Yes, but there are several large arguments against Mono, and including it in Linux by default, so if you were to develop a Linux application, there would be large dependencies. I'm not sure you can use 'up to date' as an argument. Yes, there are different features in different language, and what you use them for usually dictates whether you need something. If you want to use 'up to date' as an argument, I'd probably point you towards python - it's got masses of really useful libraries in, everything from xml parsing to an http server. Faster, I guess that's personal preference. I know people who prefer C and I know people who prefer C++ to C#.
I've come across another problem... when I try to make a 2nd "catch" the utility forces it to launch... heres the code that I've used: Code: private void button1_Click(object sender, EventArgs e) { try { System.Diagnostics.Process.Start("Explorer"); } catch { System.Diagnostics.Process.Start("Control"); } { System.Diagnostics.Process.Start("DXDIAG"); } } So if the code is identical to that above you'll find that it launches both explorer & DirectX Diagnostics... any help?
Shouldn't there be another catch before the last set of braces (the DXDIAG section)? So it will always run because it's outside the try...catch section. Or if that doesn't work, could you nest the try...catches? Like this: Code: private void button1_Click(object sender, EventArgs e) { try { System.Diagnostics.Process.Start("Explorer"); } catch { try { System.Diagnostics.Process.Start("Control"); } catch { System.Diagnostics.Process.Start("DXDIAG"); } } }
You're gonna have to nest them AFAIK: Code: try { something } catch { try { something else } catch { somehting else entirely } }
It's a bit of a PITA (handling them one by one), but it is possible to handle specific types of exceptions by going Code: catch (ex as System.[i]specific exception type[/i]) that would allow (for example) to handle File not found exceptiosn SPECIFICALLY, and then (for example) go Code: MessageBox.Show("File not found. Put file here or GTFO"); hope that helps
FYI here is a list of the standard Exception types. http://www.developerfusion.com/article/1889/exception-handling-in-c/3/ and a little code snippet example: Code: int a, b = 0 ; Console.WriteLine( "My program starts" ) ; try { a = 10 / b; } catch ( InvalidOperationException e ) { Console.WriteLine ( e ) ; } catch ( DivideByZeroException e) { Console.WriteLine ( e ) ; } finally { Console.WriteLine ( "finally" ) ; } Console.WriteLine ( "Remaining program" ) ; Of course you can always create your own if none of these are suitable.
