Anyway, I think everything is in place now.

RELOAD!

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

[Minesweeper] Games Played: 80, Bombs Used: 49, Moves Performed: 8601, New Users: 18

So, I can finally push my current PR this weekend.

Nice. However, I don't follow how code could be broken that still compiles.

It throws at runtime.

Public Sub Bar()
    Dim cls As Class1
    Dim baz As Variant
    Set cls = New Class1
    baz = cls(0)
End Sub

Compiles without default member on Class1.

However, it raises error 438 on runtime.

that woudl require you to know that htere's a default member

but we know that already via parsing, don't we?

it is annoying that VBIDE doesn't do that work. It seems obvious.

That is why my next PR will includes a DefaultMemberRequiredInspection.

Along with ValueRequiredInspection and ProcedureRequiredInspection.

:+1:

Mat will love that, I"m sure

We already have the inspections dealing with object assignments and passing of object arguments.

OK, I tried whether passing a subclass with a default member works; it does not.

So, the only reason why this is permitted is probably that an extendable interface could actually have an extended default member.

if i'm not mistaken, all VBA types are non-extensible

Yes, it would have to come from some library.

i can see why VBIDE can't cover that, but I guess they decided it was too expensive to check for non-extensible types

Anyway, there is no reason why you should build a mechanism to add an extended member with that flag.

Well, TTGTB.

night!

@this I've been wondering for a while, from the sidelines, whether this is a real restriction or an artifical one. Can VBA types be extended through extraordinary measures?

their type infos have the nonextensible flag set

Hackable?

we don't have access to the type info generation so we can't hijack that.

and besides, I have no idea how you'd even hijack it.

It's all COM underneath though...

I guess by implementing the dispatch method accordingly

but as noted, VBA's type infos' Dispatch don't really work anyway

sorry i mean IDispatch::Invoke

(I have no expererience with the specifics, just rubberducking...)

there's better ways, though. Aggregation might work around that restriction, for example.

What's the difference (at the COM level) between extension and aggregation? I feel like I'm missing a book (or two!)

um, I have no idea how extension work exactly.

for aggregation it's basically just you slapping on another interface on top of another interface

and then you can decide whether to forward the calls from your slapped-on interface to the inner interface or do something else

i have to assume that for extension to be even a thing, you must somehow enable the IDispatch::Invoke to work when given some unknown member

since obviously, extended members can be only late-bound.

ok, this is annoying me....

{Rubberduck.VBEditor.ComManagement.TypeLibs.TypeInfoFunctionCollection}
    Count: 5
    _count: 5
    _parent: {Rubberduck.VBEditor.ComManagement.TypeLibs.TypeInfoWrapper}
    Results View: Expanding the Results View will enumerate the IEnumerable
asm.GetTypes()[5].GetMethods()
{System.Reflection.MethodInfo[4]}
    [0]: {System.Reflection.RuntimeMethodInfo}
    [1]: {System.Reflection.RuntimeMethodInfo}
    [2]: {System.Reflection.RuntimeMethodInfo}
    [3]: {System.Reflection.RuntimeMethodInfo}

I gave you 5, you give me 4. C'mon, let's count better than that.

Wow... so much to learn...

"Type 'Class2' is invalid and may only be partially converted."

sigh

i might have to build the whole thing myself....

@this Sorry, context?

this is me trying to convert ITypeInfo into System.Type

which I need for mocking

it's failing to convert one of the type because the signature contains a reference to another library

Public Function Exc(foo As Excel.Application) As Long

In the ITypeInfo, it can describe the function just fine. It even correctly references the Excel.Application type

ok...

But when I use the built-in .NET's converter, it goes "wut? Imma gonna skip that one, k?"

thus, I come up a method short in the System.Type's representation of the VBA Class2 type.

meaning, I cannot mock the Exc method.

I originally did this using Marshal.GetTypeForITypeInfo()

I just tested this with TypeLibConverter.ConvertTypeLibToAssembly (which gave me more data).

This also includes a sink to let me to resolve the references.

It does not even try to call that sink to resolve the reference to Excel type library.

how lazy is that!

Is it a type buried in Excel.Application?

Excel.Application is the type

sorry, I mean you're trying to mock Excel.Application, which is huge... could it be a resolution failure somewhere in the Excel OM?

no no no

(Bear in mind, I know nothing of this, just tryna rubberduck)

this is mocking Class2

which uses Excel.Application type as a parameter

hmm.

I should check using a different type just in case.

sorry, it's ttgtb. good luck!

bye!

[rubberduck-vba/Rubberduck] Vogel612 deleted comment on issue #3347: Holy RAM, batman! (Out of memory errors and excessively high memory usage)

> AFAIK we'd already dropped Vista support when upgrading the .NET Framework to 4.6.2 a few months back

That'd be me misremembering stuff, apparently

why do you taunt me so, Microsoft? You give me an assembly builder but you won't let me redefine anything in it?

Are we aware we could track duplicates issues in GB? Appears it’s an issue outstanding github.com/isaacs/github/issues/1659

@MathieuGuindon Check email for link. Lower volume too.

lol!

Not sure if that's a good laugh or not ;p

My guess was the camera was pointed down a bit too much. :shrug: Can't learn if I don't make mistakes.

Round2 will be juggling rubber duckies.

Enjoy the weekend all. Get caught up on projects and sleep.

@IvenBach haha nah it's awesome you did that! have a great weekend too!

[rubberduck-vba/Rubberduck] retailcoder edited wiki page VB_Attribute Annotations

[rubberduck-vba/Rubberduck] retailcoder synchronized pull request #5128: Assignment not used

[rubberduck-vba/Rubberduck] build for commit f0571211 on unknown branch: AppVeyor build failed

BUILD FAILURE!

Finally had the idea of derivatives :click: for what I’m studying. :+1: for making studying easier.

Keep at it ducks. Everntuskly you figure it out. Much late and sleep is lacking “<\iven>

[rubberduck-vba/Rubberduck] wade1990 forked us into wade1990/Rubberduck

@mansellan FTR: please do call me out on my BS on GitHub. I'm just winging it, and it's better if you just speak up :)

@Vogel612 lol ok :)

[rubberduck-vba/Rubberduck] MDoerner created pull request #5146: Inspections for failed default member resolutions to merge MDoerner/Rubberduck/FailedLetCoercionOnObjectInspection into...

rubberduck-vba/Rubberduck/next

> This PR introduces the three new inspections VariableRequiredInspection, ProcedureRequiredInspection and DefaultMemberRequiredInspection that report failed let coersions, failed procedure coercions and failed indexed default member resolutions, respectively. In all three cases, the VBE compiler does not complain, but we get a runtime error. Apart from the necessary changes to collect the failed resolutions, some corrections are intoduced to the logic of the reference resolver, in...

particular in the IndexDefaultBinding. (We actually check for the compatibility of the number of arguments.) Collecting the failed resolutions also allowed to heavily simplify the ObjectVariableNotSetInspection.

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

[rubberduck-vba/Rubberduck] MDoerner synchronized pull request #5146: Inspections for failed default member resolutions

[rubberduck-vba/Rubberduck] MDoerner edited pull request #5146: Inspections for failed default member resolutions

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