I've just upgraded HtmlRenderer from version 1.4 to the latest 1.5.0.5. I immediately got the problem that instances of HtmlLabel rendered wrong all over my application when I run it in debug mode through Visual Studio 2010. If I run the application outside (still the debug build), it works fine. I traced this down to the an issue in the layout, where the method Win32Utils.GetTextMetrics (in GraphicsAdapter.MeasureString) throws an exception.
Looking at the declarations in Win32Utils, I made the following changes, which solved my problems:
```
[DllImport("gdi32.dll", EntryPoint = "GetTextMetricsW", CharSet = CharSet.Unicode)]
public static extern bool GetTextMetrics(IntPtr hdc, out TextMetric lptm);
```
```
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
internal struct TextMetric
{
public int tmHeight;
...
```
I did try to make a small test application to illustrate the problem, but that did however not exhibit this behavior. Also, I 'only' did the test on one computer, running Windows 7, 64 bit.
I hope this makes sense to you and that these or similar changes can be incorporated in the official build of HtmlRenderer.
Last, but not least, thanks for a great library. I look forward to working with all the new features.
Comments: I have tried adding only the "EntryPoint = GetTextMetricsW" part. I would make sense as all other methods in Win32Util with string parameters also use the 'W' version of the API call, but it wasn't enough to get it working. To me the strange part is that the CharSet attributes are necessary at all, given that I would assume Unicode to be default. But from the documentation from Microsoft it seems that it defaults to Ansi when using C#: > Automatically marshal strings appropriately for the target operating system. The default is Unicode on Windows NT, Windows 2000, Windows XP, and the Windows Server 2003 family; the default is Ansi on Windows 98 and Windows Me. Although the common language runtime default is Auto, languages may override this default. For example, __by default C# marks all methods and types as Ansi__. Have you ever checked the contents of the entire structure from the function call to see that all fields are valid? As I recall, you just use three values, all coming from above the part in the structure with char fields. I would suspect that fields below tmDigitizedAspectY would be wrong, unless the suggested change is made. Even if the function doesn't throw an exception. Just a thought.
Looking at the declarations in Win32Utils, I made the following changes, which solved my problems:
```
[DllImport("gdi32.dll", EntryPoint = "GetTextMetricsW", CharSet = CharSet.Unicode)]
public static extern bool GetTextMetrics(IntPtr hdc, out TextMetric lptm);
```
```
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
internal struct TextMetric
{
public int tmHeight;
...
```
I did try to make a small test application to illustrate the problem, but that did however not exhibit this behavior. Also, I 'only' did the test on one computer, running Windows 7, 64 bit.
I hope this makes sense to you and that these or similar changes can be incorporated in the official build of HtmlRenderer.
Last, but not least, thanks for a great library. I look forward to working with all the new features.
Comments: I have tried adding only the "EntryPoint = GetTextMetricsW" part. I would make sense as all other methods in Win32Util with string parameters also use the 'W' version of the API call, but it wasn't enough to get it working. To me the strange part is that the CharSet attributes are necessary at all, given that I would assume Unicode to be default. But from the documentation from Microsoft it seems that it defaults to Ansi when using C#: > Automatically marshal strings appropriately for the target operating system. The default is Unicode on Windows NT, Windows 2000, Windows XP, and the Windows Server 2003 family; the default is Ansi on Windows 98 and Windows Me. Although the common language runtime default is Auto, languages may override this default. For example, __by default C# marks all methods and types as Ansi__. Have you ever checked the contents of the entire structure from the function call to see that all fields are valid? As I recall, you just use three values, all coming from above the part in the structure with char fields. I would suspect that fields below tmDigitizedAspectY would be wrong, unless the suggested change is made. Even if the function doesn't throw an exception. Just a thought.