RELOAD!

[rubberduck-vba/Rubberduck] 3 opened issues. 9 issue comments.

hmm maybe... but not Common Controls, I have that (Win 7). Suspect its something to do with registration (or lack thereof) of the Office 8 commndbars.

[Zomis/Server2] 1 opened issue.

anyway ttgtb

Not MSCOMCT2.ocx?

night

hmm let me check

ah wait, wouldn't be valid now I've installed Office

will check when I get around to putting together some VMs

night

Home Time.

@Comintern could be related to the issue regarding missing dependency for the code analysis?

Maybe - I only had one failing test though. It worked after a rebuild clean.

that might been you getting lucky. Without the dependency, the build order can be semi-random.

And it was a unit test I added for #3343.

Weird thing is that the other 2 test were fine, but those were false positive tests, so who knows.

@mansellan I also wonder whether uninstalling Office will break RD again. Not everything necessarily get cleaned up after an uninstall.

I need to find a large, poorly coded module somewhere... I lost my test workbook in a hard drive crash.

@ThunderFrame once linked to a site "The Code Cage" or something like that that had extra awful sample but it's now dead.

I used to have this cluster-f*ck of a workbook with like 250 modules that was awesome for stress testing. I think there might be a download link in the issues now that I think about it... :runs to look:

@Comintern We have plenty of large VBA clusterf*cks on Code Review if you need

I was scanning through my old answers, but most of the code on CR is of a little higher standard than what I'm looking for. :-P

I wonder if any of the high-school coding classes around here use VBA.

i'd think all kids nowadays are learning python or javascript

Heh, the Code Cage on Internet Archive has a "Excel Homework Help" forum. We might have a winner.

@Comintern Yikes

IIR the stress test one I used to have was what prompted us to implement aggregate inspections.

the fact that they named the site "the code cage" should give one pause.

@this I think I have a copy somewhere. AFK ATM, will post later.

I found the issue, but no link. I wonder how he got us the code - I don't remember giving my email.

Oh, that's right. It was a boatload of issues...

Ahah! It was in his repository. I just hit the jackpot. Time to see if any of those 30 thousand inspection results got fixed.

Got a “can you do this” excel request for a 20yr old excel file that’s still being used that nobody know how it works.

Does it work?

we put info in and it gives us answers.

@IvenBach Blackbox.xlsm?

MudBall.xlsm?

@Comintern Nope. BlackBox.xls

[rubberduck-vba/Rubberduck] comintern added label bug to issue #4204: Parser fails on module with complex precompiler directives?

[rubberduck-vba/Rubberduck] comintern added label parse-tree-preprocessing to issue #4204: Parser fails on module with complex precompiler directives?

[rubberduck-vba/Rubberduck] comintern opened issue #4204: Parser fails on module with complex precompiler directives?

[rubberduck-vba/Rubberduck] comintern edited issue #4204: Parser fails on module with complex precompiler directives?

@MathieuGuindon Remember @Freeman's parser bug this morning?

Check out the issue I just opened.

@Comintern are you running 64-bit office?

if so, that's perfectly expected.

Yes.

What's the deal with 64 bit office and the predeclares?

on a 64-bit VBA7, you must use PtrSafe, period.

On a 32-bit VBA7, PtrSafe is optional.

Apparently I've been slumming it in 32 for too long.

On a 32-bit VBA6 and before, PtrSafe is non-keyword and thus will red up.

Therefore, if you load that worksheet in Office 2007, you'll see the other side of #If light up red

the comments are wrong, too

' 32-bit Mac

makes it confusing, I mean

yeah that's true. It'll be OK but only by a happy accident of there being no 64-bit VBA6

yeah

still, we should be able to parse it regardless

I'm curious mainly about how they're nested.

well, recall that each flag are just a literal flag

We're still doing a pre-pass for precompiler, right?

only value of 0 or 1

Not sure?

yes

I think we still make assumption without reading the actual environmental?

I believe we're now equipped to skip it though

or was that only for user defined arguments?

