Traditional C style gui making vs subclassing

[kcvinu]

Hi all,

We can make guis with GUICreate function.  As well as, we can create guis in traditional C style with _WinAPI_CreateWindowEx function. Well, in the second case, we have the power and freedom to deal with WndProc function and thus we can do a lot more than the ordinary GUICreate function. But We can do the same things in ordinary GUICreate function with the help of  _WinAPI_SetWindowSubclass function and _WinAPI_RemoveWindowSubclass function. But i think we can't do anything in the WM_CREATE, WM_PAINT messages. (Please correct me if i am wrong).

So my question is; 

Which method is better ?

ordinary GUICreate function with subclassing OR _WinAPI_CreateWindowEx with original WndProc ?

Why i am asking this because, i need more control over my guis with maximum safety without performance loss.

 

Edited June 19, 2016 by kcvinu

[LarsJ]

If you create the parent GUI with _WinAPI_CreateWindowEx you can't use any of the native GUICtrlCreate-functions and you can't use any of the native functions that uses a controlID as parameter. In that way you have ruled out a substantial part of the native functions related to GUI creation and maintenance. This means that you have to create and update the controls with the functions in the GUI UDFs.

When you create controls with the functions in the GUI UDFs a true window handle is returned (not a controlID). You are going to use the control handle to update the controls.

Many functions in the GUI UDFs are divided into two parts. Often a short and fast part in case that the control handle turns out to be a native controlID, and a longer and slower part in case it's a true window handle. Because all your control handles are true window handles, you'll always be executing the longer and slower part of the UDF function.

Your requirement of no performance loss will not hold.

The development process will take significantly longer time. As a test, try to create a window with _WinAPI_CreateWindowEx and add a group control, a label and an updown control.

You are able to catch WM_PAINT messages by subclassing the controls.

It's not easy to catch WM_CREATE messages. But most code that can be executed in response to a WM_CREATE message can also be executed immediately after the control is created and before it's visible in the GUI. Why is it so crucial to execute the code in response to a WM_CREATE message?

The best method is definitely to use GUICreate and then use subclassing in cases where it's necessary. In that way you get all the benefits of the native GUI-functions, and because of the controlIDs you get faster code when you use the functions in the GUI UDFs.

[kcvinu]

@LarsJ ,

Thanks for your detailed reply. This reply enlightened me very well. I asked this question because, i am planning to make a different IDE for autoit which can help user to make powerull C style guis. That's why i am practising all messages from WM_CREATE to WM_QUIT. All the existing IDEs are using ordinary gui creation funcions. 

Anyway, according to you, using subclassing is the best bet for me.  Now, i need to practice all types of mesages with subclassing. Thanks again. You gave such a brilliant guidance.