forum.vdsworld.com

[DaveR]

I need to have my program get the Window ID from a list box in a iconized application.

I can get the list box's ID using Window Spy or Win Spy... but it's a different ID each time the application is run.

I've had a look at Win Spy's source and tried many different things... without success.

[vdsalchemist]

Dave,
If the application is a VDS program and you just need the ID of it's listbox element then just use @winexist(~LIST1) you can do this with all the built in elements with the exception of the BITMAP and TEXT elements. To get the window ID of an external list box you will have to use the @window and walk the child windows of the parent that holds the child listbox element. You can also use the @winatpoint if you know the exact location on the screen that the listbox element is located.

[DaveR]

Yep, it's an external application.

Maybe I'm having a slow day... but how exactly do I "walk the child windows of the parent"?

[vdsalchemist]

Dave,
First get the ID of the Window that has the ListBox in question using @winexist(parent class name) or @winexist(parent Title) You can get the class name from Window Spy. Next use @window(parent ID,CHILD) after that you will need to call @window(parent ID,NEXT) for the next child and you may have to play around with moving next and prev and child until you figure out the location of the listbox. This is a similar tecnique that Window Spy uses.

[DaveR]

Basically I need to read the text in a non-vds program's list box. The program has a class of #TfMain and the listbox has a class of #TMemo.

If I know the handle I can use that

[DaveR]

Thanks DS,

I'll have a play around with it.

[vdsalchemist]

Dave,
Without seeing the exact program in question here goes nothing...

[DaveR]

That's pretty much what I've been trying to do.

For some reason all I can get is the program's statusbar handle (using CHILD). FIRST, LAST, NEXT and PREV repeatedly return the same handle - i.e. FIRST always returns the same handle, LAST always returnes the same handle etc. But every handle except CHILD isn't from the program in question.

It's as if the program only has 2 handles - which is contrary to what Window Spy shows.

[vdsalchemist]

Dave,
Maybe the other controls are a child of the 1 child control? This is usually the case of Internet Explorer.

[vdsalchemist]

Dave,
Hmmm let me see if I can find some old code of mine? I remember doing a similar thing for Garrett once

[DaveR]

If it helps, you can download the program in question here:
http://www.8ung.at/aldarin/ftp4t.html

And what I need to do is be able to get the text in the "FTP - Server Logfile" list. You'll need to press the "Start Server" button before you'll see any text in the log list.

[vdsalchemist]

Dave,
That helped

[DaveR]

Dude, you're awsome! You managed to do in minutes something that I've been struggling with for 10 hours!

I was just looking at GadgetX and it's EnumChildWindows - and all the other things it can do.

Thanks for all your help.

[vdsalchemist]

Dave,
It took me almost a month to figure that out when I was helping Garrett with it. The VDS help file is not very clear on how to use the @window() function in relationship to the Window Spy tool. Basicly you have to follow the hierachy in the Window Spy. Each child is 1 character to the right if it is not then you use NEXT.
As far as the EnumChildWindows.dsc GadgetX demo it was made to show how to use GadgetX'es built in callback functions and really shouldn't be used for this where the names are actually known since it is slower and depends on a event loop. Those demos show how to make a more complete Window Spy tool. The VDS Window Spy tool misses windows. I don't know why other than maybe they use something other than the EnumWindows and EnumChildWindows functions?

[DaveR]

Ahh, it all makes sense now. Windows Spy suddenly seems a lot more useful.