Incorrect handle for SysListView32

[Bob Coleman]

I'm trying to use ControlGetHandle to get the handle of a SysListView32 control. In the specific case that I'm working with, I consistently get a value that is 0x10000 less than the value shown by the Autoit Window Info tool. I know this isn't much to go on, but does this sound familiar to anybody?

I don't know if I could just add 0x10000 to the value and use the result because of my next problem which I'll address in another topic.

[PsaltyDS]

I'm trying to use ControlGetHandle to get the handle of a SysListView32 control. In the specific case that I'm working with, I consistently get a value that is 0x10000 less than the value shown by the Autoit Window Info tool. I know this isn't much to go on, but does this sound familiar to anybody?

I don't know if I could just add 0x10000 to the value and use the result because of my next problem which I'll address in another topic.

I haven't seen this behavior, so we need a way to duplicate your symptoms. What kind of window was it? What OS? Are you running AutoIt 3.3.0.0?

Edited March 16, 2009 by PsaltyDS

[Bob Coleman]

According to my Autoit help file, I have 3.3.0.0 . I'm going to see if I can determine which, if either, handle value is correct and then come back.

[Bob Coleman]

OK, that didn't take too long. If I add 0x10000 to the value returned by ControlGetHandle, the result is usable as the handle of the control in subsequent operations, so I have to conclude that ControlGetHandle is returning an incorrect value.

Adding 0x10000 solves my immediate issue, so the question becomes whether anyone wants to pursue this to understand what is happening in Autoit.

I'm trying to automate a specific operation in Ashampoo BurnYa! DataDisc 2. It appears that finding the apparent Autoit bug would require installing the trial version of Ashampoo BurnYa! DataDisc 2. This is a small extremely simple CD/DVD burning application. If any Autoit developer wants to install it, I'll provide a a script that illustrates the problem.

[PsaltyDS]

OK, that didn't take too long. If I add 0x10000 to the value returned by ControlGetHandle, the result is usable as the handle of the control in subsequent operations, so I have to conclude that ControlGetHandle is returning an incorrect value.

Adding 0x10000 solves my immediate issue, so the question becomes whether anyone wants to pursue this to understand what is happening in Autoit.

I'm trying to automate a specific operation in Ashampoo BurnYa! DataDisc 2. It appears that finding the apparent Autoit bug would require installing the trial version of Ashampoo BurnYa! DataDisc 2. This is a small extremely simple CD/DVD burning application. If any Autoit developer wants to install it, I'll provide a a script that illustrates the problem.

Does it have to be that app to see the problem? If you just pull the handle of the "Edit1" control in a notepad window, does that match your AU3Info data?

[Bob Coleman]

First, I no longer believe that the returned value is always 0x10000 less than the correct value, but I don't think it is ever correct either.

Second, yes, the problem appears to be related to that application or similar. I switched to Ashampoo Burning Studio 6 FREE and got the same problem. The part of the two applications where the problem occurs is the same.

The value for the Edit1 control of Notepad is correct. Also the value for a SysListView32 from a Save As dialog is correct, so it would seem that the problem is probably unique to the Ashampoo applications.

[Bob Coleman]

I've found another instance of this, this time involving Nero. (What is it with these disc burning applications?)

I guess I can't guarantee that this is true, but it seems that in this case an incorrect handle value is returned for the first instance of a sequence of actions in Nero after booting or logging on to the system. Subsequent occurrences of the same sequence seem to result in the correct handle being returned. In fact, I've worked around this particular problem, by duplicating a section of my script and using the handle obtained by the second instance of the section when the two sections are executed in sequence.