With your code sample, you are missing the part to tells the XmlTextWriter what encoding to use. If you use any class that is derived from a TextWriter (like StringWriter), then you can't specify the encoding. The reason for this is that the base string in a StringWriter is UTF-16, so you have no options for using a different Encoding. If however, you use a MemoryStream, or something derived directly from Stream, then you can specify a different Encoding. Anyway, here is a code snippet that describes this:

        MemoryStream ms = new MemoryStream();

        //Set the encoding to UTF8:
        XmlTextWriter writer = new XmlTextWriter(ms, Encoding.UTF8);

        //Just makes the xml easier to read:
        writer.Formatting = Formatting.Indented;

        //Write out our xml document:
        writer.WriteStartDocument();
        writer.WriteStartElement("Stock");
        writer.WriteAttributeString("Symbol", "123");
        writer.WriteElementString("Price", "456");
        writer.WriteElementString("Change", "abc");
        writer.WriteElementString("Volume", "edd");
        writer.WriteEndElement();

        //Reset our stream's read pointer, so we can read back from our memory stream:
        writer.Flush();
        ms.Seek(0, SeekOrigin.Begin);

        //Read our memory stream, and output to console:
        StreamReader sr = new StreamReader(ms);
        string content = sr.ReadToEnd();
        Console.WriteLine(content);

        return;

It is important to note that you could have used a similar technique in your original code when you used the XmlDocument. The reason why you were getting the UTF-16 encoding is because your underlying writer class was a string. StringWriter writes directly to a string (or possibly a StringBuilder). And because strings in .NET are all UTF-16, that is the encoding you got. When you write directly to a stream (FileStream, MemoryStream, etc), then you are not writing to a string, but conceptually you are writing to just an array of bytes. Because of that you can specify a different encoding. Anyway, I hope this helps you out.

You are using StringWriter, and it "Implements a TextWriter for writing information to a string." (http://msdn.microsoft.com/en-us/library/system.io.stringwriter.aspx[^])

Looking at msdn documenation: http://msdn.microsoft.com/en-us/library/system.xml.xmldocument.createxmldeclaration.aspx[^] The section about encoding says, "The value of the encoding attribute. This is the encoding that is used when you save the XmlDocument to a file or a stream; therefore, it must be set to a string supported by the Encoding class, otherwise Save fails. If this is nullNothingnullptra null reference (Nothing in Visual Basic) or String.Empty, the Save method does not write an encoding attribute on the XML declaration and therefore the default encoding, UTF-8, is used. Note: If the XmlDocument is saved to either a TextWriter or an XmlTextWriter, this encoding value is discarded. Instead, the encoding of the TextWriter or the XmlTextWriter is used. This ensures that the XML written out can be read back using the correct encoding. " So I would guess that the "note" applies in your case. Your StringWriter that you are saving to is causing the encoding value to be ignored. (I imagine that the underlying StringBuilder is using UTF-16 strings) If you were to use the XmlTextWriter, then you can specify the encoding that you want.

Could you just disable usb in device manager. As long as people using the machine don't have admin access, problem solved. :)

The same would wherever you registered your domain. If you registered your domain with a different company, and you have an issue with them, they could also hold your domain name hostage. :)

https://www.nearlyfreespeech.net/[^] They are a pay as you go, and you can pretty much put down as much or as little as you want. I'm using them, and have never had any problems, they are also fairly competitive with domain-name registering. (I think it was about $7US/year) If you need email, definately go with google apps http://www.google.com/a/[^]. It's free, and you get a gmail-like interface.

Sometimes it works for me, and sometimes it doesnt. Maybe I am just "text select-ionally" challenged. ;)

I've been using Microsoft's OneNote lately, and I actually like it. :)

I especially love how they've disabled selecting it, so you can't copy/paste the number. :) I think they kind of missed the point of the captha system.

This might be a long shot, but we've had problems like this with different regional settings. The ToShortDateString() "uses formatting information derived from the current culture." Another thing to try (even longer shot), is to make sure that the collation on your server is expecting your dates in the format that ToShortDateString() is returning.

Try this:if( IsWindow( m_pStats.m_hWnd ) == FALSE ) { //create m_pStats window } else { //Set m_pStats active }