Possible improvements

[cristianbuse]

Hats off for finding this Ben! Thank you for sharing!

How it works

As you pointed out in your code comments, VBA can be tricked to interpret an array of UDTs as if it were an array of something else.
Quick example, the following is perfectly legal code:

Option Explicit

Private Type SingleWrapper
    s As Single
End Type

Public Property Let WriteLongToSingle(ByRef arr() As VbVarType, ByVal newValue As Long)
    arr(0) = newValue
End Property

Sub TestLongToSingle()
    Dim arr(0 To 0) As SingleWrapper
    WriteLongToSingle(arr) = 1234
    Debug.Print arr(0).s 'Prints  1.729202E-42
End Sub

The array element interpretation type, besides VbVarType, can be any custom Enum defined in native VBA, or any typedef defined in any of the loaded libraries, as you already wrote. VbVarType is defined in VBE7.dll.

The nice thing about the following definition in VBE7.dll internal type library, is that it allows an 8-Byte type:

typedef [public, custom(F914481D-9C62-4B43-9340-E9B2E6252E5F, 1)]
int64 LONG_PTR;

and so code like the following allows us to write pointers:

Option Explicit

#If VBA7 = 0 Then
    Private Enum LONG_PTR: [_]: End Enum
#End If

Private Type DoubleWrapper
    d As Double
End Type

Public Property Let WritePtrToDouble(ByRef arr() As LONG_PTR, ByVal newValue As LongPtr)
    arr(0) = newValue
End Property

Sub TestLongToSingle()
    Dim arr(0 To 0) As DoubleWrapper
    WritePtrToDouble(arr) = 123.456789
    Debug.Print arr(0).d 'Prints  6.07700744384733E-322
End Sub

So far, all of the above can also be achieved with calls to LSet and custom UDTs.
However, your method can also overwrite the underlying pointer of an uninitialized array with something like:

Option Explicit

Public Enum SAFEARRAY_FEATURES
    FADF_AUTO = &H1
    FADF_FIXEDSIZE = &H10
End Enum

Public Type SAFEARRAYBOUND
    cElements As Long
    lLbound As Long
End Type
Public Type SAFEARRAY_1D
    cDims As Integer
    fFeatures As Integer
    cbElements As Long
    cLocks As Long
    pvData As LongPtr
    rgsabound0 As SAFEARRAYBOUND
End Type

Private Type PointerAccessor
    ptrs() As LongPtr
    sa As SAFEARRAY_1D
End Type
#If VBA7 = 0 Then
    Private Enum LONG_PTR: [_]: End Enum
#End If

Private Sub Init(ByRef ptrs() As LONG_PTR, ByVal ptr As LongPtr)
    ptrs(0) = ptr
End Sub

Private Property Get MemLongPtr(ByVal addr As LongPtr) As LongPtr
    Static pa(0 To 0) As PointerAccessor
    With pa(0)
        If .sa.cDims = 0 Then
            .sa.cDims = 1
            .sa.cLocks = 1
            .sa.fFeatures = FADF_AUTO Or FADF_FIXEDSIZE
            Init pa, VarPtr(.sa)
        End If
        .sa.pvData = addr
        .sa.rgsabound0.cElements = 1
        MemLongPtr = .ptrs(0)
        .sa.rgsabound0.cElements = 0
        .sa.pvData = 0
    End With
End Property

Sub TestReadPointer()
    Dim l As LongPtr: l = 123456789
    '
    Debug.Assert MemLongPtr(VarPtr(l)) = l
End Sub

thus creating a fake array that we can then point wherever we want.

This is superior to other approaches like the following:

• fake ByRef Variant which uses a call to VariantCopy
• base fake array which uses a RtlMoveMemory/memmove API call

because it uses no dependency.

Suggested improvements

The current approach in 07e9b0d makes use of the same mechanism I described above. It initializes a bunch of fake arrays that can then read / write memory remotely.

However, it does one more thing - it manipulates offsets and array element sizes to write directly to variables declared at module level. This is very hard to follow even for advanced users. Plus it requires quite a lot of constants.

