Reading the .Tag property of a control 
Author Message
 Reading the .Tag property of a control

Is it possible to read the .Tag property of a VB control using the
API?  If so what function would be used?

Thanks,
Steve



Thu, 19 Jan 2012 08:20:27 GMT  
 Reading the .Tag property of a control
Wow.  Can't say I've ever seen this Q before.  Do you mind if I ask why you
would need the API to get this property?

As for a solution - and this is a *complete* shot in the dark here - I would
have to theorize the Tag property for a control would be part of the
control's window properties?  Assuming that is true, perhaps you could use
the EnumPropsEx API function?

http://msdn.microsoft.com/en-us/library/ms633563%28VS.85%29.aspx

--
2025
If you do not believe in time travel,
your beliefs are about to be tempered.

http://www.facebook.com/group.php?gid=43606237254

| Is it possible to read the .Tag property of a VB control using the
| API?  If so what function would be used?
|
| Thanks,
| Steve



Thu, 19 Jan 2012 08:52:25 GMT  
 Reading the .Tag property of a control
On Aug 1, 8:52?pm, "Kevin Provance"

Quote:

> Wow. ?Can't say I've ever seen this Q before. ?Do you mind if I ask why you
> would need the API to get this property?

> As for a solution - and this is a *complete* shot in the dark here - I would
> have to theorize the Tag property for a control would be part of the
> control's window properties? ?Assuming that is true, perhaps you could use
> the EnumPropsEx API function?

> http://msdn.microsoft.com/en-us/library/ms633563%28VS.85%29.aspx

> --
> 2025
> If you do not believe in time travel,
> your beliefs are about to be tempered.



> | Is it possible to read the .Tag property of a VB control using the
> | API? ?If so what function would be used?
> |
> | Thanks,
> | Steve

No I don't mind you asking why.  I found some code (here
http://www.thescarms.com/vbasic/OwnerDrawn.aspx) which demonstrates
how to make an ownerdrawn combobox.  This code has some things with it
I do not particularly like.  One such thing is the code as written
subclasses all controls of a particular class or group of classes.  My
application requires implementing ownerdrawn style on a few specific
controls and not on others (of the same class).

