Window/Control Finder Tool (like in Spy++)

I often use Spy++ to find the class name of a component and in a recent larger project I was making for a client I needed to add such a tool and since I'm not allowed to redistribute Spy++ (and I didn't need all of the functionallaty anyway) I had to create one myself, and here it is.

http://www.vbforums.com/attachment.p...chmentid=39067

It only contains one small form (and a handy mouse class that you can use to move the mouse pointer around and click or double click wherever you want through code) that stays on top of all others while running (if you don't minimize it of course). By dragging the small magnifying glass icon around you will get the window handle, class name, and the text (if any) of the window or control the mouse is currently over. Just like Spy++ this app will also draw a border around the control you're currently over so you can clearly see that you've picked the correct one.

The project is well commented but feel free to post any question you might have about it.

I've just updated the tool with a couple of new features.

Excellent tool Joacim! :thumb:

It would be nice to have the option of keeping the form always on top, which is easy. Also, the hide finder window possible, but may not be an issue since the form is samll and not large like spy++.

I always wanted to know how to draw that outline around the window. ;)

Edit: Maybe this should be in the UtilityBank instead?

The form always stays on top... But that is, as is, not an option of course. Hiding the window? Nah... I usually search while I'm dragging the mouse so I want to see the text at all times. But if you want that feature go ahead and edit the code :).

About the utility bank... Well maybe, I don't know.

I see the OnTop code but its not working for other windows, only the VB IDE?

Quote:

---

Originally Posted by RobDog888

I see the OnTop code but its not working for other windows, only the VB IDE?

---

????? When I run it it stays on top of all windows.

Probably a glitch on my system because it works now. Guess my system was waiting for me to post about it first to fool me. :( :lol:

Anyways how about displaying the child window handles too and designating that it a parent or child window??

I was thinking of maybe showing the parent handle but looping through all possible childs (where there might not be any) would be a bit of a waste.

No, just like Spy++ does. It should the first child wndow handle. You dont have to give the rest unless they click on that child window handle or a next button to iterate through them?

Yeah, that could maybe be an idea which would be very easy to implement. However I mainly wrote this to be a substitute for the Find Window dialog in Spy++ since I use just that feature a lot.

Oh, I know what this may be from.... Your IDE?

could you make this a vb add in? If you tell me how i will..this would be VERY useful for vb ide!

Hmm... Please edit your post Rob since I haven't had the time to register a domain with that name yet and I don't want people to steal it :)

That is a very good idea remix. In .NET the utilities like this are available from the IDE menus.

It is a very good idea... I'll do that next weekend :)

Edit: Thanks for the quick edit Rob :)

yeah you dont know how nice that is for vb ide. Does this even show child windows?

Currently it only shows the handle and other information about the window or control you're pointing it at.

Nice thing JA :thumb:
but i have never used SPY++ or anything like this........so can anyone explzin me the purpose of this tool!!

I agree with Harsh Gupta, I have never used Spy++ either and dont exactly understand it. For exampe what is "Style"?? And whats "Text"?? I was also wondering(personally) how this all comes together and what is what(when you use the class hWnd) I just found this code on the last thing I was looking at that I dont understand what is what.

VB Code:

Private Declare Function SendMessage Lib "user32" Alias "SendMessageA" _
    (ByVal hWnd As Long, _
     ByVal wMsg As Long, _
     ByVal wParam As Long, _
     ByRef lParam As Any) _
    As Long
 
Private Const WM_CLOSE As Long = &H10
 
' Send a WM_CLOSE msg
SendMessage hWndWindow, WM_CLOSE, 0, ByVal 0&

In this piece of code, what is "Lib user32", is that the class or somthing? and whats "Alias "SendMessageA"?
Well, if you don't want to answer(explain) my stupid newbish question, its okay, but would you give me some advice on learning what is what and how to use it(basics). Well Thanks,

Hiroshi

User32 refers to the user32.dll file, which is one of Windows main library files. User32.dll together with Kernel32.dll and Gdi32.dll makes up the base of Windows. These files contains 100s of functions that all application use, most of the built in functions in VB calls functions in these libraries behind the scene. Just take a basic function like the VB MsgBox function for example. Each time you call that function VB makes a call to the MessageBox function in the User32.dll file.

Now, even though VB itself is rich of different functions it doesn't contain all of the functions available in Windows. As a VB developer, regardless if your using Classic VB or VB.Net, you've probably learned that Windows is event driven. Well, VB is event driven but Windows is actually message-driven... The difference isn't that huge, but Windows application doesn't really respond to events, they respond to messages send to them by the Windows OS. A message can be translated into a event or a property of a control or a window (controls just like Forms are all windows, a ListBox is a window and so is a command button and so on). Different windows respond to different messages. A TextBox for example have its own set of messages while a ListBox have another. However some messages are the same for many windows... If you for example send WM_GETTEXT (WM_GETTEXT is a message) to a command button you will get the text or caption of that button (OK, Cancel or whatever the command button text is).

WM_CLOSE in the example above will send a close request to a window, sending that message to a command button will not do anything but sending it to a Form will close the Form.

Now all windows (Forms and controls) that different applications have created are assigned a handle (by the OS), this handle is called hWnd (a window handle, or handle to a window if you like). You can never know before the application starts which number this handle will get (a handle is nothing but a unique number) since that is determent by the Windows OS when the application is started, or rather when the Form or the Control is created. So it will get different handles each time you run the application.

