The SPL compiler on Prime used to do something similar

I think you will find that two-finger touchpad scrolls will generate standard scroll messages: WM_MOUSEWHEEL, WM_VSCROLL or WM_HSCROLL as appropriate. Should be easy enough to test.

It turns out the geniuses who created this project made their own resource file with their own custom format! Arrgh...the joys of legacy code!

Hi enhzflep, I incorporated code from your example into my function, and it works with the CreateHatchBrush call to create a new brush. Unfortunately, when I substitute my already-created brush, it doesn't work; I just get solid white filling the text outlines. I've verified the brush handle is the same as the nativeBrush member of my .NET Brush, which draws correctly both before and after. Can you see anything I'm doing wrong? DLLEXPORT void drawWithGdiFont (HBITMAP hBitmap, HBRUSH hbrush, LPCWSTR fontName, LPCWSTR text, int sizeToUse, bool bold, bool italic, int br, int bg, int bb) { HDC hDc = CreateCompatibleDC (NULL); HGDIOBJ oldObj = SelectObject (hDc, hBitmap); SIZE size ; LOGFONT logFont; ::ZeroMemory(& logFont, sizeof(LOGFONT)); wcscpy ((&logFont)->lfFaceName, fontName); logFont.lfHeight = sizeToUse; if (bold) logFont.lfWeight = 800; else logFont.lfWeight = 500; logFont.lfItalic = italic; HFONT hFont = CreateFontIndirect(& logFont); HFONT oldFont = (HFONT) SelectObject (hDc, hFont); SetBkMode (hDc, TRANSPARENT) ; BeginPath (hDc) ; TextOut (hDc, 0, 0, fontName, wcslen (fontName)); EndPath (hDc) ; **// MY BRUSH FROM .NET (DOESN'T WORK): HBRUSH oldBrush = (HBRUSH) SelectObject (hDc, hbrush); // FROM EXAMPLE (WORKS): HBRUSH oldBrush = (HBRUSH) SelectObject (hDc, CreateHatchBrush (HS_DIAGCROSS, RGB (255, 0, 0))) ;** SetBkColor (hDc, RGB (br, bg, bb)); SetBkMode (hDc, OPAQUE) ; StrokeAndFillPath (hDc) ; DeleteObject (SelectObject (hDc, oldFont)); SelectObject (hDc, oldBrush); DeleteObject (hDc); } Also, it seems like the background color here is the second color of the hatch pattern. But how do I set the color between the letters (which is also called the "background color"?) Thanks! Alan "Microsoft -- Adding unnecessary complexity to your work since 1987!"

Solved my own problem! The "return 0" in the callback function was terminating the enumeration the first time through! My fault... "Microsoft -- Adding unnecessary complexity to your work since 1987!"

You're welcome. I'm just sorry I couldn't be of more assistance. *pre-emptive celebratory nipple tassle jiggle* - Sean Ewington "Mind bleach! Send me mind bleach!" - Nagy Vilmos My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility

Agreed about the examples though I finally found out how they are created and feel more for the creators and the process than the examples. Anyone that works in Microsoft Consulting is expected to "remain up to date on most current technology". Of course, the only way to demonstrate that is to write samples of the code. So they are required to be the ones to create the examples, usually at night, after 8-10 hours of coding for a client, when they should be spending time with their families.

:thumbsup: Unrequited desire is character building. OriginalGriff I'm sitting here giving you a standing ovation - Len Goodman

http://www.aurigma.com/MyAurigma/Case-8002.aspx[^]

Noted.

Same here. I reported this here in Site Bugs/Suggestions a while ago (several months ago), but it seems like nothing was done about that yet. "I love deadlines. I like the whooshing sound they make as they fly by." (DNA)

Great suggestions! Thanks! (I especially like #1; multiple threads could hit this at once.)

The cause of the problem is that apparently Win32 bitmap handles become STALE, i.e. they're for temporary use only. This led to the problem showing up in different places, depending on when Windoze decided to make the handles invalid. The solution was to pass bitmaps into the lower-level C# functions, then obtain the handles at the last possible moment, inside a loop, just before descending into Win32. These handles were fresh for each iteration, and worked perfectly. I think the Win32 system should provide a less-misleading error message when a stale handle has been used. &*($! Microsoft!

Great :thumbsup:, glad i could help, thanks for the points. :) > The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <

Not sure about the error Members of what ? Try this: public int number { get; set; } or I was looking at SOAP (never played with), but maybe with the extension of the attribute for soap envelop may work. http://msdn.microsoft.com/en-us/library/system.xml.serialization.soapignoreattribute.aspx[^] Good luck :)

Maybe following design could help: Create a new class by extending your previous class, i.e. public class MyNewClass : MyOldClass Then add a Version property to the (new) class. For deserialization, get that property with XmlNode versionNode = xmlDoc.SelectSingleNode("/MyNewClass/Version"); If versionNode is null, call the deserialization method of MyOldClass, otherwise use the deserialization method of MyNewClass. With the version property, you will then be able to extend further easily.

No problem. Glad you managed to solve it. :) Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that. [The QA section does it automatically now, I hope we soon get it on regular forums as well]

That solution works for me, I really appreciate you post that link. Diffy