The problem, as I see it, is that the determination to set the
ownerdrawn style bit is made during window creation.  I need some way
to know, before the control actualy exist, if this instance of the
control is one I want to be ownerdrawn.  My thought, therefore, was
that I needed a property which could be set to any arbitrary value
(ie. the Tag property) at design time (ruling out custom properties
using SetProp and friends) and read before the control actualy exists
(meaning I can't simply use VB code to read the property).

I will look into your suggestion, thanks.

BTW, You never got back to me with the solution you found for my
clicking on a pseudo-button in this thread
http://groups.google.com/group/microsoft.public.vb.general.discussion....

Steve



Thu, 19 Jan 2012 09:41:34 GMT  
 Reading the .Tag property of a control
On Aug 1, 8:52?pm, "Kevin Provance"

Quote:

> Wow. ?Can't say I've ever seen this Q before. ?Do you mind if I ask why you
> would need the API to get this property?

> As for a solution - and this is a *complete* shot in the dark here - I would
> have to theorize the Tag property for a control would be part of the
> control's window properties? ?Assuming that is true, perhaps you could use
> the EnumPropsEx API function?

> http://msdn.microsoft.com/en-us/library/ms633563%28VS.85%29.aspx

> --
> 2025
> If you do not believe in time travel,
> your beliefs are about to be tempered.



> | Is it possible to read the .Tag property of a VB control using the
> | API? ?If so what function would be used?
> |
> | Thanks,
> | Steve

Nope, it does not appear that this property is available in the
windows property list.

Thanks,
Steve



Thu, 19 Jan 2012 09:48:56 GMT  
 Reading the .Tag property of a control
Steve,

Be aware that even if you can read this property, it may not actually have
been set at the time of window-creation.

Would it not be better to initialise some array of references to the
combo-boxes that you want to be ownerdrawn before the subclassing takes
place, and then decide whether or not to subclass based on their existence
in that array?

PC:

Public _odCombos() As ComboBox

--- inside subclassing code
If (_odCombos() contains this ComboBox)
    SetOwnerDraw(on this combo)
End If
------


Quote:
>>I need some way
>>to know, before the control actualy exist, if this instance of the
>>control is one I want to be ownerdrawn.



Thu, 19 Jan 2012 10:31:55 GMT  
 Reading the .Tag property of a control

Quote:
> Steve,

> Be aware that even if you can read this property, it may not actually have
> been set at the time of window-creation.

> Would it not be better to initialise some array of references to the
> combo-boxes that you want to be ownerdrawn before the subclassing takes
> place, and then decide whether or not to subclass based on their existence
> in that array?

> PC:

> Public _odCombos() As ComboBox

> --- inside subclassing code
> If (_odCombos() contains this ComboBox)
> ? ? SetOwnerDraw(on this combo)
> End If
> ------



> >>I need some way
> >>to know, before the control actualy exist, if this instance of the
> >>control is one I want to be ownerdrawn.- Hide quoted text -

> - Show quoted text -

I would like to do that but again the problem is that I have no way of
knowing, at creation time, whether the combobox being created is one
that I want to be owner drawn.  In order for this to work I need some
way of applying a unique identifier to the controls at design time.
Then, when a control is created, I could read it's identifier, compare
it to my list (that array you mentioned) to determine whether or not
this particular control should be owner drawn or not.

As an example picture a form with three comboboxes.  Only one of the
three will need to be ownerdrawn.  At form load the app is sent a
WM_CREATE message for the form and all of it's constituant (windowed)
controls.  This is the point where I need to determine which of the
three comboboxes I need to be ownerdrawn.  It is required at this time
(before creation) because the style bit for ownerdrawn is only read
and used at the time of creation.  So I need a way to uniquely
identify each of the comboboxes at design time.  That identification
then needs to be able to be read at creation time to compare it with
the list (array) of controls that should have that style bit set when
created.  When a control which should be ownerdrawn is found I can
change the style to include the LBS_OWNERDRAWFIXED (or whatever is
appropriate for the control) style bit.  But again, as you can see, I
need to be able to examine the information available at creation time
to determine if the control should be manipulated in this way.

Thanks,
Steve



Thu, 19 Jan 2012 13:24:33 GMT  
 Reading the .Tag property of a control


As an example picture a form with three comboboxes.  Only one of the
three will need to be ownerdrawn.  At form load the app is sent a
WM_CREATE message for the form and all of it's constituant (windowed)
controls.  This is the point where I need to determine which of the
three comboboxes I need to be ownerdrawn.
-------------

You set the style by adjusting the style property of the CREATESTRUCT
structure in the fSetStyle routine, correct?

What's in the Name property of that structure, at that time???

Would that be the name of the control being created?  If so, you could
use the design time Name property to indicate your desire for owner draw:

cboList1
odcboList2
cboList3

Just thinking out loud...
LFS



Thu, 19 Jan 2012 15:38:21 GMT  
 Reading the .Tag property of a control

Quote:

> As an example picture a form with three comboboxes. ?Only one of the
> three will need to be ownerdrawn. ?At form load the app is sent a
> WM_CREATE message for the form and all of it's constituant (windowed)
> controls. ?This is the point where I need to determine which of the
> three comboboxes I need to be ownerdrawn.
> -------------

> You set the style by adjusting the style property of the CREATESTRUCT
> structure in the fSetStyle routine, correct?

> What's in the Name property of that structure, at that time???

> Would that be the name of the control being created? ?If so, you could
> use the design time Name property to indicate your desire for owner draw:

> cboList1
> odcboList2
> cboList3

> Just thinking out loud...
> LFS

Yes the style that is the routine in that is used to actually set the
style bits.  However the decsion as to whether or not to call the
fSetStyle function is made in the the fAppHook method where the only
thing know is the hWnd of the control.

Here is a run down of what happens (as I understand it):
  1) The app starts to SubMain where a system hook is installed.
The hook is monitoring for WH_CALLWNDPROC messages sent to this app.
This essentialy subclasses the entire app

.
  2) With the hook installed



Thu, 19 Jan 2012 21:59:39 GMT  
 Reading the .Tag property of a control

Quote:
> Yes the style that is the routine in that is used to actually set the
> style bits. ?However the decsion as to whether or not to call the
> fSetStyle function is made in the the fAppHook method where the only
> thing know is the hWnd of the control.

> Here is a run down of what happens (as I understand it):
> ? 1) The app starts to SubMain where a system hook is installed.
> The hook is monitoring for WH_CALLWNDPROC messages sent to this app.
> This essentialy subclasses the entire app

> .
> ? 2) With the hook installed

Oops sorry about that. I inadvertantly hit send before I was done.

Let me try it again.  Here is a sequential listing of what happens in
the demo app.  This was created using debug print statements in the
code then running the app.

1) In Sub Main:
       Set windows system hook to monitor all messages sent to
winprocs in our app

