I am a little upset that edit control always select the entire text body in it. The code goes like this:

SetWindowText(hwndEdit, TEXTBUFFER);
SendMessage(hwndEdit, EM_SETSEL, -1, 0); <-- suppose to clear the selection but it doesn't work.

Can someone help me out with this problem? Thanks!

Lately I am hacking this well known new game that just came out,
I wrote a small application to help me looking into its internals. Oh boy, it's gonna be hacked death just like all the previous games from the same company. Their developers just don't seem to learn at all.

Edit: I have looked for answers on internet and in books and to no avail to this seemling simple problem...

Thanks for the edit stating you have searched. Silver suggests I only have "a few stern warnings left" because I'm getting old, but he's wrong on the first point. I have lots left, even if I'm old.

Regards,

homersux, that should work. Can you use a window spy to make sure the edit control is receiving the message? Perhaps it's doing a parent handoff or reflection...

Oh and JMI,

JMI, aye, I am trying to avoid being stomped upon by the bat.

Silver, the window handle is correct. Notice that the first line puts text into the edit control, and it does. When the edit window is up, the text are all selected by default (the behavior I am trying to get rid of). If i click inside the text edit control, the selection disappears.

Oh, BTW, I kinda moved on to OpenGL hacking, it's kinda easier with all the available hook points unlike d3d where I must obtain the device ptr somehow and then figure out the location of the beginScene call. With OpenGL, I can do a lot with glBegin and glEnable.

homer, it's not that the handle isn't correct, I'm wondering if the control is doing command reflection to the parent (in which case it will never see the message). This link is MFC 4 so about, ooh, 64 years old, but should explain what I mean:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmfc98/html/_mfcnotes_tn062.asp

And opengl - bah, that's for kiddies Good luck with it though, I'd be interested to read any writeup you do...

Hey, I like OpenGL (DX is ok too though) BUT I have one rant:

Just why did M$ implement DirectX as COM interfaces?
There really was no point to it. Number 1, the whole creating-a-device is hidden behind the Direct3DCreate* function, and then also any other device creations are done from that returned device pointer. So in essence, it simply becomes a series of function calls anyway (just like OpenGL). Plus Number 2, they finally started putting in things that OpenGL had already, like matrix stacks.

Who's gonna instantiate a DX device or the network (another common use for COM objects)

I just really see no point in the DX interface thing, don't know why they ever did it that way other than to demonstrate / use somehow their own technology.

-nt20

with COM it is object oriented (handles are oldschool ) and it is not bound to c++

"SendMessage(hwndEdit, EM_SETSEL, -1, 0); <-- suppose to clear the selection but it doesn't work."

No it shouldn't clear selection - it's in oposite to select all text.
Try SendMessage(hwndEdit, EM_SETSEL, 0, 0)
or any other with both last args the same.

The Svin, I have tried numerous combinations of the last 2 arguments. None of them get the job done. Any one of you interested in writing a demo program to get it to work? hehehe. It'll take about 2 minutes at most maybe?

On opengl and d3d, I do notice a slightly worse performance of opengl on my ati 9600 card compared with d3d. My cpu is kinda slow, 1.0G oced to 1.33GHz. I always thought opengl was faster...

while I am studying the window proc of this program, in the d3d window proc, I found this portion of code:

.text:005852E1 test esi, esi
.text:005852E3 jz short loc_585304
.text:005852E5 mov esi, [esi+0EFCh] ; esi = [esi+0efc] = [hwnd+0efc]
.text:005852EB test esi, esi
.text:005852ED jz short loc_585304
.text:005852EF mov edx, [ebp+wParam]
.text:005852F2 mov ecx, [ebp+hWnd]
.text:005852F5 push edi
.text:005852F6 push edx
.text:005852F7 mov edx, ebx
.text:005852F9 call esi ; hwnd+0EFC => a windows message handler
.text:005852FB pop edi
.text:005852FC pop esi
.text:005852FD pop ebx
.text:005852FE mov esp, ebp
.text:00585300 pop ebp
.text:00585301 retn 10h

Apparently it uses the undocumented HWND data structure to handle window messages. While looking for HWND data structure information, I found this website http://www.winterdom.com/dev/ui/wnd.html. However it is still not complete and does not tell me what's going on in this code segment. Any thought on this usage of HWND data structure? BTW, this esi is not the default window proc.

Well, about the first point, it must not be that effectively object oriented, because every game engine still has to write a ton of wrappers around it. If you're gonna have to write wrappers anyway, then what's the point ? Seriously, if you go thru HeNe's OpenGL tutorials, OpenGL is pretty easy, even if it does use Handles. The way DX works, even though it's OO, it still seems like Handles anyway, because you are just passing object instances around (object addresses). That's pretty much what a Handle is !

Yeah, that second point is a good one I suppose Although a DLL is still a DLL ! COM might have been a binary standard, but you still need to ask the system to load the COM object for you, etc. Which means down at some low level you still have to have some C interface for your language (for example, python or VB). And you can still use DLL's from python or VB anyway (for example, to use OpenGL).

