Windows, Dialogs, Modal and modeless goods and bads

[MichaelW]

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.

[zemtex]

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.

[Gunner]

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

[zemtex]

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

[dedndave]

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...

Code Select Expand

;*********************************************************
;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

[dedndave]

even this is probably smaller than the local WNDCLASSEX - push/pop

Code Select Expand

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

[hutch--]

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.

[zemtex]

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?

[Gunner]

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:

Code Select Expand


    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

[zemtex]

Thanks Gunner  :U

[Gunner]

That doesn't remove the system menu, you can right click the titlebar to access the system menu

[zemtex]

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.