(http://i.imgur.com/ge6qw.png)
This is just a few basic characteristics of the different methods to create windows. I couldn't find such a list by searching the forum. Thought it might be useful to have just in case someone need a quick reference. Discuss good and bads about the different methods if you wish. It's not always too easy to deside what window type one should go for in terms of size, bloat, speed etc. I did not include the versions to create windows without "Param", because there was not enough room for it.
you can make it preformatted text with "teletype"
but, the user's default size gets used - you may want to force something reasonable, like 10 or 12 pt
or, just use the code tags :bg
i am trying to figure out what "x" and "v" mean :P (xp/vista ?)
a "key" would be handy
I removed the V and X and replaced it with Yes or No.
i think CreateWindowEx can create any type of window
the other functions all end up using it
If anything is wrong now, let me know I will change it :P
Btw, how do you remove the titlebar icon of the window, what style should I use when using CreateWindowEx? I know how to make it work with dialog windows, but not with normal user created windows.
zemtex,
Dave is basically right here, CreateWindowEx() is the method that the OS uses to create a window in the system. There are a couple of techniques that create simplified windows which are basically what dialogs are that pre-package a number of things like keyboard control but the OS uses CreateWindowEx() to provide that capacity.
As far as adding or subtracting things like title bars and the button at the top of the window, you have both the extended styles and normal styles associated with CreateWindowEx() that give you all of these adjustments. You ORR them together in the normal manner to combine styles to give you the one you require.
What is the basis for the "Auto Tab to next control" rating? This would appear to be a message loop issue, not a window creation issue. And what about the "Bloats your code" and "Fast to create" ratings, what are you measuring?
These functions can not bloat your code. There is no way. By the looks of this, you may have been misinformed what "bloat" means.
Quote from: Horton on July 25, 2011, 11:12:09 AM
These functions can not bloat your code. There is no way. By the looks of this, you may have been misinformed what "bloat" means.
If you use embedded dialog resources as opposed to native CreateWindowEx() I believe your exe will be larger??
James
Quote from: jcfuller on July 25, 2011, 03:12:27 PM
Quote from: Horton on July 25, 2011, 11:12:09 AM
These functions can not bloat your code. There is no way. By the looks of this, you may have been misinformed what "bloat" means.
If you use embedded dialog resources as opposed to native CreateWindowEx() I believe your exe will be larger??
James
Yes, in many cases you need to register the window, fill in information about it, some need a message loop which adds more bloat to your program, some of them have system internal message parsers.
Some of the functions need memory templates, you need to initialize quite alot, there is not just the memory template that needs initialization. The functions itself does not bloat your code, but it is the added code needed to make it all work that bloats your program.
Quote from: MichaelW on July 25, 2011, 04:37:32 AM
What is the basis for the "Auto Tab to next control" rating? This would appear to be a message loop issue, not a window creation issue. And what about the "Bloats your code" and "Fast to create" ratings, what are you measuring?
Auto Tab means that the system has internal parsing for TAB between dialog controls. Otherwise you would write your own parser for TAB. It is a message loop issue in CreateWindowEx for example, but it is not in DialogBoxParam where it is handled internally.
Bloats your code is a measure of all the extra code and data needed to make it all work based on which type of window you want to create. It is not just the function to create the window, but what is needed in total, like Register window, wndclassex structure, message loop, keyboard parsing. etc. I would like to mention that it is also the function itself, some of them are larger than others.
Fast to create is how quickly you can code it. :P
All controls created with createwindow can be tabbed to without writing your own handler! Create the control with ws_tab, and in the message loop you add isdialogmessage or something before translate message
Quote from: Gunner on July 25, 2011, 03:58:40 PM
All controls created with createwindow can be tabbed to without writing your own handler! Create the control with ws_tab, and in the message loop you add isdialogmessage or something before translate message
Yes but like you said yourself you have to add it, it's not by default. That is what the "Auto" tab line is measuring. Whether you have it automatically by default or if you have to code it yourself in the message loop or somewhere else.
Why should CreateWindowEx bloats my code? - There is nothing needless on this function - or what did you mean with bloats your code?
Quote from: qWord on July 25, 2011, 04:15:48 PM
Why should CreateWindowEx bloats my code? - There is nothing needless on this function - or what did you mean with bloats your code?
Maybe I didn't make myself well understood. "bloats your code" doesn't necessarily add that much of a bloat, it is just a relative term to all the other methods. It adds somewhat more or less code and data into your executable than the rest of the methods in the list. It doesn't mean it adds exceptional bloat. It is merely a relative term and I used it for its associative value. I could have written "Will produce relatively larger executable".
Quote from: zemtex on July 25, 2011, 04:01:40 PM
Yes but like you said yourself you have to add it, it's not by default. That is what the "Auto" tab line is measuring. Whether you have it automatically by default or if you have to code it yourself in the message loop or somewhere else.
A modeless dialog or an application window must have a message loop - there is no "default". If in the message loop you use the traditional TranslateMessage/DispatchMessage then you don't get dialog-style keyboard navigation. If instead you substitute IsDialogMessage, then you do get dialog-style keyboard navigation.
Quote from: MichaelW on July 25, 2011, 04:37:57 PM
Quote from: zemtex on July 25, 2011, 04:01:40 PM
Yes but like you said yourself you have to add it, it's not by default. That is what the "Auto" tab line is measuring. Whether you have it automatically by default or if you have to code it yourself in the message loop or somewhere else.
A modeless dialog or an application window must have a message loop - there is no "default". If in the message loop you use the traditional TranslateMessage/DispatchMessage then you don't get dialog-style keyboard navigation. If instead you substitute IsDialogMessage, then you do get dialog-style keyboard navigation.
I am not actually sure about how and if you do get "dialog-style keyboard navigation", but with modal dialogs you have automatic internal parsing for TAB between controls. You don't need to add it yourself.
What is the big deal, you add 1 call in your message loop. For dialogs it isn't autmagic either, you have to set tabstop for the control. From my experience, (and others here I believe) dialogs (i will use your term) :bg "bloat" your app since it is all in unicode. Dialogs are fine if you want to get your app created quickly and make it eaiser to edit. I use assembly for control, so I use CreateWindowEx to remove that extra layer of stuff...
Now, technically another reason dialogs add "bloat" and are "slower" beside windows calling createwindow for you, is if you want a control handle, you can't get that when the control is created, you have to make a call to get it (unneeded with createwindow), then there are the SendDlgMessages which call SendMessage anyways..
Eh, I preffer not to use dialogs, plus it's harder for someone to get "nosey" with your app
Gunner: Details are seldom a "big deal". But when you create a list and a list of features, you just have to list up the differences, despite how small they are, thats what the list is for.
Your argument for what is better and what is worse, you are probably right. The list is just to make a quick judgement, based upon what you really need to achieve. Do you need a "quickie" solution, go for modal dialogs, do you need more power, go for CreateWindowEx or modeless dialogs.
If there is something wrong about the features in the list, I can change it. I have to admit the "bloat" was a badly chosen word, I should have used "Will produce relatively larger executable"
Is there anything relevant I can add to the list, do tell and I can add it.
Speaking of "Auto TAB controls", I could have replaced Yes/no with Manual/Automatic so that it is not so confusing.
Discuss what is better or not, thats what the thread is for :lol
i am just getting a "handle" (pun) on RegisterClassEx/CreateWindowEx
i have only played with the dialogs and other controls a little bit
RegisterClassEx and CreateWindowEx together make a very powerful tool
i don't see them as bloat, really
but then, that depends on how you define bloat
i do see many programmers write code in a bloat style - lol
i see a lot of cases where they create a local WNDCLASSEX on the stack, then fill it with push/pop - lol
it looks nice in the source code, but if you look at the disassembly, it's a bit bloat-ish
in a project i am working on, i need to regsiter 2 classes...
;*********************************************************
;register window classes
;*********************************************************
;WNDCLASSEX STRUCT
; cbSize dd ?
; style dd ?
; lpfnWndProc dd ?
; cbClsExtra dd ?
; cbWndExtra dd ?
; hInstance dd ?
; hIcon dd ?
; hCursor dd ?
; hbrBackground dd ?
; lpszMenuName dd ?
; lpszClassName dd ?
; hIconSm dd ?
;EDI = 0
RegTwo: INVOKE CreateSolidBrush,vs.BackColor
mov edx,hIcon
mov ecx,TxtProc
push edx
mov esi,offset TxtClass
call RegOne
mov eax,COLOR_SCROLLBAR+1
pop edx
mov esi,offset WndClass
mov ecx,WndProc
RegOne: push edx ;hIconSm
push esi ;lpszClassName
push edi ;lpszMenuName
push eax ;hbrBackground
push hCursor ;hCursor
push edx ;hIcon
push hInstance ;hInstance
push edi ;cbWndExtra
push edi ;cbClsExtra
push ecx ;lpfnWndProc
push edi ;style
push sizeof WNDCLASSEX ;cbSize
INVOKE RegisterClassEx,esp
add esp,sizeof WNDCLASSEX
ret
52 bytes to register 2 classes :P
even this is probably smaller than the local WNDCLASSEX - push/pop
RgClsEx PROTO :DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD
;-----------------------------------------------------------------------------------------------------------------------
OPTION PROLOGUE:None
OPTION EPILOGUE:None
RgClsEx PROC p1:DWORD,p2:DWORD,p3:DWORD,p4:DWORD,p5:DWORD,p6:DWORD,p7:DWORD,p8:DWORD,p9:DWORD,pA:DWORD,pB:DWORD,pC:DWORD
;p1 = cbSize
;p2 = style
;p3 = lpfnWndProc
;p4 = cbClsExtra
;p5 = cbWndExtra
;p6 = hInstance
;p7 = hIcon
;p8 = hCursor
;p9 = hbrBackground
;pA = lpszMenuName
;pB = lpszClassName
;pC = hIconSm
lea eax,[esp+4]
INVOKE RegisterClassEx,eax
ret 48
RgClsEx ENDP
OPTION PROLOGUE:PrologueDef
OPTION EPILOGUE:EpilogueDef
;-----------------------------------------------------------------------------------------------------------------------
:bg
Dialogs are simply a higher level simplified window that are easier to create but have less control that a Window created with CreateWindowEx(). If you want full manual control, do it with CreateWindowEx(), if you want it quick, easy and in dialog units, then use a dialog, thats what they were designed for. You can do dialogs as either resources or directly in code so you do have a few choices to do what you need.
hutch, yes i'm aware of the indirect use of WindowCreateEx and it has up's and down's which makes it a qualified item in the list.
The question is not so much if it is used indirectly, but whether it happens internally or if you have to code the window "wrapper" yourself.
Btw, while we're talking about windows/dialogs, how do you get rid of the titlebar icon without removing the min,max and close buttons when using WindowCreateEx directly?
I get it to work when using dialogs but not WindowCreateEx, I am trying to translate my resource file to code, what styles should I use to achieve that?
Quote from: zemtex on July 26, 2011, 04:51:12 PM
Btw, while we're talking about windows/dialogs, how do you get rid of the titlebar icon without removing the min,max and close buttons when using WindowCreateEx directly?
I get it to work when using dialogs but not WindowCreateEx, I am trying to translate my resource file to code, what styles should I use to achieve that?
Hmmmm, good question....
Whn you create your window class, set the hIcon and hIconSm to NULL, then in your WM_CREATE handler do this:
invoke GetWindowLong, hWin, GWL_EXSTYLE
or eax, WS_EX_DLGMODALFRAME
invoke SetWindowLong, hWin, GWL_EXSTYLE, eax
invoke SetWindowPos, hWin, 0, 0, 0, 0, 0, SWP_NOSIZE or SWP_NOZORDER or SWP_FRAMECHANGED
:toothy
Thanks Gunner :U
That doesn't remove the system menu, you can right click the titlebar to access the system menu
Quote from: Gunner on July 26, 2011, 05:14:39 PM
That doesn't remove the system menu, you can right click the titlebar to access the system menu
I read some random suggestion to make the icon 100% transparent initially, but there had to be another way. I hate tricks and dirty programming. I can't stand it :toothy Don't get me wrong, tricks are good if you don't have to cheat, but when you use tricks for cheating, something is becoming what it was not meant to be.