Sign in to follow this  
Followers 0
Bob Coleman

Incorrect handle for SysListView32

7 posts in this topic

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.

Share this post


Link to post
Share on other sites



#2 ·  Posted (edited)

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?

:P

Edited by PsaltyDS

Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

:P


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0