I don't recall ever parsing anything with nested #If logic

But yes, definitely. We need to be using the typelib API.

it's valid, yeah, since as I was saying those are just flags

and you shouldn't treat them as literal Boolean, either

precompiler directives had a number of restrictions in the original grammar - not being nested or intertwined with other blocks was one IIRC

According to Wayne, they are basically a short

meaning that #If Not Mac And VBA7 Then might not do what you think it'd do

I was just going to ask if you could use operations on them.

#If !0 & 1 -> #If 1 & 1 -> #If 1 ->

and of course, definitely shouldn't do #If VBA6 Then .... #ElseIf VBA7 Then.... #End If. That won't work.

well it'll work, but not in the way you expect. The VBA7 branch will be unreachable

BTW, the inspections are blazing compared to when we closed the original issue as resolved due to increased performance.

because in VBA7, the flags VBA7, VBA6 and VBA5 are all 1

that would make a great inspection IMO

in contrast, VBA6 would have VBA6 and VBA5 set to 1 but wouldn't have VBA7 defined, so it'll be as if it is 0.

That means #If VBA6 Or VBA5 will match VBA7. CornerCaseInspection.

Right, so you have to be sure to arrange it as #If VBA7 Then ... #ElseIf VBA6 Then ... #Else ... #End If if you need to handle each differently.

But since he's trying to get it to work on Mac, that necessitates nesting, I think.

(at least I wouldn't want to try to And two integrals together)

I can't find an example case for #3906 anywhere. The code is objectively wrong, but I can't decouple the indices.

sorry!

This one looks like it needs investigation though:

2018-07-17 20:13:05.2057;WARN-2.2.6772.33906;Rubberduck.Inspections.Rubberduck.Inspections.Inspector;System.NullReferenceException: Object reference not set to an instance of an object.
   at Rubberduck.Inspections.Concrete.UnreachableCaseInspection.ParseTreeValueVisitor.GetConstantDeclarationValueToken(Declaration constantDeclaration) in C:\Rubberduck\Rubberduck.CodeAnalysis\Inspections\Concrete\UnreachableCaseInspection\ParseTreeValueVisitor.cs:line 294
   at Rubberduck.Inspections.Concrete.UnreachableCaseInspection.ParseTreeValueVisitor.GetContextValue(ParserRuleContext context, String& …

the inspection has an open/WIP PR

Good deal.

I love the R# stack explorer.

I sometimes wish RD had one :)

#NotGonnaHappen

We'd need a stack first...

maybe we can bribe Wayne for it

[rubberduck-vba/Rubberduck] ThunderFrame opened issue #4205: Parser Test File

[rubberduck-vba/Rubberduck] ThunderFrame added label performance to issue #4205: Parser Test File

@Comintern ^ found it

[rubberduck-vba/Rubberduck] ThunderFrame added label parse-tree-preprocessing to issue #4205: Parser Test File

[rubberduck-vba/Rubberduck] ThunderFrame added label discussion to issue #4205: Parser Test File

@ThunderFrame The irony is killing me.

That doesn't happen to exhibit #3343 does it?

I don't think so - I don't think she knew about objects, let alone doing anything with them

Hmmm...

Oh, wait, that was the easy one.

I'm looking for #3906.

Oh wow, that's a complete train wreck.

My favorite part so far...

  subMsgBox "Oops"
  Stop

O_o

I've yet to see a successful lexer/parser for VBA, written in VBA.

seeing RD, not sure I want to see that happen anyway :)

Seeing this, I almost want to disable unsigned macros.

The number of Windows API calls that don't check the return values for success is appalling. This thing is a memory blender.

you didn't run it did you?

LOL, my god no.

I'd be tempted if it had 64 bit declares.

This one would definitely call for a VM snapshot before use though.

I wonder if the "Oops" displays before the BSOD.

might be a race condition there :)

Yeah, I never ran it either.

I want to after finding this:

