C# Tutorial - Simple Threaded TCP Server

In this tutorial I'm going to show you how to build a threaded tcp server with C#. If you've ever worked with Window's sockets, you know how difficult this can sometimes be. However, thanks to the .NET framework, making one is a lot easier than it used to be.

What we'll be building today is a very simple server that accepts client connections and can send and receive data. The server spawns a thread for each client and can, in theory, accept as many connections as you want (although in practice this is limited because you can only spawn so many threads before Windows will get upset).

Let's just jump into some code. Below is the basic setup for our TCP server class.

using System;
using System.Text;
using System.Net.Sockets;
using System.Threading;
using System.Net;

namespace TCPServerTutorial
{
  class Server
  {
    private TcpListener tcpListener;
    private Thread listenThread;

    public Server()
    {
      this.tcpListener = new TcpListener(IPAddress.Any, 3000);
      this.listenThread = new Thread(new ThreadStart(ListenForClients));
      this.listenThread.Start();
    }
  }
}

So here's a basic server class - without the guts. We've got a TcpListener which does a good job of wrapping up the underlying socket communication, and a Thread which will be listening for client connections. You might have noticed the function ListenForClients that is used for our ThreadStart delegate. Let's see what that looks like.

private void ListenForClients()
{
  this.tcpListener.Start();

  while (true)
  {
    //blocks until a client has connected to the server
    TcpClient client = this.tcpListener.AcceptTcpClient();

    //create a thread to handle communication
    //with connected client
    Thread clientThread = new Thread(new ParameterizedThreadStart(HandleClientComm));
    clientThread.Start(client);
  }
}

This function is pretty simple. First it starts our TcpListener and then sits in a loop accepting connections. The call to AcceptTcpClient will block until a client has connected, at which point we fire off a thread to handle communication with our new client. I used a ParameterizedThreadStart delegate so I could pass the TcpClient object returned by the AcceptTcpClient call to our new thread.

The function I used for the ParameterizedThreadStart is called HandleClientComm. This function is responsible for reading data from the client. Let's have a look at it.

private void HandleClientComm(object client)
{
  TcpClient tcpClient = (TcpClient)client;
  NetworkStream clientStream = tcpClient.GetStream();

  byte[] message = new byte[4096];
  int bytesRead;

  while (true)
  {
    bytesRead = 0;

    try
    {
      //blocks until a client sends a message
      bytesRead = clientStream.Read(message, 0, 4096);
    }
    catch
    {
      //a socket error has occured
      break;
    }

    if (bytesRead == 0)
    {
      //the client has disconnected from the server
      break;
    }

    //message has successfully been received
    ASCIIEncoding encoder = new ASCIIEncoding();
    System.Diagnostics.Debug.WriteLine(encoder.GetString(message, 0, bytesRead));
  }

  tcpClient.Close();
}

The first thing we need to do is cast client as a TcpClient object since the ParameterizedThreadStart delegate can only accept object types. Next, we get the NetworkStream from the TcpClient, which we'll be using to do our reading. After that we simply sit in a while true loop reading information from the client. The Read call will block indefinitely until a message from the client has been received. If you read zero bytes from the client, you know the client has disconnected. Otherwise, a message has been successfully received from the server. In my example code, I simply convert the byte array to a string and push it to the debug console. You will, of course, do something more interesting with the data - I hope. If the socket has an error or the client disconnects, you should call Close on the TcpClient object to free up any resources it was using.

Believe it or not, that's pretty much all you need to do to create a threaded server that accepts connections and reads data from clients. However, a server isn't very useful if it can't send data back, so let's look at how to send data to one of our connected clients.

NetworkStream clientStream = tcpClient.GetStream();
ASCIIEncoding encoder = new ASCIIEncoding();
byte[] buffer = encoder.GetBytes("Hello Client!");

clientStream.Write(buffer, 0 , buffer.Length);
clientStream.Flush();

Do you remember the TcpClient object that was returned from the call AcceptTcpClient? Well, that's the object we'll be using to send data back to that client. That being said, you'll probably want to keep those objects around somewhere in your server. I usually keep a collection of TcpClient objects that I can use later. Sending data to connected clients is very simple. All you have to do is call Write on the the client's NetworkStream object and pass it the byte array you'd like to send.

