CreateWindow vs CreateWindowEX

[Chris Boss]

Are there any reasons why one should use CreateWindow rather than CreateWindowEX ?

Does CreateWindowEX support all the Window Styles for Dialogs ?
(They all start with %DS_ )

Some of the Dialog styles (start with %DS_) seem to be the same as some Extended styles. Is this so you can use them with CreateWindow since it doesn't support extended styles ?

Also, I want to emulate all that a Dialogbox can do, but by using CreateWindowEX (rather than any of the DialogBox functions in the API). Besides IsDialogMessage (which I already use) , are there any other API functions that are useful in emulating the Dialogbox features (setting the focus, tabbing, etc.) ?

While, I can do all that I want using CreateDialogIndirect (which I use now), I find that using the Windows DialogBox engine may also create problems since I am handing over too much control to Windows. There are some things that I might try to do, but it is possible that the Dialogbox engine may try to override some things I attempt to do (may not like Dynamically created controls after the Dialog is already created).

[Florent Heyworth]

Hi Chris

to my mind the primary advantage of using CreateWindowEx over CreateWindow is the ability to use the WNDCLASSEX. I use it as it enables me to specify a separate icon for the minimized state (I don't always want it to be the same). Here are the members of WNDCLASSEX:

typedef struct _WNDCLASSEX {    // wc  
    UINT    cbSize; 
    UINT    style; 
    WNDPROC lpfnWndProc; 
    int     cbClsExtra; 
    int     cbWndExtra; 
    HANDLE  hInstance; 
    HICON   hIcon; 
    HCURSOR hCursor; 
    HBRUSH  hbrBackground; 
    LPCTSTR lpszMenuName; 
    LPCTSTR lpszClassName; 
    HICON   hIconSm; 
} WNDCLASSEX;

Cheers

Florent

[Dominic Mitchell]

For fine control over focus changes the following functions can be used
with any window with child controls.
GetNextDlgTabItem
GetNextDlgGroupItem

Since you have decided to go the emulation route, you will have to do
something about the lack of control over the z-order of controls exhibited
by your Ezedemo.
1. Controls should retain their position in the z-order when they are
destroyed and recreated during a property change.
2. The programmer should be able to change the z-order of controls on the fly.
3. A group box should be treated as a decoration and should not obscure other
controls even if it is the last one drawn(the VisualBasic approach is a bad
solution in my opinion).

Given the following controls on a form(numbers indicate the order of creation)

          child1 child2 child3 child6
                   |
              child4 child5

the z-order table for the child windows is pretty interesting...

Oops went off on a tangent. Any style that is used with CreateWindow can be used
with CreateWindowEx. The only difference between the two functions is that CreateWindowEx
allows the use of extended styles.

Some of the Dialog styles (start with %DS_) seem to be the same as some Extended styles.

Hmm...which styles are you referring to? Some of the DS_xxx have the same numeric values
as some of the WS_EX_xxx but we are mixing apples and oranges here.
Some styles that produce similar effects are
DS_SYSMODAL WS_EX_TOPMOST
DS_MODALFRAME WS_EX_DLGMODALFRAME

Regards,
Dominic

[This message has been edited by Dominic Mitchell (edited January 23, 2000).]

[Chris Boss]

Dominic;

You brought up ZOrder (or Tab Order since they are one in the same unless some engine handles its own Tab Order).

You will notice that EZGUI (and the EZDEMO) Visual Designer, allows you to click on a control and bring it forward (always). While, editing the Dialog the controls ZOrder is NOT forced. The controls work just like regular windows , in that which ever one is clicked, it gets moved forward.

This is "by design" !

EZGUIs Visual designer has a Toolbar Button, that can be clicked that will "Reset" the ZOrder to the defined ZOrder and also when you select Test mode, the controls are all brought back to the correct ZOrder.

The reason for this is twofold:

(1) It allows getting at a control, that would otherwise be impossible to bring forward to move and resize it (select it from the combobox and it is brought forward , but not permanently. This allows bring controls forward, while working on the Dialog while not affects its permanent ZOrder (as defined when code is generated)

(2) EZGUI has Visual Design capabilities built in to it (which the Visual Designer uses), but it only takes about 4 Kb code to impliment (keeps the size down). I wasn't about to add a "huge" Visual Designer engine to EZGUI, so there are some give and takes. While some may find the techinque used a bit unusual, you do get used to it after awhile. While, not as powerful as the VB editor, it does have a few advantages (like Layers).

Thats about I'll discuss about this subject in this Forum (better suited to Third Party).


My main concerns about whether to use Create WindowEx, is because of concerns with Win 2000. I was using an "unorthidox" technique with the Dialogs Engine in Windows (Use CreateDialogIndirectlParam to create a blank Dialog, and then in the WM_InitDialog message Dynamically resizing the Dialog and dynamically creating the controls).

While it worked "perfectly" on Win95/98 there were some problems in Win 2000 (not sure if they are related to my use of Dialogs or not. I won't know until I get feedback from Beta testers)

Lets just say that I am just trying to "cover all the bases" in making my programs work on all platforms.

[Chris Boss]

Oh I forgot one other thing:

One other reason I am trying to use CreateWindowEx, instead of the Dialog engine (I had to make big chnages in EZGUI to do this), is so I can see if I can add WinLift support in version 2.0.

Patrices WinLift works "Great", but it is NOT compatible with the Dialog engine in windows. Rather, than make Patrice find a solution to work with Dialogs, I have chosen to make EZGUi work the way WinLift expects.

While, I can't guarantee WinLift support, yet, I think it is worth the effort to try to do it.

[Dominic Mitchell]

I keep forgetting that you are trying to keep it small.
Adding controls during a WM_INITDIALOG, hmm..., have to think
about that one. Since you are using DLGTEMPLATES in memory
why not just use DLGITEMTEMPLATES to add controls dynamically?

[Steve Hutchesson]

The EXPORTS for USER32.DLL tell the story to Chris's original question,
000051CF 53 84 CreateWindowExA
0000106E 54 85 CreateWindowExW
There is NO API function in the DLL called CreateWindow any longer, that
is why the PB include file defines it in terms of a wrapper function.

The two versions in USER32.DLL are alternatively ANSI & UNICODE versions.

There is every good reason to use CreateWindowEx by itself, it is the actual
function in the system DLL.

[email protected]