Page 1 of 2 12 Last
  • Jump to page:
    #1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2008
    Posts
    62
    Rep Power
    0

    Anyone familiar with C# and windows forms?


    I just started learning C# and I think I'm picking things up fairly quickly but one thing I'm having trouble with is Windows forms. I haven't been able to find a great set of tutorials/lessons/or even a book to my liking to help me learn Windows Forms. I'm going to be working for a software company this summer doing C# development and I imagine at some point I'll be asked to contribute some windows forms to existing applications. Has anyone come across any good resources for learning how to incorporate/use windows forms in existing applications? I've never used windows forms before so beginning resources would be best.
  2. #2
  3. Devshed God 1st Plane (5500 - 5999 posts)

    Join Date
    Jun 2005
    Posts
    5,964
    Rep Power
    4852
    Windows Forms is just a moniker given to some underlying, pre-written stuff that generates graphical user interfaces. It connects to the OS via the Windows API.

    What did you want to know that you couldn't find on MSDN?
    Write no code whose complexity leaves you wondering what the hell you did.
    Politically Incorrect DaWei on Pointers Grumpy on Exceptions
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2008
    Posts
    62
    Rep Power
    0
    I've just been googling for some simple tutorials/lessons to teach how to use them with Visual Studio. Do you have any good ones that you'd recommend reading first?
  6. #4
  7. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    I've been slogging through Wrox' Beginning Visual C# 2008, in part because I also needed to learn the language (similar to C++ and Java, but also different).

    Windows Forms is basically what you've been doing with Visual Basic all this time -- ie, what we had gone in expecting Visual C++ to be, but wasn't. Every form and control has properties and events. You can set the properties either at design time or programmatically at run time. You add a form to the project, give it a name, and set its properties. Then you add controls to it, give them their names, and set their properties.

    For example, if you add a label to a form to give the name of another control (eg, a TextBox), then you set that text at design time and you're done with it. But if you want to use a label to, say, display the time as it ticks, then you give that label a name and then periodically you will get the time, convert it to a string, and assign that string to the label's Text property; eg:
    lblTime.Text = sTime;
    And if you have a TextBox control and you want to read what the user had typed into it, then you simply read its Text property.

    As I mentioned, forms and controls have events associated with them -- eg, the Click event for buttons -- to which you can assign event handlers, much as you've done in other Windows programming frameworks.

    Though actually, I wouldn't say that it goes through the Windows API, but rather through the .NET API. Even though .NET might eventually go through the Windows API, only .NET will be apparent to you as every "system call" you make will be through .NET. Indeed, if you look at the same C#.NET code and VB.NET code, they will look very similar because they will both be making the exact same .NET calls.

    I also have the SAMS "in 24 hours" book at home, which offers a "start creating Windows Forms apps from the very start" approach, but I haven't had the time yet to start working with it.
  8. #5
  9. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2008
    Posts
    62
    Rep Power
    0
    Would you recommend that first book for learning how to use Windows Forms?

    I'm trying to make a simple Hello World console application and then add a form to it. I added the form and it made Form1.cs, Form1.Designer.cs, and Form1.resx. I'm not too sure about the resx part but I take it, the Designer.cs file just seperates the code needed to create my form from the code needed to handle events in the form.

    If I add a button to the form and double click the button, it jumps to the code view of the form and adds a method to handle the button click.

    In main, I can launch the form by saying Form1 f = new Form1() and then f.Show() but it disappears really quickly. Why does that happen?

    Also, what's the difference between Windows Forms and WPF? Is WPF just a fancier version?
  10. #6
  11. /(bb|[^b]{2})/

    Join Date
    Nov 2001
    Location
    Somewhere in the great unknown
    Posts
    5,163
    Rep Power
    792
    Try instead to create a new windows application instead of a console application. VS will set up some things for you so you don't have to worry about it.
  12. #7
  13. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2008
    Posts
    62
    Rep Power
    0
    Originally Posted by Onslaught
    Try instead to create a new windows application instead of a console application. VS will set up some things for you so you don't have to worry about it.
    I figured out I have to use Application.Run. What about good practices? I'm making a simple calculator program now to test out some of this stuff, and certain things like number buttons I would think should be laid out using loops to minimize code repetition etc. Do programmers care about things like this when designing GUI's or do they just disregard most of what is in the Designer.cs file?
  14. #8
  15. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    The Wrox book is more for presenting the language and the development environment (VS 2008) and introducing you to most kinds of applications you would create. The format (shared by six authors) is exposition followed by practical examples that themselves present a lot of material not covered by the exposition:
    Part I: The C# Language consists of 14 chapters and takes you through the language itself. All the examples are console applications.
    Part II: Windows Programming consists of 4 chapters and covers using Windows Forms. Though the fourth chapter deals with deploying Windows apps.
    Part III: Web Programming 5 chapters dealing with ASP.NET, web services, and Ajax.
    Part IV: Data Access 6 chapters dealing with the file system and database access.
    Part V: Additional Techniques 7 chapters on XML, network programming, graphics (GDI+) WPF, WCF, and WWF.

    Windows Forms (WF) is for Windows apps, just as ASP.NET is for web apps. As such, they are somewhat platform-dependent; even web apps will appear different on different computers.

    Windows Presentation Foundation (WPF) main claim to fame is that it is platform-independent -- and, yes, it is fancier. Some of the examples I ran used WPF instead of WF. The form is defined in a kind of XML called XAML (Extensible Application Markup Language). To create a WPF form, you add a WPF form to the project and drop controls onto it and give them all names and change their Text properties, etc. But then you go into the xaml file, define a grid with rows and columns and whatever rowspans and colspans you need, and then you edit each controls xaml tag to place it in the appropriate grid cells. That way, each control is placed exactly where you want it and it will look the same on whatever platform.

    The book also says:
    XAML is, however, a much more powerful language than ASP.NET, and is not limited by the capabilites of HTML when it is rendered for display to a user. XAML is designed with today's powerful graphics cards in mind, and as such it enables you to use all the advanced capabilities that these graphics cards offer through DirectX7 or later.
    Of course, there's lots more functionality than just that, but that's what WPF looks like from a beginner's perspective. And as far as I can tell, the C# code behind a WPF UI is the same as that which is behind a WF UI.
  16. #9
  17. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    Originally Posted by jcafaro10
    ... and certain things like number buttons I would think should be laid out using loops to minimize code repetition etc.
    ???

    A stupid question if I may, so that we don't make unwarranted assumptions:
    Have you done any Windows programming before?

    I will now proceed with the assumption that your answer was "no". My apologies if that assumption is wrong.

    Writing a GUI app is a very different way of thinking than writing a console app.

    In a console program, we have to set up the sequence of everything that happens. That includes all kinds of task loops.

    In Windows, you write event handlers, so your program is written disjointly in order to react to specific events.

    In classic SDK (AKA "Petzold"), your WinMain registers itself with Windows, gives Windows the address of its WndProc call-back function, and then goes into a loop in which it receives messages that Windows sends to it and preps them ("message pumping" -- I never really looked into the details here; the code is the same for just about every app). When there's an event (AKA "something happens", like a mouse click or mouse move, and a key on the keyboard is depressed, a window is moved, or a window is resized), Windows then calls your WndProc and passes a message to it: each message has an ID that identifies the kind of event and two parameters, a LONG and a WORD, that contain information about that event. Those parameters can have a lot encoded into them; extracting that info is called "message cracking" that WndProc must perform, but which MFC and Windows Forms do for you.

    WndProc is just one monstrous switch statement. For each event you want your app to handle, you add a case for that event in that giant switch statement and include the code that will handle that event. That, in a nutshell, is Windows programming.

    Windows frameworks, such as MFC and Windows Forms, encapsulate a lot of those details, such as the WinMain, the "message pumping", message cracking, and WndProc's giant switch statement. Instead, they set it up so that you can just add each "case" as its own separate function that's called whenever there's that event.


    So in your calculator, you define each key as a button and you add a Click event handler. Then you write the code fragment to handle the clicking of that key. Of course, that code fragment can call another function or, better yet, a Calculator object's method (I'm assuming that you have an object to handle that). For example, if a "3" is clicked, then call a calculator method for entering a numeric key and pass it the value, 3. If a "+" is pressed, then call the method for performing an addition.

    But notice that no looping is involved, but rather just reacting to each individual event as it happens.
  18. #10
  19. /(bb|[^b]{2})/

    Join Date
    Nov 2001
    Location
    Somewhere in the great unknown
    Posts
    5,163
    Rep Power
    792
    Sounds like an excellent book.

    Also, fyi for using Application.Run()
    this is what a standard WF startup looks like
    Code:
    using System;
    using System.Collections.Generic;
    using System.Windows.Forms;
    
    namespace SomeAppNamespace 
    {
        static class Program
        {
            /// <summary>
            /// The main entry point for the application.
            /// </summary>
            [STAThread]
            static void Main()
            {
                 Application.EnableVisualStyles();
                 Application.SetCompatibleTextRenderingDefault(false);
                 Application.Run(new Form1());
            }
        }
    }
  20. #11
  21. ASP.Net MVP
    Devshed Specialist (4000 - 4499 posts)

    Join Date
    Aug 2003
    Location
    WI
    Posts
    4,378
    Rep Power
    1510
    There's really not much to windows forms, in that it hides the mess from you. The easiest way to pick it up is to just download visual C# express and start using it.
    Primary Forum: .Net Development
    Holy cow, I'm now an ASP.Net MVP!

    [Moving to ASP.Net] | [.Net Dos and Don't for VB6 Programmers]

    http://twitter.com/jcoehoorn
  22. #12
  23. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2008
    Posts
    62
    Rep Power
    0
    Originally Posted by dwise1_aol
    ???

    A stupid question if I may, so that we don't make unwarranted assumptions:
    Have you done any Windows programming before?

    I will now proceed with the assumption that your answer was "no". My apologies if that assumption is wrong.

    Writing a GUI app is a very different way of thinking than writing a console app.

    In a console program, we have to set up the sequence of everything that happens. That includes all kinds of task loops.

    In Windows, you write event handlers, so your program is written disjointly in order to react to specific events.

    In classic SDK (AKA "Petzold"), your WinMain registers itself with Windows, gives Windows the address of its WndProc call-back function, and then goes into a loop in which it receives messages that Windows sends to it and preps them ("message pumping" -- I never really looked into the details here; the code is the same for just about every app). When there's an event (AKA "something happens", like a mouse click or mouse move, and a key on the keyboard is depressed, a window is moved, or a window is resized), Windows then calls your WndProc and passes a message to it: each message has an ID that identifies the kind of event and two parameters, a LONG and a WORD, that contain information about that event. Those parameters can have a lot encoded into them; extracting that info is called "message cracking" that WndProc must perform, but which MFC and Windows Forms do for you.

    WndProc is just one monstrous switch statement. For each event you want your app to handle, you add a case for that event in that giant switch statement and include the code that will handle that event. That, in a nutshell, is Windows programming.

    Windows frameworks, such as MFC and Windows Forms, encapsulate a lot of those details, such as the WinMain, the "message pumping", message cracking, and WndProc's giant switch statement. Instead, they set it up so that you can just add each "case" as its own separate function that's called whenever there's that event.


    So in your calculator, you define each key as a button and you add a Click event handler. Then you write the code fragment to handle the clicking of that key. Of course, that code fragment can call another function or, better yet, a Calculator object's method (I'm assuming that you have an object to handle that). For example, if a "3" is clicked, then call a calculator method for entering a numeric key and pass it the value, 3. If a "+" is pressed, then call the method for performing an addition.

    But notice that no looping is involved, but rather just reacting to each individual event as it happens.
    I think you misunderstood my question. I understand how events work. My question is about LAYING OUT the components. I'm used to java where I don't have a visual editor and so I've only ever laid out components in code and so for example if I wanted to add buttons to a calculator I'd perhaps write a loop to add each button, since most of them are very simpler. In C#, Visual Studio, I have a graphical interface by which to add items to the screen. I can drag a bunch of buttons onto my screen no problem but the code that gets generated is very repetitive. I'm curious if it matters as far as programming practices.
  24. #13
  25. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    Yeah, in Java you have to write code that constructs the GUI, whereas in VS you construct the GUI at design time. I haven't looked at the code that generates, but I don't think there's any optimization that you could do there.

    As for each button having its own personal Click event handler, here's a thought. Write just one Click event handler for all the keys, or at least one for all the numeric keys, another one for all the function keys, however you want to do that. When you set up the Click events for each button, set it to that one handler; that way all the keys will be pointing to that one common event handler. Then in the event handler, cast the sender parameter to the Button class and test for which button it was; when you find a match, then you use its value in the processing.

    Is that along the lines of what you're looking for?
  26. #14
  27. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2008
    Posts
    62
    Rep Power
    0
    Originally Posted by dwise1_aol
    Yeah, in Java you have to write code that constructs the GUI, whereas in VS you construct the GUI at design time. I haven't looked at the code that generates, but I don't think there's any optimization that you could do there.

    As for each button having its own personal Click event handler, here's a thought. Write just one Click event handler for all the keys, or at least one for all the numeric keys, another one for all the function keys, however you want to do that. When you set up the Click events for each button, set it to that one handler; that way all the keys will be pointing to that one common event handler. Then in the event handler, cast the sender parameter to the Button class and test for which button it was; when you find a match, then you use its value in the processing.

    Is that along the lines of what you're looking for?
    Sort of. I had already figured that out. I don't need a different handler for each button, if I'm smart about how I do things. I was mostly curious about the GUI layout as I said but you said you never look at the generated code.
  28. #15
  29. /(bb|[^b]{2})/

    Join Date
    Nov 2001
    Location
    Somewhere in the great unknown
    Posts
    5,163
    Rep Power
    792
    Rarely will you have to deal with the generated code. Occasionally you will have to remove an event handler (so it's good to review the generated code and understand what it does) but it's rare.
Page 1 of 2 12 Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo