Detecting window styles with bitwise-and Topic is solved

Get help with using AutoHotkey and its commands and hotkeys
pneumatic
Posts: 146
Joined: 05 Dec 2016, 01:51

Detecting window styles with bitwise-and

22 Feb 2018, 12:02

Hello

I was wondering how it is that bitwise-and is able to detect combinations of window styles. For example the style 0xC00000 (WS_CAPTION) is derived from the addition of 0x800000 (WS_BORDER) and 0x400000 (WS_DLGFRAME) and the documentation seems to suggest it could be detected by:

Code: [Select all] [Download] GeSHi © Codebox Plus

If (StyleToCheck & 0xC00000)


It seems like this would throw a false positive if the window happened to have a different style where just one of the bits happened to be equal to one of the bits in 0xC00000, since the bitwise-and would evaluate to a non-zero number and therefore true. Does Microsoft encode the window styles in such a way that happens to avoid this? I can't seem to find the answer on MSDN or actually anywhere. Or does the above method only work for single styles and not combinations? Should I do two bitwise-and checks, one for each style?

Thanks
pneumatic
Posts: 146
Joined: 05 Dec 2016, 01:51

Re: Detecting window styles with bitwise-and

22 Feb 2018, 12:21

Converting the styles to binary, it seems WS_DLGFRAME is encoded on the 23rd bit and WS_BORDER on the 24th bit? This seems to indicate we would need to do a check for each style?

Code: [Select all] [Download] GeSHi © Codebox Plus

If (StyleToCheck & 0x800000) and (StyleToCheck & 0x400000)
msgbox The style is 0xC00000
User avatar
jeeswg
Posts: 4511
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Detecting window styles with bitwise-and

22 Feb 2018, 19:08

I've been working on a mathematics tutorial, here's an excerpt re. window styles:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

pneumatic
Posts: 146
Joined: 05 Dec 2016, 01:51

Re: Detecting window styles with bitwise-and

23 Feb 2018, 01:22

jeeswg wrote:

Code: [Select all] [Download] GeSHi © Codebox Plus

(vWinStyle & 0xC00000 = 0xC00000) && vOutput .= "WS_CAPTION`r`n"


What in tarnation does this mean? Left side is false cause vOutput is blank, then concatenate false with a string? Please explain.
User avatar
jeeswg
Posts: 4511
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Detecting window styles with bitwise-and

23 Feb 2018, 01:37

- The simple answer to your original question is:

Code: [Select all] [Download] GeSHi © Codebox Plus

if (StyleToCheck & 0xC00000 = 0xC00000)

- The code I used is of the form:
(cond) && (action)
If cond is true then action occurs.
If cond is false then action does not occur.

- Alternatively, an equivalent ternary operator:
(cond) ? (action) : 0

- Link:
conversion logic, v1 = -> v1 := -> v2, two-way compatibility - Page 2 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=27069&p=127532#p127532
pneumatic
Posts: 146
Joined: 05 Dec 2016, 01:51

Re: Detecting window styles with bitwise-and

23 Feb 2018, 02:17

So in v2 they changed && from logical-and to a ternary operator? Ok, but I still don't understand the expression. I know it's nice to do lots of things in one line but it's not going to be readable to the lay ahk user such as myself :lol:
User avatar
jeeswg
Posts: 4511
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Detecting window styles with bitwise-and

23 Feb 2018, 02:38

Summary:

Code: [Select all] [Download] GeSHi © Codebox Plus

(cond) && (action) ;valid in AHK v1/v2
(cond) ? (action) : 0 ;valid in AHK v1/v2
(cond) ? (action) ;works in AHK v1 (but not really valid), invalid in /v2

Explaining the magic. One thing you likely know, which is mentioned in the documentation, but which I'll mention anyway. Fundamentally, in short-circuit Boolean evaluation, things that can't affect the final outcome, aren't executed, so for if a && b, if a is false, then a && b must be false, so we don't bother to evaluate b.

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

pneumatic
Posts: 146
Joined: 05 Dec 2016, 01:51

Re: Detecting window styles with bitwise-and

23 Feb 2018, 02:52

Ohhh I probably could have figured that out myself if there was brackets around it :oops:

Code: [Select all] [Download] GeSHi © Codebox Plus

(vWinStyle & 0xC00000 = 0xC00000) && (vOutput .= "WS_CAPTION`r`n")


Because I thought it was being evaluated like this

Code: [Select all] [Download] GeSHi © Codebox Plus

(((vWinStyle & 0xC00000) = 0xC00000) && vOutput) .= "WS_CAPTION`r`n"


But it's funny how ahk still does the right side even when it's short circuited and has no need to (besides being convenient).

But I still don't get why do you check to see if it equals 0xC00000? The first check (bitwise-and) will be true if it contains either of the two styles, so why compare "true" with 0xC00000?
Last edited by pneumatic on 23 Feb 2018, 04:49, edited 1 time in total.
User avatar
jeeswg
Posts: 4511
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Detecting window styles with bitwise-and

23 Feb 2018, 02:55

Two types of 'and', & and &&.
pneumatic
Posts: 146
Joined: 05 Dec 2016, 01:51

Re: Detecting window styles with bitwise-and

23 Feb 2018, 04:46

pneumatic wrote:
But it's funny how ahk still does the right side even when it's short circuited and has no need to (besides being convenient).


Ugh, this is wrong. It will only do the right side if the left side was true. In this case , vWinStyle & 0xC00000 evaluates to true if vWinStyle's 23rd or 24th bit is a 1 (i.e if either WS_BORDER or WS_DLGFRAME are present). But then it checks if that resulting boolean is equal to 0xC00000 (a number which has both 23rd and 24th bits set to 1, and the rest 0's). This is the part I don't understand. I know numbers evaluate to a boolean of true if they are something other than 0 or blank (""), but I don't know why that makes it necessary to compare it with 0xC00000.
User avatar
jeeswg
Posts: 4511
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Detecting window styles with bitwise-and  Topic is solved

23 Feb 2018, 05:01

Some info:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus


Btw:
a & b returns a value based on comparing each bit of a and b
a && b returns 0 or 1 in AHK v1, 0 or b in AHK v2
I sometimes have to be careful not to get them mixed up.

Return to “Ask For Help”

Who is online

Users browsing this forum: fuykaaaaa and 21 guests