Determine the type of common control given a handle?

[Wayne Diamond]

All I have is a handle to a window or control ... given that is there any practical way of determining what type of control it is?

I only need to detect a dozen or so of the common Windows controls (listbox, richedit, edit, etc) - not all of them, and not any custom controls, but obviously I can't just go on the Class name because that can be changed (the standard Richedit control in PBWinspy is "EDM32EDIT", for example)

[Chris Holbrook]

I can't just go on the Class name because that can be changed (the standard Richedit control in PBWinspy is "EDM32EDIT", for example)

Not sure what you mean by type unless it is Class, but I'm sure that you do, so map the class name to your "type of control" using a function or table?

[Rodney Hicks]

GetClassName perhaps?
Or maybe GetClassInfo?

Never used them, yet.

Rod

[Wayne Diamond]

Chris,
> Not sure what you mean by type unless it is Class
Well I am essentially after its _original class name_ (or at least, I guess that'd be the easiest way to determine the type of control). But when a control is created its class can be named anything, as per the PBWinspy example in my original post where a standard Richedit control has its class named "EDM32EDIT".

Rodney,
> GetClassName, Or maybe GetClassInfo?
I havent tried these yet so I'll give them a go now, thanks for searching for me

Cheers

[Paul Squires]

But when a control is created its class can be named anything, as per the PBWinspy example in my original post where a standard Richedit control has its class named "EDM32EDIT".

I think you may be confusing Borje's EDM editing component with a RichEdit control? The EDM control is a custom control written from scratch using Win32 API. It is not based on the RichEdit control whatsoever.

However, I do see your problem in cases where an existing control can be "superclassed".

[Michael Mattias]

>given that is there any practical way of determining what type of control it is?

Let's look at this from another point of view... what are you trying to learn about the window?

The classname and associated class info is what you can get by learning the window class name... but maybe there is another way to get that which you seek - whatever that really is.

MCM

[Adrian Verkuil]

I was after that also Wayne, but if they changed the class name
from the standard "Edit" to "MyEbox" as far as I know your out off luck.

[Chris Boss]

Wayne,

Every window in Windows has a class name.

A Class is the type of window it is (ie. listbox, combobox).

While we tend to refer to some window classes by a generic name (ie. listview), the actual class name may be slightly different.

The listview controls actual class name is:

SysListView32

This is the class name used when the control is created using CreateWindowEx.

The EDM32EDIT control you refer to is not a RichEdit control!

It is a custom window class. Examine Borges code for it and you will see it has its own window procedure and it is registered as a new window class.

Just because it works similiar to a richedit, does not make it a richedit control.

The GetClassName API function is the appropriate way to test a window to see what kind it is (what class).

The problem you may have is that, you may have a program which tests for a general type of control (a text editor of some kind), but different programs may use different control types (class) to accomplish this.

For example, say you want to create a program which can access the main text editor of a number of different code editors. Each code editor program may use a different class for its text editor.

You can not assume that all text editor controls work the same, just because they appear similiar. A Richedit control does not work the same as Borges EDM32EDIT control. You can not handle them all the same.

What you have to do, is research all of the different control types that each code editor uses and add support, one by one, for each one. Your software can only support those of which it has been designed for.

A good example would be a Grid control. There are dozens of types of Grid controls (different classes made by different vendors). You would have to add support for each and every different grid, one by one, to your application and then tell customers what grids are supported.

Because each different window class (control type) is different, they must be treated as totally different entities.

Sorry to say, there are no shortcuts here.

[Michael Mattias]

Just don't tell him about the really nefarious thing one can do: subclass a 'standard' control so an 'edit' control does not behave like an 'edit' control.

[Wayne Diamond]

I was after that also Wayne, but if they changed the class name
from the standard "Edit" to "MyEbox" as far as I know your out off luck.

Yeah I can't really think of any practical ways either.

Basically all I'm trying to do is extract the textual data from a control, so I need to detect if the control is for example a standard edit control in which case I can use %WM_GETTEXT, or if it's a listbox then I can traverse it with %LB_GETTEXT, and so on. And like I said in my OP I only need to do this with a small handful of the standard common controls - not any custom controls. And because you can have a, for example, SysListview32 control with a different class name I can't rely only on the class name alone.

I guess I could try sending various messages and checking the response I get back from the control, but I really don't like the idea of blindly sending a variety of messages to every control, because who knows how they might react!?

Anyway i guess Im out of luck, thanks anyway for your feedback tho ppl

[Chris Boss]

Wayne,

There is no such thing as a SysListview32 control having a different class name.

Now it is possible to build a new custom class based on an existing one, which is called superclassing, but technically speaking the new class is not the same as the one it is based on. A superclass will likely add new features and change some existing features. Because of this you can't be guaranteed that all features of the base class exist in the superclass, so one would have to be very careful in how you interact with it.

The point being that what ever classes you deal with, your code must be specific to every individual class. The existing classes built into Windows are easy to work with, since you have the API docs to tell you how they work and what messages they support. It is custom classes that you have to do extra work for, since you need to research them (get specs from the vendor who created it) individually and write code custom to each custom class.

[Chris Holbrook]

And like I said in my OP I only need to do this with a small handful of the standard common controls - not any custom controls.

yet the example you picked, EDM32, is a custom control

but I really don't like the idea of blindly sending a variety of messages to every control, because who knows how they might react!?

well, if you tried it, then YOU would know!

[Wayne Diamond]

Chris Boss, thanks for clarifying that for me - controls really arent my forte

Chris Holbrook, please accept my humble apologies

[Michael Mattias]

>Anyway i guess Im out of luck

Not if you are limited in your requirement to support only "a small handful of the standard common controls " you are not. Your plan (send appropriate message to control) is a good one.

I know there is an example somewhere in source code section to do this with a listview control.

The only time you may have problems with this ..
A. Control class name not recognized by your program.
B. Author has subclassed a supported classname... eg, he has programmed it to 'eat' a WM_GETTEXT message or whatever the message is for that control. (I did this in one applicaton specifically to prevent data piracy).

[Chris Holbrook]

Chris Holbrook, please accept my humble apologies

Pardon? I can't imagine what for.

As MCM stated and I implied, you can try sending messages. If EDM32 is on your hit list, then you're in luck, the source code is in these forums so you can see how to do it. But if you are aiming to write a tool which will suck the marrow out of any control, you will have to try another way.