Your TCP server is now finished. The hard part is defining a good protocol to use for sending information between the client and server. Application level protocols are generally unique for application, so I'm not going to go into any details - you'll just have to invent you're own.

But what use is a server without a client to connect to it? This tutorial is mainly about the server, but here's a quick piece of code that shows you how to set up a basic TCP connection and send it a piece of data.

TcpClient client = new TcpClient();

IPEndPoint serverEndPoint = new IPEndPoint(IPAddress.Parse("127.0.0.1"), 3000);

client.Connect(serverEndPoint);

NetworkStream clientStream = client.GetStream();

ASCIIEncoding encoder = new ASCIIEncoding();
byte[] buffer = encoder.GetBytes("Hello Server!");

clientStream.Write(buffer, 0 , buffer.Length);
clientStream.Flush();

The first thing we need to do is get the client connected to the server. We use the TcpClient.Connect method to do this. It needs the IPEndPoint of our server to make the connection - in this case I connect it to localhost on port 3000. I then simply send the server the string "Hello Server!".

One very important thing to remember is that one write from the client or server does not always equal one read on the receiving end. For instance, your client could send 10 bytes to the server, but the server may not get all 10 bytes the first time it reads. Using TCP, you're pretty much guaranteed to eventually get all 10 bytes, but it might take more than one read. You should keep that in mind when designing your protocol.
That's it! Now get out there and clog the tubes with your fancy new C# TCP servers. As always, comments and questions are welcome.

ref : http://www.switchonthecode.com/tutorials/csharp-tutorial-simple-threaded-tcp-server

C# Tutorial - Serialize Objects to a File

While storing information in memory is great, there comes a time your users will have to shut your application down. This means (probably) that you will need to write information to a file at some point, because you will want to store whatever data was in memory. Today, we are going to take a look at a feature built into .NET called Serialization that makes writing and reading data structures to and from a file extremely easy.

For this example, let's say I want to create a program that keeps track of all the cars my friends own. I'm going to create two objects to achieve this: Car and Owner. The Car object will store the make, model, and year of the car. The Owner object will save some information about who owns the car. Each Car object will hold a reference to an Owner object.

//information about the car
public class Car
{
   private string make;
   private string model;
   private int year;
   private Owner owner;

   public Car()
   {
   }
}

//information about the car's owner
public class Owner
{
   private string firstName;
   private string lastName;

   public Owner()
   {
   }
}

Since most of us have more than one friend, we're going to need to create a List of Car objects.

List<Car> cars = new List<Car>();

Now that we have our objects created, we're almost ready to serialize them. When I save data to files, I like to create an object specifically to hold all the things I want to serialize.

public class ObjectToSerialize
{
   private List<Car> cars;

   public List<Car> Cars
   {
      get { return this.cars; }
      set { this.cars = value; }
   }

   public ObjectToSerialize()
   {
   }
}

This class holds a reference to every object we'll want to serialize. In this case, the only thing we want to save is the list of cars. Now lets create the functions that will perform the serialization and deserialization of our object. I usually create a Serializer class to control the writing and reading to and from files.

using System.IO;
using System.Runtime.Serialization;
using System.Runtime.Serialization.Formatters.Binary;

public class Serializer
{
   public Serializer()
   {
   }

   public void SerializeObject(string filename, ObjectToSerialize objectToSerialize)
   {
      Stream stream = File.Open(filename, FileMode.Create);
      BinaryFormatter bFormatter = new BinaryFormatter();
      bFormatter.Serialize(stream, objectToSerialize);
      stream.Close();
   }

   public ObjectToSerialize DeSerializeObject(string filename)
   {
      ObjectToSerialize objectToSerialize;
      Stream stream = File.Open(filename, FileMode.Open);
      BinaryFormatter bFormatter = new BinaryFormatter();
      objectToSerialize = (ObjectToSerialize)bFormatter.Deserialize(stream);
      stream.Close();
      return objectToSerialize;
   }
}

