Sams Teach Yourself C# in 24 Hours
- Table of Contents
- Copyright
- About the Authors
- Acknowledgments
- Tell Us What You Think!
- Introduction
- Audience and Organization
- Conventions Used in This Book
- Onward and Upward!
- Part I. The Visual Studio Environment
- Hour 1. A C# Programming Tour
- Hour 2. Navigating C#
- Hour 3. Understanding Objects and Collections
- Hour 4. Understanding Events
- Part II. Building a User Interface
- Hour 5. Building FormsPart I
- Hour 6. Building FormsPart II
- Hour 7. Working with the Traditional Controls
- Hour 8. Advanced Controls
- Hour 9. Adding Menus and Toolbars to Forms
- Hour 10. Drawing and Printing
- Part III. Making Things HappenProgramming!
- Hour 11. Creating and Calling Methods
- Hour 12. Using Constants, Data Types, Variables, and Arrays
- Hour 13. Performing Arithmetic, String Manipulation, and Date/Time Adjustments
- Hour 14. Making Decisions in C# Code
- Hour 15. Looping for Efficiency
- Hour 16. Debugging Your Code
- Hour 17. Designing Objects Using Classes
- Hour 18. Interacting with Users
- Part IV. Working with Data
- Hour 19. Performing File Operations
- Hour 20. Controlling Other Applications Using Automation
- Hour 21. Working with a Database
- Part V. Deploying Solutions and Beyond
- Hour 22. Deploying a Solution
- Hour 23. Introduction to Web Development
- Hour 24. The 10,000-Foot View
- Appendix A. Answers to Quizzes/Exercises
Q&A
-
Should I alert the user that an exception has occurred to just let the code keep running?
If you've written code to handle the specific exception, then there's probably no need to tell the user about it. However, if an exception occurs that the code doesn't know how to address, you should provide the user with the exception information so that he or she can report the problem and you can fix it.
-
Should I comment every statement in my application?
Probably not. However, you should consider commenting every decision-making and looping construct in your program. Usually, these sections of code are pivotal to the success of the procedure, and it's not always obvious what they do.
-
I'm tired of writing out the full qualifier System.Diagnostics.Debug.WriteLine(). Is there anyway to shorten this?
Yes, by adding a using directive for the System.Diagnostics namespace, you will be able to access its members without having to specify the namespace. This will shorten all your System.Diagnostics.Debug.WriteLine() statements to Debug. WriteLine().
Workshop | Next Section

Account Sign In
View your cart