Hey guys.

I have created a Proc that I use to subclass my edit controls on my dialog. Everything works great with it, only thing that I am trying to find out is - when the Proc takes over control, is there an initial message sent to the new Proc stating this? I want to do some initialization for the controls here. I want to add a text limit to the controls in this proc instead of getting the handle to each and every edit control in the WM_INITDIALOG and setting them there.

here is the proc

EditSubProc proc hWin:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM

mov eax, uMsg
.if eax==WM_LBUTTONDOWN
invoke CallWindowProc,OldEditWndProc,hWin,
uMsg,wParam,lParam
invoke SendMessage,hWin,EM_SETSEL,0,-1
ret

.endif
invoke CallWindowProc,OldEditWndProc,hWin,
uMsg,wParam,lParam

ret


EditSubProc endp


I was wondering after you use the SetWindowLong API function to re-associate this new Message Proc with the controls does the new Proc get a message stating this?

ie. like this,
WM_NEWPROCTAKINGOVER
....do some initialization here

I looked through all the docs I got and can't see anything, but maybe one of you guys worked with something like this before

thanx
Posted on 2002-01-04 19:46:08 by Rockinronstar
How about defining your own message and sending the message to the new window procedure after you've subclassed the control?

I assume it would roughly look something like this:

WM_NEWPROCTAKINGOVER equ WM_USER

subclass, newproc
sendmessage, newproc, WM_NEWPROCTAKINGOVER

I've never tried this before so post your results if you give it a go.

Check out Application-Defined Messages at MSDN

Good Luck.
Posted on 2002-01-04 22:02:50 by Boggy
Just another thought: is the subclass necessary? In my opinion you should be subclassing if you have no other means to modify a windows behaviour.

How about having an array of window handles and processing them in a loop:

if message == WM_INITDIALOG

for (i = 0; i < TEXT_CONTROLS; i++)
hwnd_array = createwindow, "edit", ....

And you can just process the EN_SETFOCUS in your dialog proc:

.if (message == WM_COMMAND && wParam == EN_SETFOCUS)

sendmessage, hwnd_array, EM_SETSEL, 0, -1

Dunno, just a thought :)
Posted on 2002-01-04 22:17:50 by Boggy
custom message actually slipped my noggin, haha. I think they may work.

Regarding the edit controls, I ran into this problem a few times before. Catching the setfocus works great if its the first click in the control, but if the control has focus and you click down on it I want it to highlight its contents.

The reason the subclass is necessary is that the edit box handles its own LButton down message so the default message handling needs to be done first before you implement your own LButtonDown handler.

So you need to route all the message to the edit box first and then check the button down message(and do whatever you want then).

I think I may do the User message(well not user message, thats pretty much obselete in Win coding now, best to Register a message ID with Windows and use it that way). I have done quite a bit of this in my MFC apps. Should be easy to port to ASM

thanx alot for the suggestions;)
Posted on 2002-01-04 22:51:15 by Rockinronstar
Did someone just say obsolete? :)
Posted on 2002-01-04 23:06:22 by Boggy
I think he is just taunting you. :tongue:
Posted on 2002-01-04 23:16:59 by bitRAKE
actually forgive me. Been doing MFC way tooo long. Still have the bad habit of listening to what Microsoft considers proper programming style.
The only reason they consider WM_USER not good anymore is due to the possibility of overriding a built in Windows Message. I kinda can see their point there. They release a new operating system that adds new message ID's and your older code happens to use that same ID, or even your ID is the same as another programs ID, I guess some problems could arise there.

They want you to use the Register Message API with a GUID to eliminate this from happening.

Obselete was definately the bad word to use, more like , Bill don't like it anymore, haha
Posted on 2002-01-04 23:33:27 by Rockinronstar