As you can see, the actual code required to serialize an object is relatively small and simple. At this point, however, the code will not build. Before the Serialize function can be called on ObjectToSerialize we must include the Serializable attribute and it must implement the ISerializable interface.

using System.Runtime.Serialization;
using System.Runtime.Serialization.Formatters.Binary;

[Serializable()]
public class ObjectToSerialize : ISerializable
{
   private List<Car> cars;

   public List<Car> Cars
   {
      get { return this.cars; }
      set { this.cars = value; }
   }

   public ObjectToSerialize()
   {
   }

   public ObjectToSerialize(SerializationInfo info, StreamingContext ctxt)
   {
      this.cars = (List<Car>)info.GetValue("Cars", typeof(List<Car>));
   }

   public void GetObjectData(SerializationInfo info, StreamingContext ctxt)
   {
      info.AddValue("Cars", this.cars);
   }
}

As part of the ISerializable interface, the class must include another constructor for deserializing the object and a function GetObjectData which describes how to serialize the object. Since the Car and Owner objects are also being serialized, they will also need to implement these functions.

[Serializable()]
public class Car : ISerializable
{
   private string make;
   private string model;
   private int year;
   private Owner owner;

   public Car()
   {
   }

   public Car(SerializationInfo info, StreamingContext ctxt)
   {
      this.make = (string)info.GetValue("Make", typeof(string));
      this.model = (string)info.GetValue("Model",typeof(string));
      this.year = (string)info.GetValue("Year", typeof(int));
      this.owner = (Owner)info.GetValue("Owner", typeof(Owner));
   }

   public void GetObjectData(SerializationInfo info, StreamingContext ctxt)
   {
      info.AddValue("Make", this.make);
      info.AddValue("Model", this.model);
      info.AddValue("Make", this.year);
      info.AddValue("Owner", this.owner);
   }
}


[Serializable()]
public class Owner : ISerializable
{
   private string firstName;
   private string lastName;

   public Owner()
   {
   }

   public Owner(SerializationInfo info, StreamingContext ctxt)
   {
      this.firstName = (string)info.GetValue("FirstName", typeof(string));
      this.lastName = (string)info.GetValue("LastName", typeof(string));
   }

   public void GetObjectData(SerializationInfo info, StreamingContext ctxt)
   {
      info.AddValue("FirstName", this.firstName);
      info.AddValue("LastName", this.lastName);
   }
}

Now, to save the list of objects to a file, all that needs to be done is to call the Serialize and DeSerialize functions of the Serializer class.

List<Car> cars = new List<Car>();

//save the car list to a file
ObjectToSerialize objectToSerialize = new ObjectToSerialize();
objectToSerialize.Cars = cars;

Serializer serializer = new Serializer()
serializer.SerializeObject("outputFile.txt", objectToSerialize);

//the car list has been saved to outputFile.txt
//read the file back from outputFile.txt

objectToSerialize = serializer.DeSerializeObject("outputFile.txt");
cars = objectToSerialize.Cars;

That is all that's required to save and load custom C# objects to a binary file. Just like any file, it is possible for your files to become corrupted. Because of this, it is probably a good idea to add some error handling whenever output from the file is being cast to an object.

ref :  http://www.switchonthecode.com/tutorials/csharp-tutorial-serialize-objects-to-a-file

C# Tutorial - XML Serialization

A long while ago we posted a tutorial on how to serialize objects to a binary file. While this is very useful, unfortunately the resulting file is not very human readable. In this tutorial, I'm going to demonstrate how to serialize your own objects to and from an XML file.

Since .NET can use reflection to get property names, basic serialization is unbelievably simple. It only gets slightly difficult when you want to name your XML tags differently than your property names (but still not very hard). If you've ever used an XML serialization package in C++ like boost, tinyXML, or libXML2, you'll see how comparatively easy C# is to use.

Let's start with a basic example. Below is an object that stores some information about a movie.

public class Movie
{
  public string Title
  { get; set; }

  public int Rating
  { get; set; }

  public DateTime ReleaseDate
  { get; set; }
}

All right, now that we have an object, let's write a function that will save it to XML.