I don't have anything against DX, I think it has a lot of benefits, but I just don't know a real good argument for using COM to implement it.


-nt20

Silver, what is 'GxWindowClassD3D' for d3d window? This looks like a window proc handler. I got it through 'hwnd process' in softice, it reports IME and D3D window proc addresses. Part of the GxWindowClassD3D code:

0b6d6402 55 push ebp
0b6d6403 8BEC mov ebp,esp
0b6d6405 A18C09830B mov eax,[0xB83098C]
0b6d640a 56 push esi
0b6d640b 8B7508 mov esi,[ebp+0x8]
0b6d640e 3BC6 cmp eax,esi
0b6d6410 0F85B8030000 jnz 0x0B6D67CE
0b6d6416 813D8809830B95429542 cmp dword ptr [0xB830988],0x42954295
0b6d6420 0F85A8030000 jnz 0x0B6D67CE
0b6d6426 8B0D9409830B mov ecx,[0xB830994]
0b6d642c F6C140 test cl,0x40
0b6d642f 7407 je short 0x0B6D6438
0b6d6431 33C0 xor eax,eax
0b6d6433 5E pop esi
0b6d6434 5D pop ebp
0b6d6435 C21000 retn 0x10
0b6d6438 A19009830B mov eax,[0xB830990]
0b6d643d 53 push ebx
0b6d643e 8B5D0C mov ebx,[ebp+0xC]
0b6d6441 81FB82000000 cmp ebx,0x82
0b6d6447 894508 mov [ebp+0x8],eax
0b6d644a 7509 jnz short 0x0B6D6455
0b6d644c 83C910 or ecx,0x10
0b6d644f 890D9409830B mov [0xB830994],ecx
0b6d6455 F6C110 test cl,0x10
0b6d6458 57 push edi
0b6d6459 745C je short 0x0B6D64B7
0b6d645b F6C108 test cl,0x8
0b6d645e 7426 je short 0x0B6D6486
0b6d6460 33C9 xor ecx,ecx
0b6d6462 890D8809830B mov [0xB830988],ecx
0b6d6468 890D8C09830B mov [0xB83098C],ecx
0b6d646e 890D9009830B mov [0xB830990],ecx
0b6d6474 890D9409830B mov [0xB830994],ecx
0b6d647a 890D9809830B mov [0xB830998],ecx
0b6d6480 890D9C09830B mov [0xB83099C],ecx
0b6d6486 6842420000 push 0x4242
0b6d648b 56 push esi
0b6d648c FF1524126A0B call [0xB6A1224]
0b6d6492 8B7D08 mov edi,[ebp+0x8]
0b6d6495 57 push edi
0b6d6496 6AFC push -0x4
0b6d6498 56 push esi
0b6d6499 FF1528126A0B call [0xB6A1228]
...
I am trying to find WM_KEY (0x102) in those code but I couldn't.

Edit: Yet another sidious problem from this application. When I set a breakpoint in ollydbg and tigger it inside the application, I cannot switch to ollydbg through 'alt-tab'. I can bring out the task manager which says application is not responding and can't switch to olly. I need a damn way to get back to a debugger and figure out the keyboard handler part! I am so damn close to figure it out through IDA analysis. BTW, the thing will just boot the computer if I use sice and trigger the breakpoint. It seems it does some funky D3D stuff.

I've never heard of that, but I'm fairly convinced of something now. Yesterday I wrote a huge reply to this, then firefox crashed and I lost it so never bothered re-writing.

I believe that your D3D app is using the Microsoft Common Files Framework, which is basically a win32 wrapper system for DirectX (kind of like MFC or WTL but DX specific). If you have the SDK installed, you can look at the code to any of the samples - you'll see it's all object oriented and class based, as opposed to the code I've posted previously which is normal "C style" win32 window handling. This doesn't help you much, but I always recommend people NOT to use the common framework, it's confusing and makes things much harder. Unfortunately the DirectX Appwizard that comes with the SDK (before 9.0c) creates common framework apps, so lots of people use it.

nikola, I also wrote a long reply to:

In brief, games have wrappers because it's developer and economically sensible to do so. With a wrapper, you only have to port your engine to port the game to PS2, XBox etc. When games houses code games, they normally have 2 teams - the engine team and the gameplay team. The engine team code the wrappers using the DirectX building blocks (for example, texture managers etc). The gameplay team use those wrappers to create the actual game content. This is a big thing for tools coding - every modern game uses its own tool set. By coding an engine wrapper, the tools can use the same codebase that the game does. That means the game designers can build levels, objects etc knowing that if it works in the tool, it'll work in the game.

Exactly Then really, the choice of underlying API is only for functionality, not implementation. (DX has DirectSound and DirectPlay, so it has much more functionality - oh, and pixel and vertex shaders too ).

-nt20