I cannot get the point. How can I generate a window wich is NOT predefined ? Therefor: wich ARE the predefined windows ?
I think the answers are somewhere around me - I'd like a simplification.?Thanx
Posted on 2002-01-02 14:17:03 by oladin
How can I generate a window wich is NOT predefined ?


You can't.

Therefor: wich ARE the predefined windows ?


Windows are generated from window classes. These classes have to be registered (RegisterClassEx) before they can be used. There are some predefined classes like BUTTON, EDIT, LISTBOX and more. Look at Iczelion's tutorials, he shows you how to create these controls.

For the main window you have to register your own window class with RegisterClassEx, and then use CreateWindowEx (CreateWindow is obsolete) to actually create it.
Again, look at Iczelion's tutorials, this is described there as well.

Thomas
Posted on 2002-01-02 16:06:44 by Thomas
Thomas wrote:

[...] then use CreateWindowEx (CreateWindow is obsolete) [...]


Can you provide evidence which supports your claim? Because I've found nothing
to suggest that CreateWindow() is obsolete.
Posted on 2002-01-02 19:59:12 by Boggy
Well, obsolete isn't exactly correct. However CreateWindowEx does everything that CreateWindow does, plus more stuff:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/windows_33jr.asp

The CreateWindow function creates an overlapped, pop-up, or child window. It specifies the window class, window title, window style, and (optionally) the initial position and size of the window. The function also specifies the window's parent or owner, if any, and the window's menu.

To use extended window styles in addition to the styles supported by CreateWindow, use the CreateWindowEx function.

:)
Posted on 2002-01-02 20:36:15 by S/390
S/390 wrote:
Well, obsolete isn't exactly correct.


Right, that was the implication of my question :)



However CreateWindowEx does everything that CreateWindow does, plus more stuff:



In fact on my build environment CreateWindow is just a macro calling CreateWindowEx with a 0 for the extended style.



To use extended window styles in addition to the styles supported by CreateWindow, use the CreateWindowEx function.
:)


And from this we can infer that to use only the styles supported by the CreateWindow it would be more appropriate to use the CreateWindow function.

My question still stands.
Posted on 2002-01-02 21:43:59 by Boggy
I checked the export table of USER32.LIB (VC6). There are two entries for CreateWindowEx, and no entries for CreateWindow.

I also checked the export table of USER32.DLL (Win2000). The same story.

In C/C++, you can use CreateWindow because a macro is defined for it. In ASM, you need to define your own macro or subroutine.
Posted on 2002-01-03 13:12:04 by tank
Sorry, I got it wrong. :rolleyes: CreateWindow isn't obsolete, but still I don't see many programs these days that use CreateWindow instead of CreateWindowEx.
I just added the comment because most of the time you will use the -ex version, most controls need an extended windows style to give them the right look (like WS_EX_CLIENTEDGE).
Sorry for the confusion...

Thomas
Posted on 2002-01-03 16:30:05 by Thomas
In Win32, CreateWindow is very much obsolete, as there is no DLL entry for it. Also, the standard libraries don't have an entry for it.
Posted on 2002-01-03 20:18:23 by tank
tank wrote:
In Win32, CreateWindow is very much obsolete, as there is no DLL entry for
it. Also, the standard libraries don't have an entry for it.



Wrong. Microsoft defines the API and they decide when a function becomes
obsolete. The Microsoft Win32 Platform SDK is the normative source; it
defines the technologies and API's supported by Microsoft implementations.
CreateWindow is not obsolete, it still has a purpose, and still very much used
and supported.


In C/C++, you can use CreateWindow because a macro is defined for it.


Wrong. You can use CreateWindow because it is is apart of the Win32 API. Any
implementation--C, C++, Delphi, ASM, COBOL, QBasic or whatever--that
fully supports the Win32 API must obviously include a CreateWindow
function - whether it gets thunked or preprocessed down to a CreateWindowEx
call is irrelevant.


In ASM, you need to define your own macro or subroutine.


Wrong. In the package you are using that may be what you have to do. Doesn't
that tell you something about it's completness?

obsolete adj. no longer used, antiquated.

regards,
Boggy
Posted on 2002-01-03 22:17:19 by Boggy
Boggy, yours point is, you are right, but still.................who really cares
Posted on 2002-01-03 22:30:08 by huh
Can you feel the love? :grin:

Kid Rock (Wasting Time) - "...I'm not born again, but if I was I'd ask to come back with a little more love."
Posted on 2002-01-03 22:48:54 by bitRAKE

Boggy, yours point is, you are right, but still.................who really cares


I care. This is a technical forum; pedantics and correctness matter. If you make a statement (as tank did) and you are wrong (as he was) someone that knows this should say so. Just as I would expect someone to correct me if I'm wrong. We learn and grow by sharing and making mistakes, there's no love lost.

If you don't care about these things then maybe you should try browsing some of the other forums where these things are irrelevant. Try here:
http://directory.google.com/Top/Kids_and_Teens/Computers/Chats_and_Forums/Teens/

Kind Regards,
Boggy
Posted on 2002-01-03 23:56:58 by Boggy
Originally posted by Boggy

If you don't care about these things then maybe you should try browsing some of the other forums where these things are irrelevant. Try here:
http://directory.google.com/Top/Kids_and_Teens/Computers/Chats_and_Forums/Teens/


I'm sorry but I must point out that you are WRONG.

Last time I checked Teen Chat Network, it was still very much easy to use and didn't require downloading of software -- not to mention a great site for some teen chats.

I'm sorry to have to say that you are WRONG about you GROSS generalization... but teen chat has and always be very much relevant.

-SLIVER (damn that caps key)


:)
Posted on 2002-01-04 04:19:31 by Sliver
1-0 for Silver :)





(i'm joking)
Posted on 2002-01-04 08:15:07 by Bit7
This thread is getting really hot...
I think is it possible to express opinions more "quietly", isn't it ? ;)

Boggy is right about that MS PSDK is the "normative source".
But I also agree with Thomas, S/390 and some others's point too.

In the facts and according to what was, said all the programs uses CreateWindowEx because compilers uses macros, or API wraps to another one, ie.

A similar example could be ZeroMemory...
ZeroMemory is the official name of this MS API, but in fact its "physical name" is RtlZeroMemory.
It's always good to know things like that because the current include files defines ZeroMemory as RtlZeroMemory... (the masm .inc were created by a automated utility that parses the .lib files).

If you try to call ZeroMemory in MASM, with the "original" inc, an error will occur because the api is not defined.

Some can say that is the inc files that doesn't comply to MS standards... and they're right, but imho it is always good to know what happens behind the normalization too, and assembly programmers go usually further than what a compiler accepts, or not.
Posted on 2002-01-04 09:22:08 by JCP