static public void SerializeToXML(Movie movie)
{
  XmlSerializer serializer = new XmlSerializer(typeof(Movie));
  TextWriter textWriter = new StreamWriter(@"C:\movie.xml");
  serializer.Serialize(textWriter, movie);
  textWriter.Close();
}

The first thing I do is create an XMLSerializer (located in the System.Xml.Serialization namespace) that will serialize objects of type Movie. The XMLSerializer will serialize objects to a stream, so we'll have to create one of those next. In this case, I want to serialize it to a file, so I create a TextWriter. I then simply call Serialize on the XMLSerializer passing in the stream (textWriter) and the object (movie). Lastly I close the TextWriter because you should always close opened files. That's it! Let's create a movie object and see how this is used.

static void Main(string[] args)
{
  Movie movie = new Movie();
  movie.Title = "Starship Troopers";
  movie.ReleaseDate = DateTime.Parse("11/7/1997");
  movie.Rating = 6.9f;

  SerializeToXML(movie);
}

static public void SerializeToXML(Movie movie)
{
  XmlSerializer serializer = new XmlSerializer(typeof(Movie));
  TextWriter textWriter = new StreamWriter(@"C:\movie.xml");
  serializer.Serialize(textWriter, movie);
  textWriter.Close();
}

After this code executes, we'll have an XML file with the contents of our movie object.

version="1.0" encoding="utf-8"?>
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  >
  >6.9

>
  >1997-11-07T00:00:00>
>
If you noticed, all of the XML tag names are the same as the property names. If we want to change those, we can simply add an attribute above each property that sets the tag name.

public class Movie
{
  [XmlElement("MovieName")]
  public string Title
  { get; set; }

  [XmlElement("MovieRating")]
  public float Rating
  { get; set; }

  [XmlElement("MovieReleaseDate")]
  public DateTime ReleaseDate
  { get; set; }
}

Now when the same code is executed again, we get our custom tag names.

version="1.0" encoding="utf-8"?>
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  >Starship Troopers

>
  >6.9>
  >1997-11-07T00:00:00>
>
Sometimes, in XML, you want information stored as an attribute of another tag instead of a tag by itself. This can be easily accomplished with another property attribute.

public class Movie
{
  [XmlAttribute("MovieName")]
  public string Title
  { get; set; }

  [XmlElement("MovieRating")]
  public float Rating
  { get; set; }

  [XmlElement("MovieReleaseDate")]
  public DateTime ReleaseDate
  { get; set; }
}

With this code, MovieName will now be an attribute on the Movie tag.

version="1.0" encoding="utf-8"?>
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   MovieName="Starship Troopers">
  >6.9

>
  >1997-11-07T00:00:00>
>
Let's move on to something a little more interesting. Let's create another movie and serialize a List of them to our XML file. Here's the modified code to do just that:

static void Main(string[] args)
{
  Movie movie = new Movie();
  movie.Title = "Starship Troopers";
  movie.ReleaseDate = DateTime.Parse("11/7/1997");
  movie.Rating = 6.9f;

  Movie movie2 = new Movie();
  movie2.Title = "Ace Ventura: When Nature Calls";
  movie2.ReleaseDate = DateTime.Parse("11/10/1995");
  movie2.Rating = 5.4f;

  List<Movie> movies = new List<Movie>() { movie, movie2 };

  SerializeToXML(movies);
}

static public void SerializeToXML(List<Movie> movies)
{
  XmlSerializer serializer = new XmlSerializer(typeof(List<Movie>));
  TextWriter textWriter = new StreamWriter(@"C:\movie.xml");
  serializer.Serialize(textWriter, movies);
  textWriter.Close();
}

Now we have XML that looks like this:

version="1.0" encoding="utf-8"?>
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  MovieName="Starship Troopers">
    >6.9

>
    >1997-11-07T00:00:00>
  >
  MovieName="Ace Ventura: When Nature Calls">
    >5.4>
    >1995-11-10T00:00:00>
  >
>
Ok, so you can see how easy it is to get your objects into an XML document. Let's now look at how to read an XML document back into our objects - deserialization. The process of deserializing is very similar to what we did for serialization.

