Getting Listbox Text

[MattNis]

Hello,

I am having troubles retrieving text from a Listbox line.

One example is the listbox in the AutoIT help file.

ControlCommand....GetCurrentSelection always returns a 1

ControlGetText doesn't return anything.

More often than not, I cannot get text from listboxes.

any advice?

[Valik]

Hello,

I am having troubles retrieving text from a Listbox line.

One example is the listbox in the AutoIT help file.

ControlCommand....GetCurrentSelection always returns a 1

ControlGetText doesn't return anything.

More often than not, I cannot get text from listboxes.

any advice?

Is it a Microsoft lisbox? If its not, then I doubt it will work. I can confirm that reading from a listbox works... when the control is one of Microsoft's common controls. I have a script that relies on that ability in order to work at all.

[Valik]

Also, is there actually anything selected in the lisbox? I think it returns 1 if nothing was selected and you try to use that command...

[MattNis]

There was definitely something selected and the control is not a Microsoft control.

The listbox is a WFC.LISTBOX1

Does it mean anything?

Not having the ability to read from listboxes is a huge limitation, eh?

thanks

-Matt

[Valik]

I propose that the following text be added to the top and bottom of every control related command in this formatting:

Control related functions only work on standard Microsoft controls. If a command doesn't work on a particular control, it is not AutoIt's fault, it is the fault of the author of the program for using a non-standard control. AutoIt is not a mind reader and can not interact with controls it doesn't understand. Do not say the functions are all but useless or limited when it is in fact, not our fault.

[MattNis]

AutoIt is not a mind reader and can not interact with controls it doesn't understand.

I fully understand...and I'm sure no one is blaming AutoIT. It's just a little hard to believe that a little creative programming won't solve that problem.

WinRunner can get text from any list or object whatsoever....with just one simple line of code....obj_get_text()

The only reason I'm mentioning winrunner is to show that there is a solution out there that will read non-standard controls and that it's just a matter programming that solution in.

If no one else cares about this functionality, then forget about it, otherwise I think it's quite worthwhile.

[Jon]

The problem is that controls are just windows. Whoever creates a control decides what messages to respond to. If it is not a standard control then "user-defined" messages will be used. There is no way for anyone to determine what user messages a control will respond to as a user defined message is ANY number between WM_USER + lots.

For example, I could write a new list box that I define like:

#define JON_GETTEXT WM_USER + 2678439

And program the control to respond to a JON_GETTEXT message by returning the text that it contains. There is no way i can think of for anyone other than the author of the control to know that the secret message is 2678439. Many people who create custom controls sometimes get their control to respond to a standard "MS" message like WM_GETTEXT and these are the controls that work with AutoIt.

I can't think of any other way of doing it, if someone can then we are all ears.

[Jon]

WinRunner can get text from any list or object whatsoever....with just one simple line of code....obj_get_text()

The only reason I'm mentioning winrunner is to show that there is a solution out there that will read non-standard controls and that it's just a matter programming that solution in. 

If I knew how - I'd add it. It's that simple.

Winrunner must be doing something different to sending messages to a control. God knows what though.

Edited March 15, 2004 by Jon

[Jon]

The winrunner reference guide mentions screen coordinates in it's text functions which leads me to believe it is doing some sort of OCR on the visible text (rather than interacting with the control via messages)....

That's probably worse than not knowing...

[Valik]

I thought perhaps it was using OCR.

[trids]

The problem is that controls are just windows.  Whoever creates a control decides what messages to respond to.  If it is not a standard control then "user-defined" messages will be used.  There is no way for anyone to determine what user messages a control will respond to as a user defined message is ANY number between WM_USER + lots.

For example, I could write a new list box that I define like:

#define JON_GETTEXT WM_USER + 2678439

And program the control to respond to a JON_GETTEXT message by returning the text that it contains.  There is no way i can think of for anyone other than the author of the control to know that the secret message is 2678439.  Many people who create custom controls sometimes get their control to respond to a standard "MS" message like WM_GETTEXT and these are the controls that work with AutoIt.

I can't think of any other way of doing it, if someone can then we are all ears.

.. Jon, I haven't had time to look too deeply into it, but here are a couple of leads that you might find useful ...

StrokeIt

This is a tool that allows you to perform actions based on mouse gestures that you perform by dragging with your right mousebutton. Quite cool all by itself, but the documentation (link above) explains how to determine the message and parameters that get sent to a target window (control) .. using "Girder" below.

Girder

This is a tool that allows one to fire events with an infrared device. The exciting thing about it, is that it appears to have an interface that divulges the message & parameters that one might want to echo in a (AU3 ) script.

Hope this helps somehow. Perhaps we might end up with a new intrinsic function to send a message to a window (control) .. which message and its parameters we can glean from Girder (or an expansion to AU3Spy).

Edited March 17, 2004 by trids

[graham]

The problem is that controls are just windows.  Whoever creates a control decides what messages to respond to.  If it is not a standard control then "user-defined" messages will be used.  There is no way for anyone to determine what user messages a control will respond to as a user defined message is ANY number between WM_USER + lots.

For example, I could write a new list box that I define like:

#define JON_GETTEXT WM_USER + 2678439

And program the control to respond to a JON_GETTEXT message by returning the text that it contains.  There is no way i can think of for anyone other than the author of the control to know that the secret message is 2678439.  Many people who create custom controls sometimes get their control to respond to a standard "MS" message like WM_GETTEXT and these are the controls that work with AutoIt.

I can't think of any other way of doing it, if someone can then we are all ears.

