First of all, please see my comment to the question.
As you should already know, to print anything in your
application, you need to use the class
A simple code sample at the end of this MSDN help page clearly explains how to do it.
But the idea of "printing of control", I think, is related to some usability misconception. In most cases, you need to print data, not the panel, form or something directly reproducing the look of your UI. Paper document is paper document, screen is screen. I'll explain. Consider you have a button and a check box on your container control like a panel. On screen, it can click on check box and change is status, as well as the state of some underlying object, for example, some instance of some data model. If you click on a button, you can get trigger some processing, which can do something unrelated to a current look of your screen, for example, process existing data and generate completely new view out of it. On paper, what can your user to click on? Showing those boxes and buttons can only be confusing. That's why
is abstracted from the controls.
At the same time, the look of the
make look very close to what you want in print. But there are other problems. First, layout should be different. In print, you have to format data to fit the page, which is very different for screen, especially if you need the table to span more than one page.
More importantly, this is a wrong in terms of architecture and isolation of UI layer. You need to have a separate data layer. When you show your grid view and populated it, you do it from the data layer. Likewise, you should create a print from the data layer, not from UI.