static List<Movie> DeserializeFromXML()
{
   XmlSerializer deserializer = new XmlSerializer(typeof(List<Movie>));
   TextReader textReader = new StreamReader(@"C:\movie.xml");
   List<Movie> movies;
   movies = (List<Movie>)deserializer.Deserialize(textReader);
   textReader.Close();

   return movies;
}

Just like before, we first create an XmlSerializer that can deserialize objects of type List. The XmlSerializer also deserializes from a stream, so we create a file stream from our XML file. We then simply call Deserialize on the stream and cast the output to our desired type. Now the movies List is populated with objects that we previously serialized to the XML file.

The deserializer is very good at handling missing pieces of information in your XML file. Let's say the second movie didn't have the MovieName attribute on the Movie tag. When the XML file is deserialized, it simply populates that field with null. If MovieRating wasn't there, you'd receive 0. Since a DateTime object can't be null, if MovieReleaseDate was missing, you'd receive DateTime.MinValue (1/1/0001 12:00:00AM).

If the XML document contains invalid syntax, like say the first opening Movie tag was missing, the Deserialize call will fail with an InvalidOperationException. It will also be kind enough to specify the location in the file where it encountered the error (line number, column number).

One thing to remember is that the basic XML serialization won't maintain references. Let's say I populated my movies list with the same movie reference multiple times:

Movie movie = new Movie();
movie.Title = "Starship Troopers";
movie.ReleaseDate = DateTime.Parse("11/7/1997");
movie.Rating = 6.9f;

List<Movie> movies = new List<Movie>() { movie, movie };

Now I have a list containing two of the exact same movie reference. When I serialize and deserialize this list, it will be converted to two separate instances of the movie object - they would just have the same information. Along this same line, the XMLSerializer also doesn't support circular references. If you need this kind of flexibility, you should consider binary serialization.

There's still a lot to cover when it comes to XML serialization, but I think this tutorial covers enough of the basics to get things rolling. If you've got questions or anything else to say, leave us a comment.

ref : http://www.switchonthecode.com/tutorials/csharp-tutorial-xml-serialization

Những điều chưa tiết lộ về công việc của một lập trình viên

Lập trình là một công việc như thế nào? Có phải lập trình viên là những người tối ngày ngồi trước màn hình máy tính? Cứ code giỏi thì sản phẩm sẽ tốt?

Bạn hình dung lập trình viên là người luôn gắn chặt với chiếc máy tính, tay anh ta thì liên tục gõ và gõ các dòng lệnh khô khan, không ai hiểu?? Đấy chỉ là những hình ảnh thường thấy trên các bộ phim của Hollywood mà thôi. Vậy sự thật thì như nào? Chúng ta hãy cùng tham khảo những chia sẻ từ kĩ sư công nghệ thông tin David Veksler – chủ trang blog The Rational Mind về những sự thật ít ai biết về nghề IT – nghề lập trình.

Những quan niệm không đúng thực tế về dân lập tình - gõ và gõ code liên tục

- Chỉ 10-20% thời gian của toàn bộ dự án được các lập trình viên sử dụng để viết code, và bất kể trình độ, mỗi ngày 1 lập trình viên chỉ viết trung bình từ 10-20 dòng code. Sự khác biệt giữa tay chuyên và gà mờ đó là tay chuyên thì dành 90% thời gian để suy luận, tìm tòi và thử nghiệm các phương án tối ưu nhất cho mình; còn những gà mờ thì dành 90% thời gian để debug, thay đổi vài chỗ trong code, lại debug và mong đến một lúc nào đó chương trình sẽ hoạt động.'

- Một lập trình viên tốt cho năng suất gấp 10 một lập trình viên tầm tầm. Một lập trình viên giỏi có thể còn hơn nữa, 20 cho đến 100 lần tùy hoàn cảnh. Đây là một sự thật không hề “gió” và đã được khoa học chứng minh từ tận những năm 60. Còn một lập trình viên tồi thì chung quy hiệu suất bằng không – chẳng làm nên chuyện gì, ngược lại vẽ ra nhiều vấn đề rối tinh rối mù cho người khác phải bận tâm sửa hộ.

“Một công nhân có kĩ thuật tiện cao siêu có thể giá trị gấp vài lần một công nhân với kĩ thuật trung bình. Nhưng một lập trình viên giỏi thì có giá trị gấp 10,000 lần một lập trình viên với trình độ trung bình.” – Bill Gates


