-
Jul 4th, 2019, 03:38 PM
#1
Thread Starter
Frenzied Member
_____________________________________________________________________
----If this post has helped you. Please take time to Rate it.
----If you've solved your problem, then please mark it as RESOLVED from Thread Tools.
-
Jul 4th, 2019, 04:15 PM
#2
Re: Just found a VB Bug :O ?
the api call returns 1, vb6 true = -1, so not equal even though the bolfunc= true
i do my best to test code works before i post it, but sometimes am unable to do so for some reason, and usually say so if this is the case.
Note code snippets posted are just that and do not include error handling that is required in real world applications, but avoid On Error Resume Next
dim all variables as required as often i have done so elsewhere in my code but only posted the relevant part
come back and mark your original post as resolved if your problem is fixed
pete
-
Jul 4th, 2019, 04:59 PM
#3
Re: Just found a VB Bug :O ?
The BOOL type is 32 bits so your "bowlFunct" should really be a Long.
The entrypoint you call here has no idea you have broken protocol, so when it writes 4 bytes to the 2 bytes you provided for it... something else could get overwritten.
Some of this may get paved over by the mechanism underlying calls to Declare items but in general it is a poor and dangerous practice to get function signatures wrong.
BOOL vs. VARIANT_BOOL vs. BOOLEAN vs. bool
-
Jul 4th, 2019, 05:55 PM
#4
Thread Starter
Frenzied Member
Re: Just found a VB Bug :O ?
Ok, I do now understand what is going on here..... but
I still find it a bit strange, as the API is referencing a Boolean [bWOW64Process as Boolean] not a Long.
Shouldn't that be returning a True Boolean of -1 or 0 in the first place?
+ Doesn't boolean work in a way where 0 is False and anything <> 0 is True [not just -1]?
_____________________________________________________________________
----If this post has helped you. Please take time to Rate it.
----If you've solved your problem, then please mark it as RESOLVED from Thread Tools.
-
Jul 4th, 2019, 06:00 PM
#5
Re: Just found a VB Bug :O ?
You are playing a game of "pretend" with a Declare, and here you are pretending to be the wrong thing.
IsWow64Process just gets an address to write to. It has no idea that you called it some specific VB type.
-
Jul 4th, 2019, 06:26 PM
#6
Fanatic Member
Re: Just found a VB Bug :O ?
VB6 has no clue about parameters or return type, so it relies on you to provide the correct declaration. BOOL is 32-Bit in the Win32 API, while VB6 Boolean is 16-Bits. In return values, the calling convention uses 32-Bit for return values, and this is done for 32-Bit alignment, so sometimes you might get away with the return value being declared as "Boolean". VB6 in this case throws the upper 16-Bits.
As far as I know, this won't work with parameters. If the parameters are not declared correctly, then all bets are off, and you get undefined behavior. So, whenever you see BOOL in the API Docs, use "As Long" always.
See Windows Data Types.
Last edited by qvb6; Jul 5th, 2019 at 01:34 AM.
-
Jul 4th, 2019, 11:40 PM
#7
Re: Just found a VB Bug :O ?
Originally Posted by some1uk03
Shouldn't that be returning a True Boolean of -1 or 0 in the first place?
It has what the API wrote there.
The Boolean type could had been done in a way that always ensure 0 or -1 when it returns the value, but that check would take time and would had rendered the Boolean type slower.
Originally Posted by some1uk03
+ Doesn't boolean work in a way where 0 is False and anything <> 0 is True [not just -1]?
Yes, and if you change your line from:
Code:
If bolFunc = True Then
to
it works.
Because bolFunc is not equal to True, it is equal to 1. But when evaluated, it is evaluated to True.
Another workaround would be:
Code:
bolFunc = CBool(CInt(bolFunc))
before the If bolFunc = True Then to convert the 1 to -1
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|