Correct declaration of DWord in VBA - vba

I'm using an API function which returns a DWORD
Because I want intellisense on the LoWord and HiWord, rather than using a Long:
Declare Sub myAPI(ByRef outVariable As Long)
...as suggested in this list of WinAPI -> VBA datatype conversions, I'm using a type:
Public Type DWORD 'same size as Long, but intellisense on members is nice
'#Ignore IntegerDataType
LoWord As Integer
'#Ignore IntegerDataType
HiWord As Integer
End Type
Declare Sub myAPI(ByRef outVariable As DWORD)
However RubberDuck's IntegerDataType inspection reminded me that on 32 bit systems VBA converts 2-byte Integers to 4-byte Longs internally, so I'm wondering whether my DWORD declaration is really 4 consecutive bytes as expected, or 8.
I'm not familiar enough with pointers and bits & bytes to picture in my head what's going on, but I imagine the API somehow knows to fill only the lower half of each part, as I've been getting the results I expect (I think) from the API.

Your user defined type is 4 bytes is size, because Integer is 2 bytes in size.
You can check this for yourself:
Dim dw as DWORD
Dim size as Integer
size = LenB(dw)

Related

"VBA.len" is 4 times slower than "len" (?!) [duplicate]

When I run the following macro:
Sub try()
Dim num As Integer
num = 123
MsgBox Len(num)
MsgBox VBA.Len(num)
End Sub
The first Msgbox displays 2 and the second Msgbox displays 3.
If I remove the first line which says Dim num As Integer, both MsgBoxes display 3.
Can anyone explain why?
Len and LenB are not just ordinary functions, they are keywords, and as such are found on the list of VBA keywords (although LenB is only mentioned after you click through to Len).
Mid would be another example of such keyword disguised as function, whereas e.g. Left isn't on the list at all, because that is just an ordinary function.
It has to be a keyword because one of its jobs is to perform the compile-time task of determining the storage size of a variable. E.g. with private user-defined types, an ordinary function could not do that at all:
Private Type foo
a As Long
b As String
End Type
Sub TestLens()
Dim f As foo
MsgBox Len(f) ' OK
MsgBox VBA.Len(f) ' Compile time error
End Sub
The fact that the object browser brings you to VBA.Len when you press Shift+F2 on that Len(f) is both correct and misleading.
The Len(f) here does not actually call the VBA.Len function that determines the string size, it simply cannot do that because it would require coercing a private struct into a Variant. Instead it calculates the size of foo at compile time and substitutes the result as a literal constant into the executable.
In your example the Len(num) calculates the compile-time size of variable num (which is 2) and substitutes the constant 2 into the resulting object code, whereas VBA.Len(num) packs the value of num into a Variant and passes that variant to VBA.Len where it's further converted to string "123" and the length of that is returned.
It has to do with the way that VB stores integers and how the Len() function handles arguments that are not strings.
When a datatype that is not a string is passed to the Len() function, it returns the nominal number of bytes used to store the data (VB uses 2 bytes to store an integer). See the documentation for the Len function.
The Len() function will automatically cast the variant variable (which is created by assigning a value to a variable without declaring it first) as a string. The return isn't changing because the storage allocation changes (although it does; variants require 16 bytes of storage space, minimum). Since the implicitly declared variable is actually a variant type, VB will automatically change its type based on the situation. In this case, Len() expects a string so VB makes the variable a string.
You could use Msgbox Len(Cstr(num)) to cast the integer variable as a string before passing it to the Len function if your intent is to return the number of characters in your integer value.

Is there any limits for the Range.Cells.Count?

I have a simple row counter.
Total = Sheets("support").Range("A1", Sheets("support").Range("A1").End(xlDown)).Cells.Count
It works perfect until I count more ten thousands rows, because in that case I get this error message:
Overflow
What cause this and how can I count for example more hundred thousands rows?
.Cells is redundant, the .Count member call can be made directly off the Range object returned by the preceding Range.End member call.
That said, it depends what Total is declared as. If it's an Integer, then it only has 16 bits to store a signed integer, which means its upper limit is 32,767 - i.e. 2^15-1.
Dim Total As Integer ' 16-bit
Using a Long integer would give it 32 bits to do the same, making its upper limit 2^31-1, which should be more than enough for most uses.
Dim Total As Long ' 32-bit
If you overflow a Long, VBA7 on 64-bit systems gives you LongLong, a 64-bit signed integer type that won't overflow until 2^63-1 is busted.
Dim Total As LongLong ' 64-bit
You should use the CountLarge property instead of Count, i.e.
.Cells.CountLarge

Unknown SetProcessDpiAwareness Error Result