- Các lập trình viên giỏi thường không dành nhiều thời gian để code, trái lại những người code liên tục từ lúc này sang lúc khác lại là những người lười biếng, vô tâm, kiêu ngạo và ít chịu tìm tòi nhất. Người lập trình tốt là người biết vận dụng linh hoạt mọi giải pháp mình từng vận dụng qua cho mọi vấn đề họ gặp phải; người lập trình tồi là người viết nên những đoạn code dài dòng, rắc rối, bố cục lung tung và khó để chỉnh sửa. Thực ra quẳng hết mớ code hỏng ra ngoài và bắt đầu lại từ đầu lại là một lựa chọn hữu ích hơn ngồi ì ạch sửa từng chút một.


- Định luật entropy bao hàm mọi vật – entropy là một hàm biểu thị mức độ hỗn loạn của một sự kiện diễn ra trong vô số các khả năng ngẫu nhiên có thể diễn ra. Trong lập trình, thay đổi liên tục sẽ dẫn đến phá vỡ mô hình nguyên bản của thiết kế, dẫn đến sự suy giảm giá trị phần mềm (software rot). Dẫu biết điều này là không thể tránh khỏi, song các lập trình viên không nắm bắt được hình mẫu sơ khai của dự án và biết cách biến nó thành hiện thực sẽ tạo ra những phần mềm thất bại đến nỗi giá trị đã tiêu hao sạch sẽ kể cả trước khi dự án hoàn thành, và đây thường là lý do phổ biến nhất  tạo nên các phần mềm thất bại (Lí do phổ biến thứ nhì là tạo ra những giá trị mà khách hàng không cần đến).

Một lập trình viên giỏi sẽ dành nhiều thời gian để suy luận và tìm tòi.

- Trong năm 1994, 31% các dự án phần mềm sẽ thất bại “sặc gạch” từ đầu đến chân. Con số này đến năm 2004 thì đã được cải thiện, chỉ còn 15%, song 51% các dự án thì bị thất bại trên phương diện trí mạng của mình.


Mặc dù hầu hết các phần mềm đều được xây dựng bởi các đội ngũ chứ không riêng gì ai, nhưng đó cũng không phải là một hoạt động mang tính dân chủ. Thường thì chỉ có một người duy nhất chịu trách nhiệm về thiết kế, còn lại cả đội nghĩ cách lấp đầy cách khoảng trống xuất hiện. Kết cấu này giống với một tổ ong hay kiến nhiều hơn.


Lập trình là việc của những người chăm chỉ, trong đó, đặc biệt là bộ não sẽ phải hoạt động điên cuồng. Những lập trình viên tốt nghĩ về công việc của mình 24/7. Họ viết ra những dòng code tuyệt vời nhất trong bồn tắm hay những giấc mơ. Tại sao? Bởi hầu hết các công việc quan trọng đều không được hoàn thành tại chính nơi làm việc của nó, bản thân Einstein cũng đã tháo gỡ nút thắt trong thuyết tương đối của mình khi mơ. Làm phần mềm không phải đơn giản chỉ cần dành nhiều thời gian làm việc hay thêm người vào là có thể hoàn thành.

Theo : http://www.techz.vn  

C# Tutorial - Binding a DataGridView to a Database

In this tutorial, I'm going to show a fairly simple way to bind a .NET DataGridView to a database. The form designer has some support for data binding, but I found doing it without the form designer is a little easier to understand and implement. Also, when I'm developing a desktop database application, my database schemas are rarely 100% defined, and the form designer doesn't easily support changes to the database.

The database I'm going to use for the example code will be an Access database. I know Access databases aren't the preferred database type for developers - because of their speed and scalability. However, for simple database apps, Access is hard to beat - since you don't need to install any outside database engines. In reality, the concepts shown in this tutorial can be used with any number of databases.

The first thing we'll need to do is generate a connection string to connect to our Access database. For simplicity, the database I'm using doesn't require any authentication. If your database has authentication, MSDN has some great documentation on how to accomplish that.

