QuoteCreateWindowEx (https://msdn.microsoft.com/en-us/library/windows/desktop/ms632680(v=vs.85).aspx), lpClassName: A null-terminated string or a class atom created by a previous call to the RegisterClass or RegisterClassEx function. The atom must be in the low-order word of lpClassName; the high-order word must be zero.
So what do you get with this, assuming 49182 is the atom for "edit"?
invoke CreateWindowEx, 0,
49182, 0, (WS_VISIBLE or WS_CHILD or ES_MULTILINE), 0, 0, 100, 100, hWnd, ID_EDIT, hInstance, NULL
The answer is: something that looks like an edit control. Test it on one of your "simple window" templates 8)
Attached a list of atoms found on Win7-64.
It produces a window in win10 64 but will not accept text.
invoke CreateWindowEx, 0, 49182, 0, \
WS_VISIBLE or WS_CHILD or ES_MULTILINE, \
0, 0, 1000, 600, hWin, 1234, hInstance, NULL
mov hed, rax
invoke SetWindowText,hed,"How Dee"
Exactly. Looks like a duck, walks like a duck, smells like a duck, but cannot say quak :(
Here is a Rude HWND:
include \masm32\include\masm32rt.inc
.code
start:
invoke SendMessage, HWND_BROADCAST, WM_SETTEXT, 0, chr$("Hello World, how are you?")
exit
end start
Builds fine, but PLEASE don't run it. You have been warned 8)
I confess to being biased, in the Win 3.0 days atoms looked like old sh*t and I never used them.
There are 2 (or 3 if you include the non-global atom functions) different atom tables, GlobalGetAtom and friends use the kernel based one whereas the window classes are registered in the user/win32k based atom table, alongside clipboard format names, registered window messages and hook dlls.
You can't search the User atom table with a string, GetClipboardFormatName in a loop from 0xc001 to 0xffff is the only way to query its entries (despite its name, it returns the names of all the mentioned things). If you find 'Edit' in there and use that atom, it'll probably work.
Interesting - and it works :t
49175 Button
49176 Edit
49177 Static
49178 ListBox
49179 ScrollBar
49180 ComboBox
49181 MDIClient