'
' Get the Integer portion of a Word
'
Private Function LoWord(dw As Long) As Integer

    On Error Resume Next

    If dw And &H8000& Then
        LoWord = &H8000 Or (dw And &H7FFF&)
    Else
        LoWord = dw And &HFFFF&
    End If

End Function

Given the quality of the code, I wonder if it was only ever run against similarly bad code.

Gotta make sure to strip the sign bit from those pointers, yo.

@Comintern yep, undoubtedly some inspection ideas we'd never have thought of otherwise.

Actually an UncheckedDeclareFunctionReturn would be an awesome inspection.

"If the imported Function is safe to call without checking its return value, you should indicate it as such by explicitly discarding it and declaring it as a Sub."

Maybe as a special subset of return value not used.

Tonight's movie: LOTR The 2 Towers

@IvenBach that's the next LOTR I'm watching with the kids!

we watched fellowship last week :)

I'm bummed by the fact that the fellowship dvd wouldn't play 3 chapters. Brand new newer been opened...

weird

Can't take it back since it was a gift to my old man 5+ years ago.

FML this disk has problems being read...

hmm, is it on netflix?

Don't have Netflix, hulu or any streaming service

blockbuster still around?

@MathieuGuindon Theres like 1 in Alaska

^

LOL

John Oliver did a bit on it

You should consider Amazon Prime

@MathieuGuindon nbcnews.com/news/us-news/…

and i think the alaskan one announced it was closing this week

Because its a useful service and a streaming service incidentally

The free e-reading material is worthwhile too but only if you have kindle

[rubberduck-vba/Rubberduck] comintern opened issue #4206: RD needs an inspection for unassigned and unevaluated Declare Function return values.

[rubberduck-vba/Rubberduck] comintern added label feature-inspections to issue #4206: RD needs an inspection for unassigned and unevaluated Declare Function return values.

[rubberduck-vba/Rubberduck] comintern added label enhancement to issue #4206: RD needs an inspection for unassigned and unevaluated Declare Function return values.

^^^ On Error Resume Access Violation

@Comintern uh, no. They don't throw errors on DLL errors, remember? ;-)

And therein lies the problem...