string connString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\\myDatabase.mdb";

The connection string is broken up into two parts, a provider and a data source. The provider is the engine we're going to be using - in this case, Microsoft's Jet engine. The data source, for Access, is simply the path to the database file.

Now let's use the connection string and get some data from our database.

//create the connection string
string connString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\\myDatabase.mdb";

//create the database query
string query = "SELECT * FROM MyTable";

//create an OleDbDataAdapter to execute the query
OleDbDataAdapter dAdapter = new OleDbDataAdapter(query, connString);

//create a command builder
OleDbCommandBuilder cBuilder = new OleDbCommandBuilder(dAdapter);

//create a DataTable to hold the query results
DataTable dTable = new DataTable();

//fill the DataTable
dAdapter.Fill(dTable);

To keep the code simple, I've left out a lot of error handling. You'll definitely want to surround dAdapter.Fill with some exception handling. That call will fail for many different reasons - for instance the database isn't where the connection string says it is, or the query string is invalid SQL code.

So let's go through what this code is actually doing. The first thing to do is to create the connection string as described above. Then we need an SQL statement to execute on our database. This can be any SELECT statement you want. Next we create an OleDbDataAdapter which serves as a bridge between our DataTable and our database. An OleDbCommandBuilder comes next. This beautiful object automatically generates SQL insert, update, and delete statements to rectify changes made to our DataTable. Next we need to make a DataTable to hold the information retrieved from the database. And lastly, we call dAdapter.Fill(dTable) which executes our SQL query and fills dTable with the results.

Now that we have a DataTable filled with database information, let's see how to synchronize it with a DataGridView.

//the DataGridView
DataGridView dgView = new DataGridView();

//BindingSource to sync DataTable and DataGridView
BindingSource bSource = new BindingSource();

//set the BindingSource DataSource
bSource.DataSource = dTable;

//set the DataGridView DataSource
dgView.DataSource = bSource;

The BindingSource object is what will be keeping our DataTable synchronized with the DataGridView. So we set the DataSource of the BindingSource to dTable, then set the DataSource of the DataGridView to the BindingSource. Now when your program runs, the DataGridView should be filled with the results of your SQL query.

At point, any changes made by the user in the DataGridView will automically be made to the DataTable, dTable. Now we need a way to get the changes back into the database. All you have to do is call the Update function of the OleDbDataAdapter with the DataTable as the argument to accomplish this.

dAdapter.Update(dTable);

This call will use the OleDbCommandBuilder to create all of the necessary SQL code to synchronize your database with the changes made to dTable. But, when should you call this function? There's lots of different answers to that. If you have a save button, call it when the user pushes save. If you want the database updated in real-time, I like to call it on the DataGridView's Validating event.

The last topic to discuss is error handling. What happens when the user types something in the DataGridView that can't be put in the database - like text where a number is supposed to go? Because you're using DataBinding, it would take a lot of work to get the data type at each column and manually make sure the user typed in the correct thing. Fortunately, the DataGridView has an event, DataError, to handle that for you. Whenever the user enters something incorrectly, this event will be fired. From this event you can get the row and column index of the cell where the incorrect value was placed, and you can also cancel the event so you don't attempt to update the database with bad data.

That's all the code required to perform two-way data binding with an Access database. If you have any questions or concerns about the above code, leave a comment.

ref : switchonthecode.com

C# Tutorial - Binding a DataGridView to a Collection

This tutorial is kind of a follow-up to my previous tutorial about binding a DataGridView to an Access database. In this tutorial, I'm going to demonstrate how to bind a DataGridView to a regular old .NET collection.

Before we can build a collection of objects, we first need an object. I tend to use a Car object for most of my examples. The car object simply holds some information about a typical car - make, model, and year. Below is the object I'm going to use.

public class Car
{
  private string _make;
  private string _model;
  private int _year;

  public Car(string make, string model, int year)
  {
    _make = make;
    _model = model;
    _year = year;
  }

  public string Make
  {
    get { return _make; }
    set { _make = value; }
  }

  public string Model
  {
    get { return _model; }
    set { _model = value; }
  }

  public int Year
  {
    get { return _year; }
    set { _year = value; }
  }
}

