Proposed Change to _WinAPI_HiWord()

[wraithdu 69]

Considering the discussion a few weeks ago about BitShift being a *signed* shift in AutoIt, shouldn't the _WinAPI_HiWord function, and indeed all UDF functions where a DWORD needs to be split into hi and lo words by any means (the _WinAPI_HiWord function or manually via BitShift), be changed accordingly:

Func _WinAPI_HiWord($iLong)
    Return BitAND(BitShift($iLong, 16), 0xFFFF)
EndFunc   ;==>_WinAPI_HiWord

While an error likely won't occur very often, this is the only way to assure we are getting the correct hi word result, unless AutoIt changes the way it does BitShift to be unsigned.

Edited January 9, 2010 by wraithdu

[jchd 956]

There is a dirty workaround here

[Zedna 166]

I think this is wrong place to post that.

It would be better to make ticket for it on the Trac.

[wraithdu 69]

I wanted to get some opinions first... seems no one really cares. I'll create a ticket and leave it up to the devs.

[jchd 956]

I wanted to get some opinions first... seems no one really cares. I'll create a ticket and leave it up to the devs.

There is a ticket already open for that and similar 32-64 bit issues. Valik has already discussed that. A recent beta/release has brought integral Mod() -- instead of approximate floating point operation. So things are already underway. As I understand it, a complete rewamp of all these aspects involves significant work and may need more time. I just wanted to fill a little gap in the interim.

[wraithdu 69]

Well, but this is an interim change to the winapi UDF... not sure if they will want to make that change until the AutoIt internal changes are finished or not. I think they should, but it's up to them.

[Valik 471]

I am not a fan of temporary changes. If we know something isn't a final change going into it, what's the point deviating from the current behavior when it's all going to change again?

[wraithdu 69]

Ack. You can delete my feature request ticket then. Wish I'd seen your reply 10 minutes ago...