I am sure that this will sound incredibly stupid, but ... I have created many custom controls myself, in Borland's C++ Builder (and some in Delphi & Kylix) adn I am not sure if it is even possible to craete an entirely new control. It certainly seems pointless to me.

Afik, all new controls are descendants of existing windows control classes and, as such, I would expect them to respond to the messages of their parents. In fact, the only way to prevent this inherited behaviour would be to explicitly catch the message and throw it away - and how many creators of new components are going to bother to do that?

As I said, it may sound a bit thick, but I can't undertstand the basic problem - only, I suppose, that you can't be certain what the component's parent class(es) is/are... maybe that can be subtly probed? Try various combination until you get a non-empty text?

Otoh, whereabouts in the control class tree is handling of WM_GETTEXT & WM_GETTEXTLENGTH introduced? All descendants of that should, in all probability, respond by default to WM_GETTEXT.

Like I said, I'm probably just being thick & this has probably all been discussed to death before, so please excuse my stupid newbie ramblings ... (fades off, babling innanities)

[Valik]

I am sure that this will sound incredibly stupid, but ... I have created many custom controls myself, in Borland's C++ Builder (and some in Delphi & Kylix) adn I am not sure if it is even possible to craete an entirely new control. It certainly seems pointless to me.

Afik, all new controls are descendants of existing windows control classes and, as such, I would expect them to respond to the messages of their parents. In fact, the only way to prevent this inherited behaviour would be to explicitly catch the message and throw it away - and how many creators of new components are going to bother to do that?

As I said, it may sound a bit thick, but I can't undertstand the basic problem - only, I suppose, that you can't be certain what the component's parent class(es) is/are... maybe that can be subtly probed? Try various combination until you get a non-empty text?

Otoh, whereabouts in the control class tree is handling of WM_GETTEXT & WM_GETTEXTLENGTH introduced? All descendants of that should, in all probability, respond by default to WM_GETTEXT.

Like I said, I'm probably just being thick & this has probably all been discussed to death before, so please excuse my stupid newbie ramblings ... (fades off, babling innanities)

Creating your own control involves doing all the drawing and stuff yourself. If you know how to handle that stuff, then it's probably easier to have a custom control than a stock one because you could write it in an OO manner. I know off the top of my head that Scintilla creates it's own control, the author just happened to set it up to respond to some Windows messages. But as far as I know, it's all home brewed code. It does all the drawing and stuff for itself and uses it's own set of messages.

[graham]

I know off the top of my head that Scintilla creates it's own control, the author just happened to set it up to respond to some Windows messages.  But as far as I know, it's all home brewed code.  It does all the drawing and stuff for itself and uses it's own set of messages.

That was my point, Scintilla doesn't "just happen" to respond to some windows messages - it inherits that behaviour from its parent, getting it for free this is not something that the Scintilla coder implemented (IIRC, Scintilla is a syntax highlighting memo component? If so, it gets a whole lot of stuff for free from Tmemo).

Sure, it does its own "owner draw" stuff; for syntax highlighting it has to. But, my point here is that unless it explicitly handles WM_GETTEXT and sends back an empty string, then it is going to handle that message by default, because its ancestor does. The control has a text property, inherited from the ancestor, which bears no relationship to what is drawn on the screen and default handling of WM_GETTEXT will return it.

And, like I said, I can't conceive of anyone designing a control from scratch - it would increase the difficulty a hundredfold, over inheriting from an existing control. I never have and can't see that I ever will.

Just my 2c worth.

[graham]

Hmm, Scintilla is probably not the best example to discuss here. When I last looked at it, about a year (or two?) ago, it was windows only - now it is also GTK. I guess that this is a case where one would have to start from scratch & will have to back off slightly from my previous statement. ...

Let's modify it to something like "And, like I said, I can't conceive of anyone designing a WINDOWS ONLY control from scratch - it would increase the difficulty a hundredfold, over inheriting from an existing control. I never have and can't see that I ever will".

But since 99%+ of new controls _are_ windows only ...

[Valik]

Have you ever created your own control? Until then, it might be wise to back off saying anything on the matter at all. You already stuck your foot in your mouth in regards to Scintilla and had to back off something you said about it.

Personally, I dislike how controls work. I'm sure I'm not the only one. Get a bunch of people together who don't and you end up with custom controls. I bet it isn't too hard if were to try to figure it out.

On top of that, I bet simply not passing the message to Windows for default processing would stop all messages from having their "default" behavior. So that would mean unless explicitly handled by the author, Window's won't handle it, either, even if it was a standard control.

[graham]

Have I ever created my own control? Dozens. More than I can count. Have you?

Yes, I "stuck my foot in my mouth" because I stupidly only considered the 99% case and not the 1% exception. But we don't seem to be getting 99% success on getting text from user defined controls.

... simply not passing the message to Windows for default processing would stop all messages from having their "default" behavior.

Of course, it would but, as I ask, how many authors will bother to do this? There are only 2 reasons to do so: 1) you want to override the default behaviour, or 2) you don't want the behaviour at all and don't want outsiders spying on it. I just don't see much need for overriding handling of WM_GETTEXT.

So that would mean unless explicitly handled by the author, Window's won't handle it, either, even if it was a standard control.

I'm sorry, but I don't follow that. The way inheritance works is unless explicitly handled by the author, Window's WILL handle it, SO LONG AS IT IS DERIVED FROM a standard control (and 99% of them are).

That foot/mouth crack sounded antagonistic, so I am wondering if I have put your back up? If so, that was absolutely not my intention; I just thought that a discussion with someone who understands inheritance in C++ and Windows controls might cause someone to think Aha! and to advance the functionality of Autoit a little.