SubClassing two different controls with the same PROC???

Started by xandaz, January 03, 2011, 06:56:41 PM

Previous topic - Next topic

xandaz

   Can this be done? i have this toolbar and also a tracked menu which use the same commands. I wanted to write the WM_COMMAND stuff only once but it seems it's impossible. Gives errors. I used:
CallWindowProc,lpOldEditProc,hRichEdit,uMsg,wParam,lParam
CallWindowProc,lpOldToolbarProc,hToolbar,uMsg,wParam,lParam
ret
....after all conditions but doesn't work. Seems obvious to me that if this can be done i'd need to chose from control specific messages and also those that are common to both. Oh hell. I guess i'll just use different procs. But hey, anyone knowing how to do this, just feel free to reply. Thanks and bye.

Tight_Coder_Ex

It is for this very reason I wrote http://www.masm32.com/board/index.php?topic=15757.0 but without changing your code, share what you've already done and I/we will probably be able to firgure out a solution

dedndave

i am sure it can be done
so long as you keep all the variables that are written to on the stack (i.e. local)
if you are getting an error it is probably because of conflicting use of a static variable
as Tight says - show us the code - we should be able to work with just the proc that you want to use twice

hutch--

Unless they are identical controls, do yourself a favour and make a seperate subclass for each.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

donkey

Quote from: dedndave on January 03, 2011, 07:35:05 PM
i am sure it can be done
so long as you keep all the variables that are written to on the stack (i.e. local)
if you are getting an error it is probably because of conflicting use of a static variable
as Tight says - show us the code - we should be able to work with just the proc that you want to use twice

Not really necessary, its a callback and there is never a chance of two controls calling it at the same time, there is only one message queue for a process so there can never be more than one being processed at a time. For global variables the same problem exists whether you use the same proc or separate ones.

Quote from: hutch-- on January 04, 2011, 12:02:51 AM
Unless they are identical controls, do yourself a favour and make a seperate subclass for each.

It makes no difference if the controls are the same type or not if you use the common controls subclassing helpers. See my article on common controls subclassing here:

http://www.masm32.com/board/index.php?topic=15708.0

You can use the same subclassing procedure, Windows will direct the DefSubclassProc to the correct original (or next one in the chain) automatically. If you need to support a wider set of Windows versions you can use the ordinal calls instead of the named APIs and go back as far as Win98, the named APIs started at Windows XP.
"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

xandaz

   ok here goes the code. Im not sure that the commands are working. They was working yesterday but i rearely use mem allocations and last time i checked it was a bit faulty. Thanks. Sorry ... i was supposed to make this post yesterday night but somehow i didn't. I just opened the laptop and it was on post edition page. Sorry. Thanks and bye

xandaz


dedndave

i see there is no error checking after LocalAlloc
i would use the Heap functions - although you may have a reason for using Local
and - it's not a bad idea to:
1) calculate required bytes
2) add 16 for the allocation size
3) check Alloc for error status
4) use mod 16 to calculate the used base address
5) store the calculated base and the handle base
6) use the calculated base for storage
7) use the handle base for Free

the thing is going to allocate memory in page-sized (4 kB) blocks, i think
but, without knowing the base address ahead of time, you don't know what size to request
i suppose you could allocate a small amount, see what the base is, the free it and allocate a size based on that
i dunno if it would work

i noticed a little tihng...
.const

MainWindowWidth     equ     600

EQUates are assembler directives - you do not need to open a section for them
not sure it matters if you open the .const section if you don't put any data in it - probably not

but that isn't what the original post was about - lol
i see a few variables that are written in WndProc
the ones that grab my attention are hToolbar, ToolbarReservedY, hRichEdit, hFile - there may be a couple others
i would think these need to be stored in indexed arrays or something
for each one, you want a copy for each instance
so, you might want an arrays of instances, with indeces to sort out the other arrays

InstanceList - has an index for each handle:
lpOldEditProc     0
lpOldToolbarProc  4


then you use that index to find the indiividual value of hToolbar, ToolbarReservedY, hRichEdit, hFile, etc in respective arrays
there is probably a simpler way - lol
but, you get the idea

each instance could have a structure with each unique value
same idea - different implementation

qWord

xandaz,
are you modifying esi and edi in API-callbacks(EditProc) without saving them? - this isn't a good idea  :bg

qWord
FPU in a trice: SmplMath
It's that simple!

xandaz

   Yes i am. Forgot all bout that even tho the other we spoke about it in the forum. It was rlative to the StreamINOUTproc i think. Thanks. and bye