Improvements:

1. I would simplify to just initializing a single fake array of pointers. I would then use that fake array of pointers to initialize anything else needed without the burden of mantaining all that complex logic.

2. I would use a separate SAFEARRAY structure for each of the fake arrays. While VBA is single threaded, the Locals and Watch window can do asyncronous calls into VBA methods, and so while debugging, a call from one of these windows can change the current single SAFERRAY (e.g. calling RefDbl) while VBA itself is trying to use the same SAFERRAY for something else (e.g. calling RefDate) leading to a crash of the app.

3. I would also group the fake array with their corresponding SAFEARRAY into a separate custom structure - to keep related things together.

Without doing this for all of the data types you currently have, I would apply all of the above to something like the following:

Option Explicit

Private Enum DataTypeSize
    byteSize = 1
    intSize = 2
    longSize = 4
#If Win64 Then
    ptrSize = 8
#Else
    ptrSize = 4
#End If
    currSize = 8
#If Win64 Then
    variantSize = 24
#Else
    variantSize = 16
#End If
    '... to be added
End Enum

Public Type SAFEARRAY_1D
    cDims As Integer
    fFeatures As Integer
    cbElements As Long
    cLocks As Long
    pvData As LongPtr
    cElements0 As Long
    lLbound0 As Long
End Type

Private Type PointerAccessor
    ptrs() As LongPtr
    sa As SAFEARRAY_1D
End Type
Private Type IntegerAccessor
    ints() As Integer
    sa As SAFEARRAY_1D
End Type
Private Type LongAccessor
    lngs() As Long
    sa As SAFEARRAY_1D
End Type

#If VBA7 = 0 Then
    Private Enum LONG_PTR: [_]: End Enum
#End If

Private m_safeAddr As LongPtr

Private Sub InitAccessor(ByVal accPtr As LongPtr _
                       , ByRef sa As SAFEARRAY_1D _
                       , ByVal elemSize As DataTypeSize)
    Static pa(0 To 0) As PointerAccessor
    With pa(0)
        If .sa.cDims = 0 Then
            m_safeAddr = VarPtr(m_safeAddr)
            InitSafeArray pa(0).sa, ptrSize
            WritePtrNatively pa, VarPtr(.sa) 'https://github.com/WNKLER/RefTypes
        End If
        .sa.pvData = accPtr
        '
        InitSafeArray sa, elemSize
        .ptrs(0) = VarPtr(sa)
        '
        .sa.pvData = m_safeAddr 'To avoid accesing released memory e.g. via Locals window
    End With
End Sub
Private Sub InitSafeArray(ByRef sa As SAFEARRAY_1D, ByVal elemSize As Long)
    Const FADF_AUTO As Long = &H1
    Const FADF_FIXEDSIZE As Long = &H10
    With sa
        .cDims = 1
        .fFeatures = FADF_AUTO Or FADF_FIXEDSIZE
        .cbElements = elemSize 'This is required for indexing if the fake array has more than 1 element
        .cLocks = 1
        .pvData = m_safeAddr
        .cElements0 = 1
    End With
End Sub
Private Sub WritePtrNatively(ByRef ptrs() As LONG_PTR, ByVal ptr As LongPtr)
    ptrs(0) = ptr
End Sub

Public Property Get RefInt(ByVal Target As LongPtr) As Integer
    Static ia As IntegerAccessor
    If ia.sa.cDims = 0 Then InitAccessor VarPtr(ia), ia.sa, intSize
    ia.sa.pvData = Target
    RefInt = ia.ints(0)
    ia.sa.pvData = m_safeAddr
End Property
Public Property Let RefInt(ByVal Target As LongPtr, ByVal RefInt As Integer)
    Static ia As IntegerAccessor
    If ia.sa.cDims = 0 Then InitAccessor VarPtr(ia), ia.sa, intSize
    ia.sa.pvData = Target
    ia.ints(0) = RefInt
    ia.sa.pvData = m_safeAddr
End Property

