How does a Windows non-native user interface work?

Through experience I have found that the native windows forms/components don’t like to be changed. I know using Delphi or Visual Studio you are given native windows components to populate a form or window with and then you attach code on events that these components may do (onClick for example).

However, how do all of these programs like Word or google’s Chrome browser alter the st开发者_JS百科andard windows’ window? I thought it was somehow protected?

Chrome seems to have tabs actually on the window’s frame?

I know you can also get toolkits like Swing and QT that have their own controls/components to populate a form. How do these work? (How does the operating system/computer know what a non-native button should act like? For example; Chrome's back and forward buttons, they're not native components?).

I can understand how OpenGL/DirectX window would work because you’re telling the computer exactly what to draw with polygons/quads.

I hope this question is clear!

Windows does not protect GUI elements. Windows and controls can be subclassed to handle various drawing operations in a custom way. For example, windows may override and reimplement the handling of the WM_NCPAINT message to draw a custom titlebar and frame:

http://msdn.microsoft.com/en-us/library/dd145212(VS.85).aspx

Some Windows controls have an "owner-draw" mode. If you use this, you get to draw the control (or at least vital parts of the control), while Windows takes care of responding to user input in the standard way.

Swing ant QT draw their own widgets at a low level using basic primitives, but they also have theme engines which can mimic the native controls.

Qt moved to native controls a while back. As for how swing does it, it gets a basic window from the OS. Then much like Opengl\Directx it does all of the drawing with in that window. As for where to position things that is what the layout managers do. Each manager has a layout style horizontal, vertical, grid, components it has to draw and a section of window it is expected to fill. From there it does some pretty easy math to allocate its space to its controls.

There's no magic: non native controls are simply drawn on a blank window. Or, instead of being drawn they may be represented as one of several bitmaps based on state (ie: a button may be represented as a .png for the normal state, another .png for the pressed state, etc)