This UI in particular is possible, because you don't have text-over-image or text-over-gradients.

I'm not sure what you mean here, both are pretty simple.

What I mean is that functions like TextOut and DrawText seem to be drawing solid color background. I might have missed something, but the last time I tried, I couldn't figure out how to draw text on an image without that solid color background. I spent a few hours trying different thing. and I finally ditched DPI. If you have solid background, it is trivially easy to draw text.

This UI in particular is possible, because you don't have text-over-image or text-over-gradients.

I'm not sure what you mean here, both are pretty simple.

What I mean is that functions like TextOut and DrawText seem to be drawing solid color background. I might have missed something, but the last time I tried, I couldn't figure out how to draw text on an image without that solid color background. I spent a few hours trying different thing. and I finally ditched DPI. If you have solid background, it is trivially easy to draw text.

SetBkMode

(Also it's GDI, not DPI )

I asked how to do that. Please provide me some links to tutorials where they are doing modern eye-candy elements with pure WinAPI. I'm seriously interested in it.

In relation to the screenshots the OP posted, all I see is flat shaded rectangles. Where is the eye-candy in the VS2012 UI? Surely any graphics API can produce similar results.

It took me ~2 years to build this IDE on top of my GUI library which is in turn based on the win32 API :

[attachment=17940:ide_temp.png]

[attachment=17939:ide_temp2.png]

Let me know if you like it and/or how I can make it better

I asked how to do that. Please provide me some links to tutorials where they are doing modern eye-candy elements with pure WinAPI. I'm seriously interested in it.

You can do almost any common effect with GDI only. The weakest point is antialiased drawing of shapes, which is not included by default in GDI (but can be done with GDI+ or Cairo, for example).

If you are really feeling the need of doing something that GDI can't handle on its own, there is always the option of rendering directly to the pixels with GetDIBits/SetDIBits, but that's rarely needed.

If you could be a little more specific about what kind of eye-candy you are looking for, maybe I can help.

Sure it's true, but thanks for the downvote anyways.

I downvoted you because your information was incorrect and that is precisely the point of the downvote system. I felt kinda bad because I just thought you'd made an honest mistake.

But if you insist on being wrong, well, for the benefit of others who might mistakenly believe you, prepare for learnings....

Below you can see a simple app written in winforms (which really is win32).

You can see the visual studio project open behind it. Notice that Spy++ shows us that there is a main window, and three subwindows (one each for the label, button and text box)

Here's the same app written in WPF.

Notice how there is only one window.

Once again, WPF does not use win32, other that to create a host window which it fills itself. Everything within that window is handled by WPF.

So please stop talking about stuff you clearly know nothing about.

What are you on about? I never said there was more than one win32 window.

I can render controls directly onto one window also. Does that mean I'm not using Win32?

Once again, WPF does not use win32, other that to create a host window which it fills itself. Everything within that window is handled by WPF.

They're called windowless controls, and used to be shipped with VS. Everything you've shown can be accomplished using Win32. The project I am currently working on is based 100% on windowless controls - the only difference is I choose to use OpenGL as the graphics API rather than GDI for performance reasons.