However if you want to send a message to a window (or control, remember that a control is also a window) you'll need to know which handle it has. You can find the hWnd of a window in another application (not your own) by using the FindWindow function found in the User32.dll file. But since VB doesn't have a wrapper for this function you will need to declare it before you can call it... And that is what is done in the code you posted above... Well, it doesn't declare the FindWindow function, it declares the SendMessage function. FindWindow would look like this:

VB Code:

Private Declare Function FindWindow _
 Lib "user32.dll" Alias "FindWindowA" ( _
    ByVal lpClassName As String, _
    ByVal lpWindowName As String _
) As Long

As you see, both the declaration of FindWindow and SendMessage has an "alias" (FindWindowA and SendMessageA) and that is because all Windows functions (called API functions, API = Application Programming Interface) that can accept strings of text exist in two different versions. One that accepts Ansi strings and one for Unicode strings. So the real function names for SendMessage are either SendMessageA (for Ansi strings) or SendMessageW (for unicode strings, W = WideString). Classic VB (VB6 and earlier versions) always pass a string to an API function as an Ansi string so we need to use that version of the function.

But instead of typing SendMessageA when we call the function we declare it with an alias name of SendMessage (SendMessage is the alias for SendMessageA). In the same way is FindWindow above an alias for FindWindowA. I could have declared FindWindow like this if I wanted to:

VB Code:

Private Declare Function IwantTheHandleOfThisWindowPlease _
 Lib "user32.dll" Alias "FindWindowA" ( _
    ByVal lpClassName As String, _
    ByVal lpWindowName As String _
) As Long

So in my VB code I would now call the function "IWantTheHandleOfThisWindowPlease" which would actually call the FindWindowA function.

So all Windows have a handle, many windows have a text (not all of them), and all windows are also of a class (which I haven't really mentioned, but they are...) and this class has nothing todo with classes you create objects from when you'll type object-oriented-programming (OOP) code.

Oh okay, that helps alot! Thank you so much for explaining it. Nobody else has ever explained it. Makes much more sense. So, basically the "FindWindowA is the API function came and the function name before that is the name you give it to refer to it in your VB code.(am I getting this right?) And everytime you want to send somehthing to a window you have to find its hWnd cause its never the same. but then whats the point of Spy++ or programs that do similar things, they give you the hWnd to things your mouse is over, right? But what use are they to you if they are going to change anyway? That's the only thing I don't get. Oh yeah, also, I don't think you mentioned anything about style, what exacty is that and whats it used for?(like in this program I have similar to Spy++) and how do you know when to use which constants?

Thank you so much for your help,
very much appreciated ^^

Hiroshi

Wait are Constant kind of like Messages? that get sent to wherever.

You've got it pretty much right. I agree that using this tool I wrote or Spy++ to find a window handle is pretty much useless unless you need to know the handle the window have right now. However the FindWindow function, for example, takes two arguments, one is the text of the window (or the caption) which is fine if you want to get the handle of a running instance of the Windows calculator for example since the text or caption (the window title) is always "Calculator", at least if you're running an English or US version of Windows... But let's say you want to get the hWnd of a running instance of Word... Well the text for Word could be "Document1 - Microsoft Word" but it could just as well be "My CV.doc - Microsoft Word" or anything else since Word shows the name of the current opened document in its title. So in that case you can't rely on the text. But you can also use the Class name of the window when you call FindWindow, and the class name for Word is "OpusApp" (for some reason) and that never change. But the name "OpusApp" is probably nothing you would have guessed that Word was called, so in this case this tool is great to use to find the class name of the window.

Constants are not messages themself, but a message is constant. That is a message is a message and the value a message have doesn't change. It's like you call an automatic phone service and you'll need to press 1 to order a pizza and press 2 to enter your credit card information (or whatever). 1 and 2 are of course constant, the number 1 can never be anything but 1. But in this case 1 means "order pizza", but of course only this particular phone service understand that 1 means just that. A TextBox understands that the message with the number 199 means that it should undo the last editing, but a command button wouldn't interpret 199 as an Undo command since a command button doesn't know what Undo is. A TextBox can undo while a command button can't (but you can of course send the undo message to a textbox when you click on a command button). However your code would become very cryptic if you would simply type that you send 199 to the window handle of a textbox. So instead of doing so you would declare a named constant like EM_UNDO (EM = EditBox Message) and give that the value of 199.

The documentation of messages that a TextBox can accept would say that EM_UNDO would be one of them, however it will not actually say which value that WM_UNDO represents. This is because the documentation have been written for C and C++ developers and all of these named constants are already declared in the include files they use. But we VB developers needs to declare them ourself, so to our help we have the API Viewer application, in which we can look up these values and also how we would declare an API function like SendMessage.

WinID (in my sig) works in a similar fashion, but props for making this yourself :thumb:

I am trying to DDE and need the textbox name in the linkitem field. when i hover on the targeted textbox the name shows as ThunderRT6TBox but where does it show that the name is really "text2" and "text3" ?

It doesn't show those names since they are really only useful for the internal program. Normally the name you give a textbox, for example, isn't compiled into the program. The DDE names are not the same thing as the name of the component you have in the source (well, in VB it actually is the same name). The only way you can find out the DDE name is to read the documentation of the program since those are stored internally and are not exposed.