yeah, i wonder how many people think that results from declare are ok to ignore. I've seen a fair share of code sample don't do that at all. In other cases, they do check but in improper way (e.g. assuming that everything that's 0 is success when the documentation says otherwise)

[rubberduck-vba/Rubberduck] comintern created pull request #4207: Test for anonymous object access in With blocks. Closes #3343 to merge comintern/Rubberduck/next into rubberduck-vba/Rubberduck/next

@this I remember lighting somebody up on CR about that once.

[rubberduck-vba/Rubberduck] bclothier created comment on issue #4206: RD needs an inspection for unassigned and unevaluated Declare Function return values.

Inspecting for null checks on external LngPtr assignments would be a nice inspection too.

got the stubs for the dialog & view working --- the refactoring dialogs are now easily substituted with stubs. Have to work out a logical way to manage the stub's behavior for some unit tests but I think (hope!) it's the easy part since they are set up as singleton.

@Comintern IDK if that can be done without creating false positive? There's lot of ways they use a LongPtr....

I'd say if it isn't a pointer it should be declared as Long or LongLong instead.

[rubberduck-vba/Rubberduck] build for commit 21ba5841 on unknown branch: AppVeyor build succeeded

[rubberduck-vba/Rubberduck] [codecov[bot]](github.com/apps/codecov) created comment on pull request #4207: Test for anonymous object access in With blocks. Closes #3343

[rubberduck-vba/Rubberduck] build for commit 21ba5841 on unknown branch: 52.23% (target 0%)

It's up to the VBA caller to define the semantics of the call, so that should match the intended usage.

Hmm. I know I've had to use LongPtr for stuff that technically aren't pointers to conform to the API definitions.

Really? In VBA? I've abused the hell out of parameter types.

@Comintern Any is very useful

^^^That.

yes we're free to use whatever as long it's compatible. That said, the compatiblity also means that you shouldn't use Long if the documentation says it returns a pointer.

Right, but on the other hand if it really isn't a pointer, I 'm not sure I care what they call it from the VBA side of things. I reserve LongPtr for actual pointers (even if they're documented as Long).

ah yes, here's an example: docs.microsoft.com/en-us/windows/desktop/api/shellapi/…

For that reason, declaring that function to return LongPtr is technically the correct thing to do, even though it's really returning Long

I haven't tried but I'm pretty sure that using Long for the ShellExecute will crash 64-bit host.

or at least fizzle with a silent DLL error.

there's also scope for an inspection for CopyMemory - I've found code that just blindly accepts the address, only for it to be 0..... and BOOM!

That isn't a pointer though, is it? Isn't that a bastardized overloaded HRESULT? Handle != Pointer.

Technically, handles are pointers.

typedef PVOID HANDLE;

typedef void *PVOID;

Right, but I didn't think they were ever intended to be used as a pointer - i.e., you would never directly dereference one.

Therefore, LongPtr are correct data type to use with any H*** data types.

Well, just because we can't dereference a handle, doesn't mean it's safe to use it like 32-bit integer.

I think I'd declare it as conditionally Long or LongLong for semantic reasons.

that'd just make code more hard to read/understand for others. LongPtr does exactly just that.

LongPtr is just syntactic sugar around a typedef alias anyway.

I got it - best of both worlds would be to make a typelib defining aliases for all of the defines in the header files. That way you could just have it return HInstance.

I might do that as a side project.

@Comintern nice - IIRC, there's an issue somewhere for working with header files as snippets, like Pivoke.net

I remember that conversation well.

RDInvoke

#894

Chaps my hide... Two Towers dvd can't be read...

The structs could easily go into a typelib too.

@Comintern I always struggle with the unions

regrets mentioning the construction industry

LOL

Best way to handle unions from VBA (or c# for that matter), is to use a bunch of different "views" on the same struct.

A good analog from the RD code is how I split lparams into high and low words:

[StructLayout(LayoutKind.Explicit)]
private struct LParam
{
    [FieldOffset(0)]
    public uint Value;
    [FieldOffset(0)]
    public readonly ushort LowWord;
    [FieldOffset(2)]
    public readonly ushort HighWord;
}

In c#, a union would be a struct where the FieldOffsets overlap. You can't do that in VBA, but you can make multiple Types that represent different parts of the union.

@Comintern yeah, I know. VBA is painful like that

I could add a ushort MidWord; at offset 1 in c#, not so much VBA.

same with reading dynamic arrays from a binary file

Sequential access?

That could be fun in VBA. Read the entire file into memory as a byte array, then build a SafeArray struct of the appropriate type to point at it.

That would probably be fast as hell compared to the VBA structured reads.

Or depending on the use case, just memory map it

@IvenBach I was about to suggest checking Amazon Prime, but apparently they're dirt cheap on eBay.

@Comintern No, I mean where a binary file has a header, where, say, the 5th Long is the count of structs, then followed by more header. If VBA allowed for dynamic arrays in a Type, you could read it in one go, but AFAIK, you can't.

Ahhh... Yeah, we have some files like that at work. I generally abstract them into a class or set of classes and then deserialize them via the ctors.

@Comintern just gotta wait 10 years and prices get reasonable. Just watching RoTK instead. Thanks for the heads up.

This is why i <3 XML.

@Comintern That's something I've not been working on for far too long. I set out to deserialize the FRM/FRX into XML. I've got the main parts of the form working, and a handful of controls, but I need to revisit the form part to refactor, and then finish off the other controls. And I still have no idea how the custom controls are completely serialized - I'm saving those for last.

Is that somewhere on your fork, or is that in another project?

The idea is that deserializing the FRM/FRX will make it easier to review changes, and make source control easier. There'll just need to be a serialize/deserialize process.

We still need to figure out how the fm20.dll controls get extended. Does the new TypeLib API handle those?

standalone project on my PC, for now. I can't remember if I made an issue for it. Originally it was so we could get the control Types, but iiuc, the TypeLib should be giving us that now.

I may have to take a look at incorporating that into the RDC.

There are a ton of open issues around that.

@Comintern I was hopeful that the alternate TLB in FM20.dll was going to reveal some secrets, but it appears to just be an alternate version without the HTML controls. I guess the correct TLB gets loaded, depending upon whether you elected to have HTML controls available when installing Office (which I don't think you can do in recent versions of Office)

RDC?

@Comintern I assume so. haven't looked yet.

ReferencedDeclarationsCollector

ditto for worksheet controls, and Access form/report controls and maybe even Visio

Yes typelib api can tell you what other interfaces are implemented

They are in the to do for the type lib integration project

How do the Worksheet controls show up? I thought the ActiveX ones were just OLE embedded and the non-ActiveX ones were glorified Shapes.

Just need to be implemented

If there's an available tlb that exposes the full interface set, implementation should be fairly easy.

Aiui they get their own typeinfo

I would be nice if there weren't 2 parallel typelib function sets in 2 different projects too.

Use the documentall method to peek

The RDC version is set up to create declarations - the new API isn't.

I'd have to check some of the VB specific quirks before passing them back and forth between the two.

Well thr type lin api exosts for 2 reasons. One to get to the hidden lib with all dirty details. Two to work around bugs in vba created typeinfo

@Comintern the ActiveX ones should show up. I'm unsure about shapes with OnAction properties. I doubt they show up.

Thwre are at least two lnown bugs with vba created typeinfo that prevent you from using them dirextly

Right, but if they were 2 implementations with common interfaces, the could server both rolls.

And the extra methods?

The RDC doesn't care how the tlb was processed, it just expects the component tree to be built.

but only the ActiveX controls can be referred to in code and/or have event procedures, so we don't really care, other than for the ProcedureNotUsed inspections.

@this Nothing says that they can't share an interface and each have distinct functionality.

idk if you can do this since there is aggregating to avoid the bugs

I need to look at that some more. I've only given it a casual read. I'm not sure I understand completely what is meant by "aggregating" in that context.

I really need to watch it in the debugger to see what's going on in memory.

Really i think only need to modify the rdc to accept both native amd special typeinfo. The typeinfo returned by the api are castable to normal typeinfo

[rubberduck-vba/Rubberduck] Stevefb created comment on issue #4176: Something ~Rubberduck~ ate my code, spit it out ....

> Feeling dumb. In the bottom left of the code window are 2 buttons, one of which limits the view to a single method...

@this Did our new build process obsolete issue #2789?

[rubberduck-vba/Rubberduck] Stevefb closed issue #4176: Something ~Rubberduck~ ate my code, spit it out ....

Hm that wasnt an issue for me prior to the change to build

Shld be able early bind without problem now. But definitely wasnt me who fixed it

I was thinking mainly of how the RD tlb is now compiled with modified MIDL. Does the installer register a tlb file, or is it still against the executable.

Installer writes to registry directly. Distributes both 32 and 64 bit tlb with a dll

The binding problem was due to RD being loaded in the same process that the call from LoadLibrary came from.

Awesome. I'll close it.

[rubberduck-vba/Rubberduck] comintern closed issue #2789: Referencing of RubberDuck.tlb causes indefinite Loading References

[rubberduck-vba/Rubberduck] comintern created comment on issue #2789: Referencing of RubberDuck.tlb causes indefinite Loading References

> This issue should be resolved with custom tlb registration.

Come to think of it it may br a side effect of splitting the vba api into its own project?

we might have to resort to a host-specific shape parse for the OnAction shapes, just like we'll need to collect ribbon and CommandBar items

Regardless, if LoadLibrary is loading a tlb that fixes it.

@ThunderFrame that wld be a use case for the IHostApplication. Add method call CollectVbaReference or something.

@ThunderFrame Crap. I always forget about the stupid ribbon.

@Comintern I have that one just about ready to go.... And then MS went and introduced a new ribbon last month

Oh yeah, the whole Team Foundation Excel BS?

the new "simplified" ribbon - theverge.com/2018/6/13/17457800/…

it's still undocumented AFAICT

I should put #2775 on my todo list while I'm in tlb mode too. That one bothers me for inexplicable reasons.

Did they actually change the xml schema?

@ThunderFrame Wow, they look so happy in that video. I wish my co-workers felt that way about Excel.

I already dislike it.

[rubberduck-vba/Rubberduck] comintern assigned comintern to issue #2775: COM reflection should resolve AsTypeNames for function return types as the alias identifier.

@this I assume they'll have to for other devs to take advantage. Right now, I assume the ribbon expands and shrinks as you switch tabs. yuk

@Comintern it's good to know the new ribbon has "speed and velocity"

last time I looked, animation in a productivity app was like having explosives in a childcare center.

I'll remember to duck.

TTGTB

night

@Comintern the main problem is that the TypeLib API works on special versions of ITypeLib / ITypeInfo that expose object parameters as IntPtrs in order to work around bugs in the VBE implementations.

As @this mentions, the TypeLib API also exposes the type info as ordinary ITypeLib / ITypeInfos so that you should, in theory, be able to just pass them on to your com collector or whatever (and avoid the VBE bugs).

[rubberduck-vba/Rubberduck] Vogel612 commented on RubberduckTests/Inspections/MemberNotOnInterfaceInspectionTests.cs of pull request #4207: Test for anonymous object access in With blocks. Closes #3343

@this will check that after work

[rubberduck-vba/Rubberduck] MDoerner created pull request #4208: Fix minor grammar issues to merge MDoerner/Rubberduck/FixMinorGrammarIssues into rubberduck-vba/Rubberduck/next

> This PR closes #4196 Moreover, it fixes the parser part of #3210 (Unfortunately, I messed up when amending commits so that the commit with the corresponding tests now has the wrong commit message.) The fix for the first issue is simply to make the leading whitespace in a LINE_CONTINUATION mandatory. The fix for the other issue is kind of a hack and I would welcome better solutions. I allowed line numbers and labels right after line continuations as well. This is less strict than the VBE,...

but it should not cause any problems. Then the problem is that there usually is whitespace after the LINE_CONTINUATION, which the VBE seems to count as part of the line continuation. (This is all part of the preceding endOfStatement.) So I added the trailing whitespace to the LINE_CONTINUATION unless it is followed by something looking like a line continuation, since consuming all whitespace in front of a line continuation breaks it. In addition, this PR makes all but the test projects...

dependent on the code analysis project to avoid failing builds due to a wrong build order.

[rubberduck-vba/Rubberduck] build for commit b997085e on unknown branch: 52.22% (target 0%)

[rubberduck-vba/Rubberduck] build for commit b997085e on unknown branch: AppVeyor build succeeded

@WaynePhillipsEA just to confirm my understanding is correct --- the other day I observed that I can compile a IDL file into a TLB file without a backing implementation. That can be then referenced in VBA and I can write code on it and have it compile. Obviously it can't run. The reason it can't is because at the runtime, VBA needs to access the CLSID/Interface registry in order to create the objects defined in the TLB, right?

(and it's those registry entries that we get the path to the implementing DLL)

[rubberduck-vba/Rubberduck] Vogel612 commented on RubberduckTests/Grammar/VBAParserTests.cs of pull request #4208: Fix minor grammar issues

[rubberduck-vba/Rubberduck] Vogel612 commented on RubberduckTests/Grammar/VBAParserTests.cs of pull request #4208: Fix minor grammar issues

@WaynePhillipsEA Thanks, that's good to know. The controls have been a PITA.

[rubberduck-vba/Rubberduck] comintern commented on RubberduckTests/Inspections/MemberNotOnInterfaceInspectionTests.cs of pull request #4207: Test for anonymous object access in With blocks. Closes #3343

@Comintern Interestingly there is no LongPtr anywhere in the TLB. The LONG_PTR is merely a typedef. On my 32-bit VBE7, it's for long. I imagine that on 64-bit, it'll be longlong.

[rubberduck-vba/Rubberduck] comintern synchronized pull request #4207: Test for anonymous object access in With blocks. Closes #3343

[rubberduck-vba/Rubberduck] [codecov[bot]](github.com/apps/codecov) edited comment on pull request #4207: Test for anonymous object access in With blocks. Closes #3343

@this Yep. The typedef looks like a hack they used when they put in 64 bit support.

Maybe not a hack. A cheap and easy work-around maybe.

right and we don't have LongLong readily available, either.

but I wonder how did they get that working in Access.

What I can't figure out is why they exposed it like this:

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

... instead of matching the intended name.

presumably because they have to compile 2 versions of TLB

that way, they only change one typedef without touching others?

In 32-bit Access 2016 with support for 64-bit integers we can do this....

@MathieuGuindon We really need the precompilation pass. Precompiler directives can make code unparsable quite easily.

Public Sub Foo()
    Dim rs As DAO.Recordset
    Set rs = CurrentDb.OpenRecordset("SomeTable")

    Dim v As Variant

    v = rs.Fields("SomeBigNumber").Value

    Debug.Print v           'Returns 12345678901234567
    Debug.Print VarType(v)  'Returns 20
    Debug.Print TypeName(v) 'Error 458 - Variable uses an Automation type not supported in Visual Basic
End Sub

and from VARTYPE enumeration:

> vbLongLong 20 LongLong integer (Valid on 64-bit platforms only.)

Btw, using binary logical operators on built in compilation flags yields exactly what you would expect, by coincidence.

@M.Doerner oh that's right, we need it to strip the "dead code"!

Yes

Or rather, hide it.

which is a fat big lie. 32-bit VBA apparently can handle 64-bit integers but we can't directly declare variables like so.

@this Oh that part makes perfect sense. It just looks like the VBA team added the support, but the MFC team named it in the tlb. I would have expected it to be named int64 LongPtr;

[rubberduck-vba/Rubberduck] build for commit 5475718d on unknown branch: AppVeyor build succeeded

[rubberduck-vba/Rubberduck] [codecov[bot]](github.com/apps/codecov) edited comment on pull request #4207: Test for anonymous object access in With blocks. Closes #3343

[rubberduck-vba/Rubberduck] build for commit 5475718d on unknown branch: 52.23% (target 0%)

@Comintern oh i follow now. Yeah I don't know how they get LongPtr.

@MathieuGuindon Didn't we discuss sending them to their own parser streams at one point?

@M.Doerner given that the built-in flags are short with values of either 0 and 1, Not 1 would be evaluated as -2. Given this:

Public Sub bar()
    #If VBA7 And Not VBA6 Then
        Debug.Print True
    #Else
        Debug.Print False
    #End If
End Sub

it yields False on a VBA7 host.

which is technically incorrect because on a VBA7 host, both VBA7 and VBA6 are supposed to have 1 as their value.

It only happens that there's overlap between expected logical and bitwise operation, I think, but treating bitwise as logical wouldn't be always correct in all cases.

@MathieuGuindon FWIW it would be great if there was a support for creating more than one parse tree given a different set of compilation directives.

I forget, is VB6 support released?

not really - it's in pre-releases, though.

there's few issues mansallen wants to fix before making it generally public

@this mainly making sure libs resolve fully, then its good to go. gonna try @comintern's latest fixes tonight.

OK - just noticing that we need to add registry entries to the Build Process wiki, and installing wiki (assuming the installing wiki still needs registry entries)

yep. I think the installer needs HKCU entries for VB6 too - @this could you take a look when you get time?

(or maybe it was the deployment project scripts, I forget)

github.com/rubberduck-vba/Rubberduck/blob/next/…

ah ok, you got it already :-)

but the debug is missing their entries....

github.com/rubberduck-vba/Rubberduck/blob/next/…