News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Superclassing problem

Started by Neil, February 06, 2010, 04:02:05 PM

Previous topic - Next topic

Neil

I,ve Changed it to :-  WS_BORDER,20,edi,75,25
Now I've got the edit Boxes but Instead of being side by side they are underneath one another.
I'll check through the parameters to find out what I'm doing wrong.

Neil

Right, changed the parameters to :-  WS_BORDER,edi,20,25,25.
Now I've got the Edit Boxes displaying side by side, Thanks JJ :U
So it seems that the display problem is in EditWndProc, I'll study it & try & pin the problem down, if not I'll post it.

Neil

I've looked at EditWndProc & commented everything out so all that's left in it is xor eax,eax & ret & the edit boxes still don't show but if as JJ suggested I comment out mov wc.lpfnWndProc, OFFSET EditWndProc they do I'm baffled :(

jj2007

Quote from: Neil on February 08, 2010, 03:44:18 PM
I've looked at EditWndProc & commented everything out so all that's left in it is xor eax,eax & ret

Is ret the right way to leave that proc? Have you tried a call to DefWindowProc?

donkey

Quote from: jj2007 on February 08, 2010, 04:19:15 PM
Quote from: Neil on February 08, 2010, 03:44:18 PM
I've looked at EditWndProc & commented everything out so all that's left in it is xor eax,eax & ret

Is ret the right way to leave that proc? Have you tried a call to DefWindowProc?

In Superclassing he should call the old window procedure, although DefWindowProc will do in a pinch, after all you only superclassed to get some functionality from the global class and that it done through its old window procedure. Under no circumstances should he be returning with a simple RET, there are a lot of messages that need to be processed. Returning 0 generally means that the message has been processed (for example WM_NCPAINT), if it was not then you must pass it to Windows for processing.
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

Neil

Here is the complete EditWndProc, this works OK when I subclass 1 Edit Box.

EditWndProc PROC hEdit:DWORD,uMsg:DWORD,wParam:DWORD,lParam:DWORD

        cmp uMsg,WM_CHAR
        jne ERT
        mov eax,wParam
        jmp @F
        cmp al,VK_RETURN
        jne @F
        cmp icount,2
        jne ERT
        invoke DestroyWindow, hEdit
       
ERT:    xor eax,eax
        ret
       
@@:     cmp al,VK_BACK
        jne ERTT
        cmp icount,0
        je ERT
        dec icount
        jmp ERTTT
       
ERTT:   cmp icount,2
        je ERT 
        cmp al,"0"
        jb ERT
        cmp al,"9"
        ja ERT
        cmp icount,0
        jne ER
        cmp al,"4"
        ja ERT

ER:     inc icount
       
ERTTT:  invoke CallWindowProc,OldWndProc,hEdit,uMsg,eax,lParam
        ret

EditWndProc endp

Neil

Discovered that if I comment out everything except invoke CallWindowProc,OldWndProc,hEdit,uMsg,eax,lParam ret 1 edit box is displayed?

jj2007

And what happens if you replace eax with wParam?

Neil

It works!! :U :U
I'm puzzled why

Neil

Unfortunately it only displays the Edit Boxes when everything else is commented out :(
But it still works OK with the subclassed Edit Box.
EDIT There is one difference with the subclassed Edit Box in that it now doesn't get destroyed when ENTER is pressed.

hutch--

Neil,

What you would normally do in production code is to make a procedure that contains the CreateWindowEx() function call to make the control and make a normal subclass to go with the procedure that does what you want with that control. Once this is working correctly you can duplicate the control by just calling the first procedure as many times as you need.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

jj2007

Quote from: Neil on February 08, 2010, 07:35:43 PM
It works!! :U :U
I'm puzzled why

Imagine a sub/superclassing procedure as a kind of break point where Windows allows you to intervene before it continues to do its job. For example, if a WM_CHAR message with a 9 in wParam passes by this break point, Windows gives you a chance to decide whether you want to insert a tab or not. By returning null, you tell Windows "no further processing", and no tab will be inserted. By jumping to the end, CallWindowProc or DefWindowProc will take over and do the default processing.
So if you get a WM_PAINT message and you do NOT call CallWindowProc, nothing will be painted (except you do it yourself by hand...).

Neil

This is certainly a steep learning curve, thanks for all the info, I'm now going to 'sleep' on it & start afresh tomorrow.

Neil

Happy to report I've cracked it. After studying Iczelion's Tutorial Number 22 I could see where I was going wrong.
Now all I've got to do is refine it so that it does what i want it to do :bg
Thanks everyone for pointing me in the right direction, without that I would still be looking in the wrong place :clap:

Neil

I'm implementing a 'CANCEL' button for the above Edit Boxes. The way I'm getting rid of them at the moment is by means of a loop which adds 4 to hwndEdit & then  Invokes DestroyWindow on each pass through the loop. It works but is this the correct way to do it or is there an easier method?