How come we are using the console instead of the form.
so instead of consol.writeline("test"); < — console
i would write messagebox.show("test"); <- Form
why use console O.o if i want to create form type applications.
and there both slightly different code. wont that confuse me in the long run? whats the console for.
and will we get into forms?
Greetings Yurij!
The console is used in the beginning just to show some basic concepts such as quick and easy display, getting user input, and stuff like for loops. You seem like you may already have a good grasp on those, so feel free to jump ahead. I assure you, forms are not far off.
As things progress, the console window also makes a great place to see debug info and diagnostics as your app is running… I imagine thats why RB started out with it as its something that can be used continuously throughout development.
"May the mercy of His Divine Shadow fall upon you." - Stanley H. Tweedle, Security Guard class IV, The League of 20,000 planets
well i flipped to page 207
and i still see console.writeline
instead of messagebox.show….
so umm….
are you sure this whole book isint about console stuff.
I want to make forms lol.
which page are the forms at.
"console window also makes a great place to see debug info and diagnostics as your app is running"
as i said 207 still shows console. i dont think that many pages is needed for a console that just has debug info lol O.o…
cause in the end ill just get mixed up with
console c# code
vs
form c# code
Hi Yurij!
C# supports a wide variety of UI toolkits and frameworks, and my C# Player's Guide just simply can't cover them all. Or any of them, really. It's a book about the core language, which is shared across all of them and also used heavily outside of UI applications altogether.
To illustrate, here are several commonly used C# UI frameworks:
GUI frameworks are vast. Books that introduce you to them tend to be some of the thickest books on the bookshelf. My goal was to get people started in C#, and not to herd them towards any specific UI framework, so I left it out entirely.
I'd argue strongly that you shouldn't even start thinking about UI until you understand the basics of object-oriented programming (including, but not limited to inheritance, interfaces, polymorphism, virtual/abstract/overridden methods) event-based programming (including delegates) and a healthy dose of lambdas and LINQ expressions. My point is, UI isn't the starting point. Get the basics of the language down using something simple (which is the role of the console window, as the simplest form of user interface possible). Then move on to the harder UI stuff.
I know it's not as fun. I remember showing of the early programs I made to my friends and family. Nobody cared. But the day I first drew some graphics on the screen, everyone ooh'd and ahh'd. And it didn't even do anything.
So anyway, that's why I've left out UI development. It's (1) too advanced for getting started with, (2) there's so many choices within C# that I can't do them all justice, and (3) it would make for a very long book if I tried to cover core C# as well as any form of UI framework.
I've considered writing a UI book. It's on my list. But I've got a few other ones that have higher priority, so the UI one will have to wait.
I can possibly recommend some other books for UI specific stuff, once you finish up this one. (For example, I used Pro WPF in C# 2010. It's a great 1100 page reference book that covers everything.) But all the UI books that I'm aware of assume you already know C#. They don't teach you the difference between a float and a double, or between a class and a struct. So it really is the "normal" approach here.
Basically, this book is just the first step in the journey.
To address your more specific question about MessageBox.Show… well… I considered it. I saw that a few other books around utilized it instead of the console window. I just went with plain Console because it felt misplaced to bring in just a tiny thin slice of the UI world without addressing it fully. (And to make matters worse, it's a WinForms thing, which is out of date at this point.)
I hope I've explained my reasons well enough, but on the other hand, you clearly seem to know about MessageBox already, and if you feel like going that direction instead, you should go for it, by all means. Programming is a creative process. We often think of it as being very analytic, and in an analytic world, there's usually thought to be a "correct" answer. In programming, as often as not, there are a dozen ways to do things, and none is best in all cases. So use MessageBox all you want to! In fact, here's the link to the MessageBox class documentation on MSDN: http://msdn.microsoft.com/en-us/library/system.windows.forms.messagebox(v=vs.110).aspx, if you haven't found that already.
Anyway, I know that turned out to be kind of long. I hope it helps to explain why I did what I did in the book, but let us know if you still have questions… :D
Now im just confused…
lolz.
well one of my goals is to create my own anti virus. ( just to give you a little direction of where im going).
so now im really confused.
i remmeber you stating if i hit a certain chapter in this book and know everything to that chapter i should be able to know a lot about c#. And the rest is like stuff that is optional to read…
So my goal is to create an anti virus….
what does console really have to do with c# O.o.. like you can do much this a console :O..
while forms i can create a bunch of programs.
also
console c# code is different then form c# code. So isint it kinda useless or am i benefiting from anything that can help me in form coding?
"And to make matters worse, it's a WinForms thing, which is out of date at this point.)"
how is it out of date. doesnt basically every program made with froms, cause that how you create programs na?
ive used vb.net and i always used forms lol.
sorry for all these questions, just trying to get everything in my head before reading on aha.
Basically should i just move on to a book that focuses on forms if iwant to create and anti virus
or
should i finish your book then find a book with forms.
and if i should move on to forms which is a good c# 2012 book that have easy to follow that has like try it outs like your book and stuff.
Sum it up:
If i learn forms it will be harder for me to process but if i can process it, it will take less time to learn.
or
if i ready your book first then read a form book it will be easier for me but longer for everything to finish?
hope u can answer :) ty
well some guy told me this
"My suggestion is that you start with Console Based applications. This way you can learn the core fundamentals C#, also learn the fundaments of the C# programming language. E.g data types, data conversions, voids, functions, structures, arrays etc. And the reason why you are learning C# is to code an Antivirus then I'm afaraid you won't get that far , because if you have that goal in mind you will always cut corners and not learn the important stuff. Then later on when you have a bug in your proram, you post numerous threads asking for help when you don't even know the basic stuff. See, you're already planning on skipping Console Application to jump straight to Windows application because you think you don't need it…
Take me for example, I had a genuine passion for programming, when I started programming I never learned because I wanted to create a crypter or RAT, I learned it because I loved to code, and I loved what I could make the computer do. And uptil today that's what that keeps me going.
Here's a quote from Steve Jobs that I agree with in application to the context of this thread.
Quote:
People say you have to have a lot of passion for what you’re doing, and it’s totally true and the reason is, because its so hard, that if you don’t, any rational person would give up. It’s really hard and you have to do it over a sustained period of time.
So if you don’t love it, if you’re not having fun doing it, if you don’t really love it, you’re going to give up.
"
When I say some stuff is optional, I'm not suggesting that you actually permanently skip it. Just that some stuff is more important than others. When you've covered the "required" work, you have enough knowledge that you could start to make your own programs. As an example, towards the back, there's a chapter on LINQ expressions. You do not have to know LINQ to make a C# application of any sort. (Well… unless you use a 3rd party library that forces you to use it.) Everything you can do with LINQ, you could do another way, with more primitive tools. LINQ is a better choice in some circumstances, but if it never existed, you could still write amazing software. (That's what people did before LINQ came out in C# 3.0.)
So some parts are not truly required, but it's hard to say you've mastered C# without having a pretty solid understanding of all of the material in the book. You could write your antivirus software without LINQ and be fine. (On the other hand, you probably do need a GUI of some sort, which I think is really one of your big points here. You technically could write it without a GUI (I wrote a security application that was purely command-line) but it's the kind of thing you really do want a GUI for.)
You said, "Console C# code is different from forms code"…. No. Not really. There's the part about Console.WriteLine, but literally everything else that you see and use is applicable in a GUI application. Variables, methods, classes, inheritance… you name it. It applies in a console app just as well as a GUI desktop app, or a game, or a service or a server. That's why I structured the book the way I did. My focus is on looking at the core C# language, the stuff anybody who does anything with C# will need to know. It's the starting point for everybody. The next step will be different, depending on what you want to do with it, but it's the same first step.
Do do GUI programming, you'll have to still learn a lot more, but everything you learn in this phase is still useful. Indeed, not only is it useful, it's the foundation that the various UI frameworks are built on.
Microsoft quit doing significant updates to Windows Forms when C# 3.0 came out and WPF superseded it. It's currently in "maintenance mode", which means they're still fixing bugs, and still supporting it, but they're not adding anything new to it anymore. That's not to say it's useless. WinForms is a bit easier to work with than WPF, but it's also less powerful and doesn't take advantage of the graphics device like WPF does.
In general, WPF and WinRT don't call things "forms" like WinForms does. They're UIElements, Controls, Windows, etc. The term "form" is only used on rare occasion, usually by a programmer who did a lot with WinForms before it.
To top it off, even WPF isn't getting updated at the moment. Microsoft switched to WinRT, which is sort of an evolution of WPF. WinRT still uses much of the same syntax (XAML) and design patterns that WPF has, but it is designed to be more cross platform, to target smart phones and other mobile devices, as well as desktops, laptops, and even the Xbox One. But developers haven't had much love for WinRT, and so the future is a bit uncertain right now.
It's not a horrible choice to use Windows Forms to start a new application right now, but I'd probably recommend WPF over WinForms in general. I always tell people it's twice as hard to learn, but ten times more powerful. (Both of those numbers are probably an exaggeration, but it gets the point across.)
If you've used VB.NET and WinForms, then going with C# and WinForms is actually a pretty good choice. If you've already used WinForms in another .NET language, then picking up WinForms in C# ought to be a piece of cake. (But then why not just stick with VB.NET? Why even switch languages? I prefer C#, but that's a personal preference, not a professional preference.)
As far as whether you should finish this book before moving on to a UI-specific book or just jump ahead to another book, that's up to you. It kind of depends on how much programming you've done in the past. Honestly, if you've got a year or two of VB.NET experience behind you, I'd start skimming through the book, rather than reading it. VB.NET and C# were both designed at the same time as the .NET Framework itself. Their syntax is quite different, but there's almost 1-to-1 parity between their features.
But otherwise, I'd say you should work your way though this book before tackling a UI book. You may be able to understand what the UI book is showing, but those books aren't going to be focused on explaining how the core language works. They're focused on how the UI framework works. I think it's worth reading it to pick up on those fundamentals that probably won't get explained or even appear in a UI book.
If you're antsy to get moving into the UI world, it doesn't have to take long. I think somebody with some programming experience and some free time could probably move through the book in just a few days. (For others, especially if they don't have much programming experience, it may take a few weeks or even a couple of months.) You could take a look at the little sections at the beginning of each chapter, and then jump ahead to the quizzes and Try It Out problems and make sure you didn't miss anything important.
But you know your situation a lot better than I do. If you feel like you'd rather just jump into a good WinForms or WPF book or something, then you're probably ready for it. This book would always be there as a fallback reference for you.
WinForms and WPF are two completely different UI frameworks that are both for the .NET Framework. There's shared principles/knowledge/patterns that you can reuse once you learn one (or any other UI framework) but the code is completely different, and they do have somewhat different feature sets.
Since they (WinForms and WPF) are both for the .NET Framework, any .NET language can take advantage of them, which includes VB.NET, C#, Visual C++, and several others. So the UI framework is tied to the .NET Framework itself, not to any specific language.
WPF is newer than WinForms. It's a bit harder to learn, but substantially more powerful. WPF is probably the preferred option if you're starting completely fresh, but lots of programs (even new ones) are still being made with Windows Forms. It's a technology that's not leaving any time soon (but don't expect new features for it).
