Stefano Demiliani WeBlog

OS bootable from CD: a Windows solutions

From my post about this problem, David Cumps gives me an interesting link that I want to share with you: PE Builder, from Bart Lagerweij.

Bart's PE Builder helps you build a "BartPE" (Bart Preinstalled Environment) bootable Windows CD-Rom or DVD from Windows XP or Windows Server 2003 very suitable for PC maintenance tasks.

It will give you a complete Win32 environment with network support, a graphical user interface (800x600) and FAT/NTFS/CDFS filesystem support. Very handy for burn-in testing systems with no OS, rescuing files to a network share, virus scan and so on.
This will replace any Dos bootdisk in no time!

Check it... I think it could be one of my favourite tools!

Convert Datareader into Dataset part 2

My Blog about this problems generate an on-going discussion on Roy Osherove Blog.

I see very interesting the solutions that Josh say us, and I want to put evidence about it.

Josh say this:

Basically, the DbDataAdapter class (which all provider specific DataAdapters derive from) already contains a protected Fill overload that takes an IDataReader as a parameter.

So, create a custom class that derives from DbDataAdapter, and expose that functionality with a public method, as follows:

public class DataReaderAdapter : DbDataAdapter {
public int FillFromReader(DataTable dataTable, IDataReader dataReader){
return this.Fill(dataTable, dataReader);
}
}

(You are also required to override 4 events. I left them out of this example for brevity. My implementation didnt include any code in the events, just the base implementation provided by VS.NET 2003.)

Now, in your code, it is as easy as:

SqlDataReader dr = cmd.ExecuteReader();
DataSet ds = new DataSet();
DataSet dt = new DataTable();
DataReaderAdapter da = new DataReaderAdapter();
da.FillFromReader(dt, dr);
ds.Tables.Add(dt)

Hurray! You will find your dataset now contains a table with all of the data from the datareader. No messing with schemas, loops, etc. Use the functionality already built into the Framework.

Thanks a lot Josh... it seems good. I'd like to have other possible solutions about this problem.

Again about my Singleton implementation...

 Roy Osherove gives me his opinion about my singleton implementation... here are his comments:

The main points of a Singleton:

• No new instances of the Singleton class can be created
• There should be one existing instance for use which cannot be destroyed

To do this in a winform the steps should be:

• Make the constructor private (so that no one create a new instance)
• Add a private shared _instance variable of type Form1
• Add a public shared and readonly property that exposes the variable, called "Instance"
• Use this property to run the application

Here's an example(VB.NET):

End Class

 Module Module1

    Public Sub Main()

        Application.Run(Form1.Instance)

    End Sub

End Module

Could be this a good solution? Opinions?

Update

Stuart adds a very important comment about the Roy solution on Singleton implementation (I'm really surprised for the discussions that my Blog on this topic has caused ^_^ ):

Forms are a slightly more complex animal than other classes in that a form instance can be destroyed at will by the end user.  When a form is closed, its controls and its base class are disposed.  This is not desired behavior in a singleton class because once an object has been disposed, it can no longer be accessed (or, in the case of a form, displayed).  To see this undesired behavior in action, simply attempt to launch Roy's singleton form twice in succession and observe the System.ObjectDisposedException that gets thrown.

Solving this problem is easy, though.  Simply override OnClosing(), cancel the close, and hide the form instead.

   Protected Overrides Sub OnClosing(ByVal e As System.ComponentModel.CancelEventArgs)
      e.Cancel = True
      Me.Hide()
   End Sub

Now when the user closes the form, the form merely hides instead of disposing and everything works as expected (until you start trying to use singleton forms as MDI children, but that's the subject of a different post). 

Good!

Save a Windows Form in a file

How can I save an entire visible Windows Form in a file?

We can use the function described below, that uses some Win32 APIs:

•  GetWindowDC retrieves a device context that represents the context of the entire window, non-client area included (the Graphics object from GDI+ works only with the client area).
• ReleaseDC releases the retrieved device context by GetWindowDC
• BitBlt copy the contents of a device context to an other, and permits to specify the source area to copy and the destination area.

' Win32 API Declarations
Private Declare Function BitBlt Lib "gdi32.dll" (ByVal hdcDest As IntPtr, ByVal x As Int32, ByVal y As Int32, ByVal Width As Int32, ByVal Height As Int32, ByVal hdcSrc As IntPtr, ByVal XSrc As Int32, ByVal YSrc As Int32, ByVal dwRop As Int32) As Boolean
Private Declare Function GetWindowDC Lib "user32" (ByVal hWnd As IntPtr) As IntPtr
Private Declare Function ReleaseDC Lib "user32" (ByVal hWnd As IntPtr, ByVal hDc As IntPtr) As IntPtr

Public Sub SaveFormToFile(ByVal form As Form, ByVal fileName As String)
    ' Create a memorybitmap with the dimension of the Form to save 
    Dim memImage As New Bitmap(form.Width, form.Height)
    ' Create a Graphics object associated to the memorybitmap
    Dim memGraphic As Graphics = Graphics.FromImage(memImage)
    ' Retrieve the device context associated to the entire form and Graphics object
    Dim dc1 As IntPtr = GetWindowDC(form.Handle)
    Dim dc2 As IntPtr = memGraphic.GetHdc
    ' Copy the form content to the memorybitmap
    BitBlt(dc2, 0, 0, Me.Size.Width, Me.Size.Height, dc1, 0, 0, &HCC0020)
    ' Release the handles and Graphics object
    ReleaseDC(form.Handle, dc1)
    memGraphic.ReleaseHdc(dc2)
    memGraphic.Dispose()
    ' Save the memorybitmap in a .JPG file
    memImage.Save(fileName, System.Drawing.Imaging.ImageFormat.Jpeg)
End Sub

Google Mail... maybe soon!