Obtaining a control handle..

[K_F]

Hi Ramon, just a thought on obtaining control handles, correct me if I'm wrong here..

If I have a control named edtEDIT in the wndMAIN, and edtEDT has it's own window proc, can I not extract the handle of edtEDIT with it's WM_Create (or any other) message
instead of using a GetWindowItem, or is the hWnd here, still the parent window handle ?

wndMainedtEdit Proc hWnd:HWND, uMsg:ULONG, wParam:WPARAM, lParam:LPARAM
                 .If uMsg == WM_CREATE
                       mov     hedtEDIT, hWnd


Thanks

[rsala]

Hi K_F,

Thanks for using Easy Code!

The WM_CREATE message is only sent when a window object is created (Window, MDIWindow or DialogBox), but not for child controls since their window procedures are subclassed once the controls have been created. So the answer is no, you can not get the handle of the edtEDT control on its WM_CREATE message because it is never received. You should get the handle in the WM_CREATE message of the parent window by using the GetWindowItem method (also you can use the GetDlgItem API function).

Regards,

Ramon

[K_F]

Thanks Ramon.
I'm trying to clarify the value of hWnd in the (subclass) proc below..

wndMainedtEdit Proc hWnd:HWND, uMsg:ULONG, wParam:WPARAM, lParam:LPARAM

Would hWnd be the parent handle, or the edtEdit handle. ?
I'm thinking along the line that if it is the control handle, one could use it.

My easycodeV18 help file has 'bombed' under Win7,  so I cannot readup on it.
:icon_cool:

[dedndave]

what you re going to find is that, under windows 7, these controls have a different hierarchy
particularly if you use the glass theme
some controls are even affected by using xp themes with common controls v 6.0
simple buttons come to mind - hard to set the background color on an xp theme button   :P

you may want to try using Spy++ to see how they are put together   :t
i use v 8.0

http://mdb-blog.blogspot.com/2010/11/microsoft-spy-or-spyxx-for-download.html

a while back, i was playing with the GetOpenFileName dialog and ran into the same thing
i wrote some code to detect the window hierarchy and sub-class accordingly
i guess we lost interest in that or something - i don't think it ever got tested under windows 7

http://www.masmforum.com/board/index.php?topic=16931.msg154917#msg154917

there is an attachment on that post - give it a shot

[K_F]

Thanks
 :t

[rsala]

Hi K_F,

wndMainedtEdit Proc hWnd:HWND, uMsg:ULONG, wParam:WPARAM, lParam:LPARAM

Yes, it is the edtEdit handle and, of course, you can use it. However, child controls send most of their events (click, focus, etc.)  to their parent through the WM_COMMAND and WM_NOTIFY messages. So it is easier and faster managing those events in the parent window, except if you are going to control something that WM_COMMAND or WM_NOTIFY messages do not control.

Regards,

Ramon

[K_F]

Thanks Ramon,
This is what I was thinking, as the control is made with CreateWindow(Ex), according to the API 'bible'.

I was making a plan to pick up the control handle on the WM_Create message, instead of using the GetWindowItem proc - thus saving a lot of code lines when I have a 'gazillion' controls on a window.
It'll make the code neater.

Maybe if I do  not handle the WM_Create message in the parent window, will it pass it on to the child window (edtEDT) proc, or I can just pass on the create message from parent to child proc !! 

[dedndave]

the WM_CREATE messages are sent to windows as they are created
actually, during execution of the CreateWindow(Ex) call
the CreateWindow call does not return until WM_CREATE has returned

controls fall into the catagory of windows - so they get the message, as well

the question is - how are you creating the edit control

if you are using a system pre-defined class ('Edit',0) then that class provides WndProc
this includes edit controls created in resource
if you sub-class the edit control, your WndProc will not receive the WM_CREATE message
that is because, when the control is created, the system pre-defined WndProc is in use
when you sub-class it, too late - it's already been created   :P

if you are using your own class that is like an edit control, then you can save the handle during WM_CREATE
i doubt this is the case   :P

however, if you create the edit control with CreateWindow(Ex), that function returns a handle
so - if that happens during WM_CREATE of the parent, you can store the handle when it returns

[dedndave]

here is a method i use that might interest you

i use tables for creating multiple controls
then, i call a loop that creates everything from the parms in the table(s)
the handles are stored sequentially into a handle structure

attached is some text to describe how i do it
you may want to come up with your own   :P

in your case, you might even add a parm to the table or something
and modify the loop code to subclass controls for you

in this one, i modified it to set the font for some control types
you could do a similar mod
add a parm to the table that is a pointer to the WndProc for sub-classing
if it is NULL, that control isn't sub-classed
pretty easy, really   :P

[jj2007]

the handles are stored sequentially into a handle structure

I hope you are not using stosd for doing that
First, it's old-fashioned, second, I have the copyleft :icon_mrgreen:

[dedndave]

as a a matter of fact, i am
Hutch won't like it at all - lol
i use LODSD to get the parms from the table and STOSD to store the handles
if the output handle pointer is 0, it does not store the handles

copyleft - i don't think so - lol
this is a fairly recent version
you can see how eariler versions have evolved over time   :P

the NULL handle pointer is one improvement
but, also, i pass a pointer to the parent handle, rather than the parent handle, itself
that way, the first window in the table can be the main window
it will be created with a parent handle of 0
once it has been created, the parent handle for the rest is now non-zero
tricky, eh ?

i have used this on projects with many windows and controls - complex hierarchy
it works great   

i also have a loop function for positioning windows/controls
and, i have written a similar routine for registering window classes
i only use the later if i have several classes to register

i had considered making one for creating menus
but, there is little advantage over using the resource file for that if you use unicorn strings
i had in mind using a recursive routine for that
the OS does a pretty good job, already

[MichaelW]

but, there is little advantage over using the resource file for that if you use unicorn strings

Unicorn strings?

[jj2007]

but, there is little advantage over using the resource file for that if you use unicorn strings

Unicorn strings?

Check \Masm32\include\windows.inc:

      IFDEF __UNICODE__
        echo     
        echo *************
        echo UNICODE Build
        echo *************
        echo     
      ELSEIF SIXPACKS GT 1
        echo     
        echo ***********
        echo UNICORN build
        echo ***********
        echo     
      ELSE
        echo     
        echo ***********
        echo ASCII build
        echo ***********
        echo     
      ENDIF

[hutch--]

You can tell its a ring in, only beer drinkers think in terms of six packs.

[dedndave]

he's German - lol - nuff said

"unicorn strings" sounds a lot more interesting than "unicode strings", eh ?
it's actually the name of a company   :P