2

I'm trying to design a custom type that can be used in APIs which need window handles or other kinds of pointers, and which will work for all systems VBA can run on. Here's what I've got:

#If (Win64 = 1) And (VBA7 = 0) Then
    Public Type LongLong '64-bit systems pre-VBA7 wouldn't have had LongLong
        LoPart As Long
        HiPart As Long
    End Type
#End If

Public Type Pointer 'could alternatively make a LongPtr type for pre VBA7 systems only
    #If VBA7 Then
        Address As LongPtr 'should always be correct right?
    #ElseIf Win64 Then
        Address As LongLong 'should never exist as VBA6 and lower are 32 or 16 bit
    #ElseIf Win16 Then
        Address As Integer '16 bit address, is this correct?
    #Else
        Address As Long '32 Bit pre-VBA7 system
    #End If
End Type

The logic goes:

  1. Only the bitness of the Office host matters, not of the operating system. Is this definitely correct, I'm not sure?
    • Win64/32/16 misleadingly refer to that the version of Office (not the version of Windows - the OS - as the name may suggest).
  2. VBA7 introduced the LongPtr type which evaluates to LongLong in 64 bit hosts, Long in 32 bit hosts - Mac or Windows it should just work (I don't know what it does on a 16 bit host, but can VBA7 even be run on that?). So that's the first check
    • VBA7 is the last edition of VBA so no need to check for more modern than that. But out of interest, is there a way I could?
  3. Next I check for bitness of a pre-VBA7 host; I don't think it can ever be 64, but just in case, that requires a custom LongLong type (since that's only defined in VBA7)
    • Interestingly Win64 works on Macs too - the name really is misleading
  4. Similar checks take place 16 and 32 bit - only they don't need custom types (I assume Integer was defined in 16-bit VBA, and that it's the right datatype to use - I've never come across it so I can't really check)

Now one issue is that the LongLong type flags an error in 64-bit VBA7 systems; I assume because LongLong already exists on those systems so is not a valid name for a type. But the #If Win64 And VBA7 = 0 check should rule out the entire definition in such systems so I don't really know why it's a problem - I've asked a question about that.

Either way the code still runs as expected; any variable of type LongLong just defaults to the builtin rather than mine in VBA7 - I just get Public Type LongLong highlighted red in the editor which is a bit of a pain. Workarounds would be to rename it and avoid clashes (but also change the semantic meaning, and would mean that LongLong couldn't be used elsewhere). Alternatively redefine pointer as 

Public Type Pointer
    #If VBA7 Then
        Address As LongPtr 'should always be correct right?
    #ElseIf Win64 Then
        AddressLo As Long
        AddressHi As Long
    #ElseIf Win16 Then
        Address As Integer '16 bit
    #Else
        Address As Long '32 Bit
    #End If
End Type

which would change the interface a little.

So is this type going to work for all systems, Mac Windows, 32 64 bit, VBA7 VBA6 etc?

Greedo
  • 4,967
  • 2
  • 30
  • 78
  • Don't know anything about your issue, but are you certain that `#If Win64 And VBA7 = 0 ` does what you think it does? – Jim Mack Jun 30 '19 at 22:39
  • 1
    I would recommend this is a post for Code Review: https://codereview.stackexchange.com/ – Dean Jul 01 '19 at 08:15
  • 1
    @Dean Nope. Given that OP states _"Now one issue is that the LongLong type flags an error in 64-bit VBA7 systems;"_, the code is not ready for review yet. – 301_Moved_Permanently Jul 01 '19 at 08:54
  • 1
    #Win16 is irrelevant & always false, there has not been a 16 bit version of office for 25 years. "*64-bit systems pre-VBA7*" - This doesn't matter, Office 2010 was the first 64 bit version & it shipped with VBA7, any prior versions irrespective of the version of Windows they run on have no need of a 64 bit pointer type. – Alex K. Jul 01 '19 at 10:53
  • You seem to be targeting VBA, but this question is tagged "vb6" as well. Are you asking if this type will work on VB6 (the standalone non-VBA pre-dotNET VB) as well? –  Jul 01 '19 at 12:28
  • @JimMack I'm quite sure it does, I believe the operator precedence means `And` is evaluated after `=`. But I've made it more explicit, no reason not to – Greedo Jul 01 '19 at 16:09
  • @PeterCooperJr. Good catch, that's a mistake. While there is next to no difference, I'm not explicitly targeting VB6 - I actually meant VBA6 which is an old version of VBA7 (current office is VBA7.1), but it still hangs around on macs and other places. That said, I'd be happy if this worked on VB6 too, but I don't even know where to start with VB compatibility so I'll leave it for now. Question updated – Greedo Jul 01 '19 at 16:12
  • @MathiasEttinger I'm in split minds; if you look at the linked question, the error is - until someone corrects me otherwise - only a syntax highlighting issue (the IDE highlighter appears to ignore the conditional compilation). The code itself compiles and runs as expected as far as I can tell (although I can't actually test it because I don't have access to the right environments). My main reason for not posing on CR was because I'm not 100% confident this is even right - but I guess it's working as intended *to the best of my knowledge* – Greedo Jul 01 '19 at 16:16
  • Well this is a bit of a grey area, but "does this code do what I think it does?" Kind of questions are not a great fit for CR. If you ever test it and are confident it works, this will be perfect. – 301_Moved_Permanently Jul 02 '19 at 06:03

0 Answers0