All right, now that we've got an object, we need a collection to hold them. One of my favorite collection objects is the List, located in the System.Collections.Generic namespace, so we'll start with that.

List<Car> cars = new List<Car>();
cars.Add(new Car("Ford", "Mustang", 1967));
cars.Add(new Car("Shelby AC", "Cobra", 1965));
cars.Add(new Car("Chevrolet", "Corvette Sting Ray", 1965));

Binding this to a DataGridView is painfully easy. Simply set the DataSource property of the DataGridView to the List.

_dgCars.DataSource = cars;

What will happen is that the DataGridView will automatically create columns for each property in the Car object, then create a row for each Car in the List. What we've created here is one-way binding. Any changes made by the user in the DataGridView will also take place in the List. If we want changes made to a Car to update the DataGridView, the Car object will have to implement the INotifyPropertyChanged interface.

public class Car : INotifyPropertyChanged
{
  private string _make;
  private string _model;
  private int _year;

  public event PropertyChangedEventHandler PropertyChanged;

  public Car(string make, string model, int year)
  {
    _make = make;
    _model = model;
    _year = year;
  }

  public string Make
  {
    get { return _make; }
    set
    {
      _make = value;
      this.NotifyPropertyChanged("Make");
    }
  }

  public string Model
  {
    get { return _model; }
    set
    {
      _model = value;
      this.NotifyPropertyChanged("Model");
    }
  }

  public int Year
  {
    get { return _year; }
    set
    {
      _year = value;
      this.NotifyPropertyChanged("Year");
    }
  }

  private void NotifyPropertyChanged(string name)
  {
    if(PropertyChanged != null)
      PropertyChanged(this, new PropertyChangedEventArgs(name));
  }
}

Unfortunately, this won't be enough. The List class does not support notifications from objects within its collection. Fortunately, there is an object that does - the BindingList. For the most part, the BindingList is used exactly like a List.

BindingList<Car> cars = new BindingList<Car>();

cars.Add(new Car("Ford", "Mustang", 1967));
cars.Add(new Car("Shelby AC", "Cobra", 1965));
cars.Add(new Car("Chevrolet", "Corvette Sting Ray", 1965));

_dgCars.DataSource = cars;

Now, if any external process, like a network thread, makes a change to a Car object, the DataGridView will automatically update to reflect the change.

Now we've got data in the DataGridView and any changes to the UI or the List will automatically update the other. Usually my properties aren't named something that are so user friendly. What happens when I want my columns named something else? This can be easily accomplished by disabling the AutoGenerateColumns property and by setting up the columns ourselves.

_dgCars.AutoGenerateColumns = false;

DataGridViewTextBoxColumn makeColumn = new DataGridViewTextBoxColumn();
makeColumn.DataPropertyName = "Make";
makeColumn.HeaderText = "The Car's Make";

DataGridViewTextBoxColumn modelColumn = new DataGridViewTextBoxColumn();
modelColumn.DataPropertyName = "Model";
modelColumn.HeaderText = "The Car's Model";

DataGridViewTextBoxColumn yearColumn = new DataGridViewTextBoxColumn();
yearColumn.DataPropertyName = "Year";
yearColumn.HeaderText = "The Car's Year";

_dgCars.Columns.Add(makeColumn);
_dgCars.Columns.Add(modelColumn);
_dgCars.Columns.Add(yearColumn);

BindingList<Car> cars = new BindingList<Car>();

cars.Add(new Car("Ford", "Mustang", 1967));
cars.Add(new Car("Shelby AC", "Cobra", 1965));
cars.Add(new Car("Chevrolet", "Corvette Sting Ray", 1965));

_dgCars.DataSource = cars;

Setting up the columns is pretty straight forward. There's all types of DataGridViewColumns, but I went with the basic TextBox version. All you have to do it set the HeaderText, which is what the user will see, and the DataPropertyName, which is the name of the property of the object that is bound to the DataGridView. Here's what our DataGridView looks like now:

I think that does it for binding a collection to a DataGridView. Data binding is a very powerful tool and we haven't even begun scratching the surface. If you have any questions leave us a comment.

ref : switchonthecode.com