Public Property Get RefLong(ByVal Target As LongPtr) As Long
    Static la As LongAccessor
    If la.sa.cDims = 0 Then InitAccessor VarPtr(la), la.sa, longSize
    la.sa.pvData = Target
    RefLong = la.lngs(0)
    la.sa.pvData = m_safeAddr
End Property
Public Property Let RefLong(ByVal Target As LongPtr, ByVal RefLong As Long)
    Static la As LongAccessor
    If la.sa.cDims = 0 Then InitAccessor VarPtr(la), la.sa, longSize
    la.sa.pvData = Target
    la.lngs(0) = RefLong
    la.sa.pvData = m_safeAddr
End Property

I've only done just Integer and Long but you get the idea - every single fake array (accesor) is isolated from the other ones and even points to a safe address after each method exits. This avoids any potential crashes with shared resources or accesing released memory.

Looking forward to hear your thoughts.

[cristianbuse]

By the way, Private Sub WritePtrNatively(ByRef ptrs() As LONG_PTR, ByVal ptr As LongPtr) would not work correctly in some scenarios on x32 and that's because LONG_PTR is defined as int64 which is always 8-byte. So, in VBA7 under x32 we would be writing a 4-Byte integer (Long) to a 8-byte integer thus having the potential to screw up the pointer if the signed integer has the sign bit on.

More correct would be something like:

#If Win64 Then
Private Sub WritePtrNatively(ByRef ptrs() As LONG_PTR, ByVal ptr As LongPtr)
#Else
Private Sub WritePtrNatively(ByRef ptrs() As VbVarType, ByVal ptr As LongPtr)
#End If
    ptrs(0) = ptr
End Sub

which would also remove the need to declare Private Enum LONG_PTR: [_]: End Enum

[WNKLER]

Are you sure VBA.LONG_PTR resolves to int64 on x32?
This is the definition I pulled from the embedded TypeLib (.tlb) resource in the x32 VBE7.DLL:

[public, custom(F914481D-9C62-4B43-9340-E9B2E6252E5F, 1)]
typedef long LONG_PTR;

And, the Windows SDK defines LONG_PTR as:

typedef __int3264 LONG_PTR;

According to Windows MIDL, __int3264 is defined as:

An integer that is 32-bit on 32-bit platforms, and is 64-bit on 64-bit platforms.

[cristianbuse]

Not sure. I only had the x64 version of the VBE7.dll and the definition was int64 in the tlb. I assumed it's the same for x32 but you are probably right. Will have access to a x32 version of the dll but only tomorrow. I will come back to confirm

[WNKLER]

Both the x64 and x86 versions of the VBA TypeLib define the return type of VarPtr() to be a LONG_PTR:

LONG_PTR _stdcall VarPtr([in] void* Ptr);

In fact, ALL occurrences of LongPtr in the VBE Object Browser correspond to a LONG_PTR-typed definition in the associated TypeLib.
Just like Object corresponds to IDispatch, Any to void, and Unknown to IUnknown.

So, hopefully it works 😅

[cristianbuse]

I can confirm the x32 definition is Long instead of int64 so LONG_PTR should work fine. Apologies for the confusion

[WNKLER]

Hi Cristian, thank you for taking the time to look this over and provide feedback!
It will take me some time to go over your comments.

Just briefly, regarding the bulky constant declarations, I completely agree.
I built that up more as a calculator for my own testing.
I left it in thinking it might make proxy-init less of a black-box.

I invite you to take a look at an even simpler init method I uploaded here: [https://github.com/WNKLER/RefTypes/blob/main/RefTypes_stdole.bas]

Technically, this method depends on stdole, however the project already assumes a reference to stdole in order to support RefUnk.

[cristianbuse]

Funnily enough I just experimented with FONTNAME about an hour ago.

[WNKLER]

FYI, I uploaded a new demo: RefTypesV3.bas

It uses a new technique that overcomes some of the limitations/drawbacks of current solutions.

• No per-call initialization checks
• No per-call setup
• No cleanup
• No shared memory among active calls (no safearrays or global references)

The caveat being that it only works for VBA and p-code applications. (at least, as currently implemented)