I have 1 computer out of 50 that is returning a non zero result from SetProcessDpiAwareness and I can't find any information on it. I am setting the DPI Awareness to Unaware. I have one computer that is returning a value of 105621835743232(Decimal). It seems to still be setting the DPI Awareness to unaware like it should but gives a return value that is not expected.
Private Declare Function SetProcessDpiAwareness Lib "shcore.dll" (ByVal Value As PROCESS_DPI_AWARENESS) As Long
Private Function SetDPI() As Long
'Results from SetProcessDPIAwareness
'Const S_OK = &H0&
'Const E_INVALIDARG = &H80070057
'Const E_ACCESSDENIED = &H80070005
Dim lngResult As Long
lngResult = SetProcessDpiAwareness(PROCESS_DPI_AWARENESS.Process_DPI_Unaware)
Return lngResult
End Function
This is a clickonce winforms application so I can't use the manifest to set DPI.
Any help with locating documentation would be greatly welcomed!
Thanks in advance.
This API function's return value is a 32 bit integer so you should use Integer rather than Long. Note that Long is a 64 bit type.
I also strongly recommend using p/invoke rather than Declare. The latter exists for compatibility reasons. P/invoke offers much greater control of the import process.

Need a method for storing obscenely long numbers in number format (not scientific)

How would I go about storing a very large number in number format and not scientific.
Please bear in mind that the number I will be storing is too big for the Long data type.
I've set it as a String.
I have a userform with a command button and a textbox.
Below is the sample code:
Private Sub Cmd_Click()
Dim bits As Integer
Dim out As String
bits = 64
out = 2 ^ (bits - 1)
Txt_Output.Value = out
End Sub
The above will return: 9.22337203685478E+18.
But I want 9223372036854775807.
Can anyone explain how to avoid this?
Thanks in advance.
P.S. I'm hoping to avoid having to use an array.
You can achieve that specific calculation using Decimal data types and a modification to the calculation routine:
Private Sub Cmd_Click()
Dim bits As Integer
Dim out As Variant
Dim i As Long
bits = 64
out = CDec(1)
For i = 1 to bits - 1
out = out * 2
Next
Txt_Output.Value = out
End Sub
By forcing out to be a Variant/Decimal, the calculation does not lose precision as it is being calculated. However some things, such as CDec(2) ^ CDec(63) would still lose precision as the calculation would be done using an intermediate Double precision, so you will need to be very careful as to what calculations you do.
This might give you clues as to how to generalise that method to achieve what you need.
If you have 64-bit Excel, you can use the LongLong data type.

Why do Len and VBA.Len return different results?

When I run the following macro:
Sub try()
Dim num As Integer
num = 123
MsgBox Len(num)
MsgBox VBA.Len(num)
End Sub
The first Msgbox displays 2 and the second Msgbox displays 3.
If I remove the first line which says Dim num As Integer, both MsgBoxes display 3.
Can anyone explain why?
Len and LenB are not just ordinary functions, they are keywords, and as such are found on the list of VBA keywords (although LenB is only mentioned after you click through to Len).
Mid would be another example of such keyword disguised as function, whereas e.g. Left isn't on the list at all, because that is just an ordinary function.
It has to be a keyword because one of its jobs is to perform the compile-time task of determining the storage size of a variable. E.g. with private user-defined types, an ordinary function could not do that at all:
Private Type foo
a As Long
b As String
End Type
Sub TestLens()
Dim f As foo
MsgBox Len(f) ' OK
MsgBox VBA.Len(f) ' Compile time error
End Sub
The fact that the object browser brings you to VBA.Len when you press Shift+F2 on that Len(f) is both correct and misleading.
The Len(f) here does not actually call the VBA.Len function that determines the string size, it simply cannot do that because it would require coercing a private struct into a Variant. Instead it calculates the size of foo at compile time and substitutes the result as a literal constant into the executable.
In your example the Len(num) calculates the compile-time size of variable num (which is 2) and substitutes the constant 2 into the resulting object code, whereas VBA.Len(num) packs the value of num into a Variant and passes that variant to VBA.Len where it's further converted to string "123" and the length of that is returned.
It has to do with the way that VB stores integers and how the Len() function handles arguments that are not strings.
When a datatype that is not a string is passed to the Len() function, it returns the nominal number of bytes used to store the data (VB uses 2 bytes to store an integer). See the documentation for the Len function.
The Len() function will automatically cast the variant variable (which is created by assigning a value to a variable without declaring it first) as a string. The return isn't changing because the storage allocation changes (although it does; variants require 16 bytes of storage space, minimum). Since the implicitly declared variable is actually a variant type, VB will automatically change its type based on the situation. In this case, Len() expects a string so VB makes the variable a string.
You could use Msgbox Len(Cstr(num)) to cast the integer variable as a string before passing it to the Len function if your intent is to return the number of characters in your integer value.