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
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
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.
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.
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 :)
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 :)
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;)
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;)
Did someone just say obsolete? :)
I think he is just taunting you. :tongue:
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
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