2) In Sub Main:
       Show our form.

3) In fAppHook:
       A WM_CREATE message was intercepted by our hook
       The message is for one of the classes (ComboLBox) we want to be
ownerdrawn
       so capture the style word for the window which is about to be
created

4) In fAppHook:
       Since we have a style word stored, subclass this window
       so that we can catch the create message when it is sent
       to the window itself

5) In fSetStyle:
       A window we have subclassed (for the purposes of catching its
create message)
       has recieved a WM_CREATE message so we need to apply the stored
style word.

6) In Form_Load:
       Our form is being loaded

7) In Form_Load:
       Our main form is being loaded so we need to subclass
       the parent of the control(s) we want to be owner drawn
       and send the messages to our fAppWinProc function
       Here we will monitor for the WM_DRAWITEM message for our
       target window

8) In Form_Load:
       Our form has been completely loaded and is now shown

9) In Sub Main
       Remove the system hook

10) In fAppWndProc:
       A WM_DRAWITEM message has been sent to the parent window of
       a control we have subclassed to be ownerdrawn.
       So we must handle the drawing of the item.

My primary problem with this (I have other concerns but this is what I
am working on now) is that the code makes the determination to alter
the style bits when the app recieves the WM_Create message before we
have enough information to determine which control the WM_Create
message is ultimately bound for.  All we know at the point when the
determination is made is that the control is of the correct class.  We
do have the hWnd of the control so I am looking for a way to assign a
unique identifier to that window at design time (or use some existing
value) that can be read at run time when the control is created.  Then
I could use that value to determine whether or not to the sub class
the windows create message.

A further concern here is that, the whole thing is dependant on the
sequence of events ALWAYS happening as shown.  If somehow a new window
is created in between the WM_CREATE message sent to the app (step 3)
and the corresponding WM_CREATE message sent to the actual window
being created (step 5) the thing will not work.  I realize that that
SHOULD never happen, but I do not think code should be based on a
circumstantial happenstance (as opposed to something which is designed
behavior which is "guaranteed" to work as stated)

Thanks,
Steve



Thu, 19 Jan 2012 23:31:16 GMT  
 Reading the .Tag property of a control
While we are at it maybe you guy's (and gals) could help me with
another problem I have with the code.  As written, the size of the
drop down list for a combobox (which has been set to be ownerdrawn) is
not handled correctly.  To see what I am talking about try the demo
(link given in OP) but limit the number of items added to the
cboPictures combo to only two items.  This will result in the dropdown
list only being large enough to show one item.  Worse if you only add
a single item the dropdown list is too small to display anything.

I think this is happening because the app also needs to handle
WM_MEASUREITEM messages.  Unfortunately I have been unable to figure
out how to capture this message.  Further, once I do figure this out I
am unsure as to what I should do to "handle" it.

Anybody got any ideas here?

Thanks,
Steve



Thu, 19 Jan 2012 23:47:47 GMT  
 Reading the .Tag property of a control


<inline>
The demo shows how to subclass controls, and as you say, is dependant
on the process happening in a certain order.  What if you subclass every
combobox so it uses the fSetStyles and then in fSetStyles you can make the
determination if it is the right combobox and either set the style or stop
sub classing the control?  Instead of using one module level variable to hold
the style value, you'd use a collection, associating the style value with the
window handle.  Also instead of one variable for the previous WinProc,
you'd use a second collection to associate WinProcs with their whindow handles.
I've added statement to your outline of what is happening to help clarify the issue:

Let me try it again.  Here is a sequential listing of what happens in
the demo app.  This was created using debug print statements in the
code then running the app.

1) In Sub Main:
       Set windows system hook to monitor all messages sent to
winprocs in our app
    + Create 2 collections:  Styles and Procs

2) In Sub Main:
       Show our form.

3) In fAppHook:
       A WM_CREATE message was intercepted by our hook
       The message is for one of the classes (ComboLBox) we want to be ownerdrawn
       so capture the style word for the window which is about to be created
       + Styles.Add mlSetStyle, CStr(CWP.hWnd)

4) In fAppHook:
       Since we have a style word stored, subclass this window
       so that we can catch the create message when it is sent
       to the window itself
       + Procs.Add msHookWndProc, CStr(XCWP.hWnd)

5) In fSetStyle:
       A window we have subclassed (for the purposes of catching its create message)
       has recieved a WM_CREATE message so we need to apply the stored style word.
      + Get name of control from C.lpszName
      + If name is desired control Then Set the new style using Styles(hWnd)
      + Un Subclass the control using Procs(hWnd)

6) In Form_Load:
       Our form is being loaded

7) In Form_Load:
       Our main form is being loaded so we need to subclass
       the parent of the control(s) we want to be owner drawn
       and send the messages to our fAppWinProc function
       Here we will monitor for the WM_DRAWITEM message for our
       target window
      + Here you can use the desired control's name to subclass it

8) In Form_Load:
       Our form has been completely loaded and is now shown

9) In Sub Main
       Remove the system hook

10) In fAppWndProc:
       A WM_DRAWITEM message has been sent to the parent window of
       a control we have subclassed to be ownerdrawn.
       So we must handle the drawing of the item.

--------
As shown above, you can hook into the creation of all your combo boxes,
and save all their Styles and WinProcs for later use.  When the one you want
is being created, apply your modified style, and for the rest, don't do anything.

It sounds very possible to me, do you see a problem with it?

LFS



Fri, 20 Jan 2012 03:44:09 GMT  
 Reading the .Tag property of a control


Quote:
> I think this is happening because the app also needs to handle
> WM_MEASUREITEM messages.  Unfortunately I have been unable to figure
> out how to capture this message.  Further, once I do figure this out I
> am unsure as to what I should do to "handle" it.

> Anybody got any ideas here?

You capture that message in the same procedure where you capture the
WM_DRAWITEM message, typically using Select Case to determine what
message is being sent.  To respond to that message copy the
MESAUREITEMSTRUCT to a local variable (from lParam) and adjust
the width and height accordingly.  Then copy the structure back to the lParam.

LFS



Fri, 20 Jan 2012 03:59:19 GMT  
 Reading the .Tag property of a control

Quote:

> > I think this is happening because the app also needs to handle
> > WM_MEASUREITEM messages. ?Unfortunately I have been unable to figure
> > out how to capture this message. ?Further, once I do figure this out I
> > am unsure as to what I should do to "handle" it.

> > Anybody got any ideas here?

> You capture that message in the same procedure where you capture the
> WM_DRAWITEM message, typically using Select Case to determine what
> message is being sent. ?To respond to that message copy the
> MESAUREITEMSTRUCT to a local variable (from lParam) and adjust
> the width and height accordingly. ?Then copy the structure back to the lParam.

> LFS

Larry,

Thanks very much for your help.  I will apply these concepts and let
you know how it goes.

Thanks again,
Steve



Fri, 20 Jan 2012 04:23:08 GMT  
 Reading the .Tag property of a control

Quote:


> As an example picture a form with three comboboxes.  Only one of the
> three will need to be ownerdrawn.  At form load the app is sent a
> WM_CREATE message for the form and all of it's constituant (windowed)
> controls.  This is the point where I need to determine which of the
> three comboboxes I need to be ownerdrawn.
> -------------

> You set the style by adjusting the style property of the CREATESTRUCT
> structure in the fSetStyle routine, correct?

> What's in the Name property of that structure, at that time???

> Would that be the name of the control being created?

Hey Steve!  You seem to have totally missed Larry's question here.  I sure didn't
see the response to it, if you did.  Did he just totally miss the boat, or what?
Because I had a very similar thought.  If the Name property doesn't work out, how
about the hwndParent member?  Seems you could create this "special" combo in a
borderless frame control, to distinguish it, for example.
--
.NET: It's About Trust!
 http://vfred.mvps.org


Sat, 21 Jan 2012 04:18:37 GMT  
 Reading the .Tag property of a control

Quote:

> Nope, it does not appear that this property is available in the
> windows property list.

It's almost certainly held in an internal collection, and just as almost certainly
not at all available at the time of window creation.
--
.NET: It's About Trust!
 http://vfred.mvps.org


Sat, 21 Jan 2012 04:19:43 GMT  
 
 [ 23 post ]  Go to page: [1] [2]

 Relevant Pages 

1. How to read mp3 ID3v1 Tag and other properties in ACCESS VBA

2. Problem with TreeView control Nodes and assigning objects to Tag property

3. How do I get a controls tag property using api functions

4. Treeview control tag property

5. Indentifying controls in an array via .Tag property

6. Use Control's Tag property to store a structure or object

7. How do I get a controls tag property using api functions

8. How do I get a controls tag property using api functions

9. PARAM TAG: Control does not Show after reading PARAM values

10. PARAM TAG: Control does not Show after reading PARAM values

11. PARAM TAG: Control does not Show after reading PARAM values

12. Read META-tags from web browser control

 

 
Powered by phpBB® Forum Software