NVM, let me check something just to make sure I'm confused.

[rubberduck-vba/Rubberduck] transistor1 commented on issue #1704: Releasing COM objects.

> BTW... Mike Rosenblum is a great source for this. He has written a ton of stuff on this topic. Heres one stackoverflow.com/a/159419/864414

Yep, I'm confused.

Why aren't Initialize &c. being picked up as events?

What does Class_Initialize reference?

nothing. these two are hard-coded

Shouldn't it reference something?

How is it fired?

Through the VBE?

by the VBA runtime

OK.

when you New up and instance and when the runtime kills the instance, respectively

How should I get the user form events?

They're on this interface:

Hard code them too?

Interface IClassModuleEvt;
GUID = {FCFB3D21-A0FA-1068-A738-08002B3371B5};
  function Initialize: HResult; stdcall;
  function Terminate: HResult; stdcall;

It should always be implemented by:

CoClass Class;
GUID = {FCFB3D2A-A0FA-1068-A738-08002B3371B5};

oh, so we could add IClassModuleEvt to the implemented interfaces of all class modules and forms

right? and forms?

[rubberduck-vba/Rubberduck] tcostin opened issue #1719: Incorrect COM object handling in VBEEditor/VBEHost/HostApplicationBase.cs

> Intuitively it makes sense to consider the Application object an unmanaged resource (it's supposed to be a COM object, which is definitely unmanaged), but that is actually incorrect. The Application object is actually a special type of managed object called a RCW (runtime callable wrapper), which has its own finalizer. Hence it is actually a managed resource for HostApplicationBase, so Marshal.ReleaseComObject should only be called if disposing is true (and hence HostAppBase doesn't really

@Duga - After this weekend I know more than you do about that.

I'm dizzy

I'm so F'n tempted to reply with "can't reproduce" on that one.

Everywhere you look, there's a different approach. Feels like googling for a frakkin repository pattern implementation

@Comintern I trust you, I know you'll just do what's right.

Again, Visio would seem to be the most dev friendly type library... Visio's Document object exposes a ProgID property.

I really don't think it matters at all. There's a 1 to 1 relationship with references created in the ctor and references released in dispose. if (Application != null) is exactly the same thing as bool disposing - the syntax isn't exactly the same as your canonical Dispose block, but it has the exact same effect.

@comintern I think you want ?TypeName(Application.VBE.ActiveVBProject.VBComponents("Sheet1").Properties("Sa‌​ved").**Value*)*

@ThunderFrame - Probably, didn't turn out to be helpful though. In other news, I can get a raw IDispatch out of a VBComponent - if I can get an IUnknown, we can just ask it if it's a Workbook.

huh? That was valid markdown?! Maybe *? is special?

@Comintern that's what we actually need!

> knock-knock! yes? - are you a workbook?

[rubberduck-vba/Rubberduck] ckuhn203 commented on issue #1704: Releasing COM objects.

meh, I think the property hash is going to be the only way to get the base class of a document, unless we resort to host-specific tests.

Happy for @Comintern to prove me wrong

@ThunderFrame you need a hat

an edible one, preferably ;-)

sure, mark me down for that

OK, I'm 101% confused.

btw - Did Outlook run tests for you?

@ThunderFrame It did :)

[rubberduck-vba/Rubberduck] comintern commented on issue #1719: Incorrect COM object handling in VBEEditor/VBEHost/HostApplicationBase.cs

@RubberDuck Time to eat your hat.

> I'm not sure how I see this as an issue other than just readability . if (Application != null) should be operating in the same manner as if (disposing). Also, not sure how this could leak an Application object out to be released elsewhere in code - it exposes the name of the application and the run method. There's also a one to one relationship between creations and releases, so it isn't clear how this could "curdle the .Net reference count". At worst it's unnecessary code.

@RubberDuck @Hosch250 @ThunderFrame FWIW I have a draft on Rubberduck News to announce the beta, titled "You're going to eat your hat"

@Mat'sMug @Comintern Just doing Workbook/Worksheet isn't enough.

Outlook is Application.

Word is Document.

@Hosch250 - That's why I'm trying to see if I can get the VBComponent to spit out its implemented interfaces. If we can do that, we can just match them against collected ones and find the appropriate CoClass.

OK.

Excel is the only one that crashes on close. PP, Word, and Outlook do not.

@Comintern egg-zac-tlee

@Comintern This bit on COM and threading might be interesting (you probably already read it, though): en.wikipedia.org/wiki/Component_Object_Model#Threading

s/read/wrote/

;-)

He wrote that article?

OK...

LOL, no. I think I might have indirectly referred to that earlier though. .NET looks the other way on the STA threading contract when it's convenient though.

[rubberduck-vba/Rubberduck] LNow commented on issue #1704: Releasing COM objects.

[rubberduck-vba/Rubberduck] LNow commented on issue #1704: Releasing COM objects.

[rubberduck-vba/Rubberduck] retailcoder commented on issue #1704: Releasing COM objects.

@Duga or am I thinking this wrong?

@Mat'sMug Should these events be built-in?

which?

Class_Initialize, &c.

yes

they're not user-defined, therefore they're built-in ;-)

Should this be two tests?

yep

    [TestMethod]
    public void ClassModuleEvent_IsEvent()
    {
        // arrange
        var input = @"
Private Sub Class_Initialize()

End Sub";
        // act
        var state = Resolve(input, vbext_ComponentType.vbext_ct_ClassModule);

        // assert
        var declaration = state.AllUserDeclarations.Single(item => item.IdentifierName == "Class_Initialize");

        Assert.AreEqual(DeclarationType.Event, declaration.DeclarationType);
        Assert.IsTrue(declaration.IsBuiltIn);
    }

and it passes? o.O

@Hosch250 wait a minute, you're confused: the declaration Sub Class_Initialize() is a user declaration with a declaration type "Procedure"

It needs to resolve to an event, doesn't it?

no

it needs to resolve to a handler for a built-in event

the event being ClassModuleEvt.Initialize

I wish you would have told me that a couple hours ago...

I thought we had that all cleared up already

OK, then I'll go look at the inspections again.

Maybe instead of checking if the parent is an event, I need to check if it is an event or event handler.

back to square one: is ClassModuleEvt made a "base type" of every user class module? If not, the resolver has no idea about these events, and the only way an inspection can tell, is by hard-coding Class_Initialize and Class_Terminate members as "special cases"

Well, how do I code them as special cases?

I'm not real sure we can, unless we do it in the event-handler-finder thing.

any method in a class module named Class_Terminate or Class_Initialize cannot be anything other than a handler for these built-in events

Even if they have parameters?

Those ones don't, but the user form ones do.

Like, what if the parameter types don't match?

won't compile

Oh right, the VBE doesn't allow overloads.

VBA doesn't.

@Mat'sMug What about my report?

Also, are you still planning on releasing tonight?

ugh. right. printing

@Hosch250 not sure

OK, I'll stick these as special cases in the event-handler-finder.

that should work until we figure out something better. I'm pretty sure they used to be special-cased in the inspection though

Got it.

@Mat'sMug No, they won't.

The inspection uses the built-in event handler finder.

ah, that's what changed then

makes sense

FWIW, it would actually need special handling either way you approached it. That interface information I put up earlier is in a non-standard typelib (resource 3), so it would have to be specifically extracted from vbe7.dll to be read.

well, it's just two members, might as well hard-code them the simple way ;-)

@Mat'sMug Plus the user form ones...

            // class module built-in events
            var classModuleHandlers = declarations.Where(item =>
                        item.DeclarationType == DeclarationType.Procedure &&
                        item.ParentDeclaration.DeclarationType == DeclarationType.ClassModule &&
                        (item.IdentifierName == "Class_Initialize" || item.IdentifierName == "Class_Terminate"));

            // user form built-in events
            var userFormHandlers = declarations.Where(item =>

That should fix it.

Private Sub UserForm_Initialize()

End Sub

Private Sub UserForm_Terminate()

End Sub

yeah that should do it

temporarily at least

@Hosch250 actually these methods will always only ever be "UserForm_[EventName]"

@Mat'sMug Yeah, I realized that for the Nth time just now.

while _Click could be a handler for a button/control click

I used OneNote to extract the text out of a picture of the event names, and forgot to adjust them.

OK, Param Not Used is fixed.

Procedure Not Used is not.

Proc not used fixed.

awesome

awesome hat-sauce

TTQW

[Hosch250/Rubberduck] Hosch250 pushed commit e09a0735 to InspectionBugs: Fix a couple inspections

[Hosch250/Rubberduck] Hosch250 pushed commit 47ca5446 to InspectionBugs: Fix a few more inspections

@ThunderFrame Can an event parameter name be changed?

Or do I need to make that not complain as well?

@Hosch250 - Yep, you can change the parameter names. What is it complaining about?

X.

In the mouse ones.

My instinct would be to suppress that warning if it matches the parameter from the typelib. No sure what that would involve though.

Not too much.

[Hosch250/Rubberduck] Hosch250 pushed commit f32c4994 to InspectionBugs: Add a few tests

[rubberduck-vba/Rubberduck] Hosch250 created pull request #1720: Inspection bugs to merge Hosch250/Rubberduck/InspectionBugs into rubberduck-vba/Rubberduck/next

@Mat'sMug I think I've got the release notes pretty good.

Cool, LMK where they are, I'll review/edit and... PR whatever you've got, I'll bring it in and run a local build and then we'll setup a TeamViewer session and build that baby

My OneDrive. I linked them here a while ago (well, several weeks).

I have them in a Word doc.

Post them in a sec--uploading my report.

Ok

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

onedrive.live.com/…

That's a view link.

You can either copy it and email me a new one or I can email you an edit link.

Just be sure to only use features that I can replicate with markdown.

lol

@Hosch250 are you going to do that?

No.

Ok

I just realized that is a lot more than I initially thought.

[rubberduck-vba/Rubberduck] retailcoder merged pull request #1720: Inspection bugs from Hosch250/Rubberduck/InspectionBugs into rubberduck-vba/Rubberduck/next

[rubberduck-vba/Rubberduck] Hosch250 pushed commit 3f7c3cd7 to next: Correctly check param-not-used for events and library procedures/functions

As a matter of fact, until we get the declarations out (we don't get these ones, AFAICT), I don't even know what the original name is.

[rubberduck-vba/Rubberduck] Hosch250 pushed commit e09a0735 to next: Fix a couple inspections

[rubberduck-vba/Rubberduck] Hosch250 pushed commit 47ca5446 to next: Fix a few more inspections

[rubberduck-vba/Rubberduck] Hosch250 pushed commit f32c4994 to next: Add a few tests

[rubberduck-vba/Rubberduck] retailcoder pushed commit 7123cac1 to next

@Comintern What would it take to get the event declarations for these event handlers from the dll?

We have them already. The handler declarations arent linked to them yet though

I couldn't find them in the list.

Hmm, did I miss some events?

Wait the ClassModuleEvt ones? These we don't have

But form events should be picked up as such, as long as there's a form in the project

I'm not sure - it might need to be pulled directly from the dll resource. I'll check if there's an API to read a non-default typelib.

Form ones too, AFAIK.

Checking, we might have them.

What dll are those ones in?

ActiveX controls in document-type ActiveX containers have events handlers too, but we're not collecting the ActiveX controls.... yet

@Hosch250 Don't forget that the UserForm itself has event handlers for _Click etc.

@ThunderFrame Those are the ones I'm talking about.

Meh.. at least we have the option to @Ignore individual inspection results now

[rubberduck-vba/Rubberduck] build for commit 7123cac1 on next: AppVeyor build succeeded

I think we have them.

Huh.

Why aren't the form events tied to them?

@ThunderFrame I'm expecting those to be already picked up now

@Hosch250 see if you can find out :-)

@Mat'sMug Going to release, or no?

Not if things I thought were working are actually broken....

OK.

Supper time, I'll work on this later.

np. I should eat too I guess

@Mat'sMug What was the Outlook problem? Was it the security settings?

Didn't get to it yet, but probably. I'll make a last-minute change to the comments in the test module template if that's the case

Also, I create and destroy the CommandBar and Control every time, for Outlook Unit Tests. That's twice for every module, and 3 times for every Test. I suspect that is slowing down the runtimes of the tests. I could perhaps create a temporary button, and re-use it for all callbacks

Yep

What threads get created other than the parser ones? I think I got all of the parser threads to close by just forcing a GC.WaitForPendingFinalizers. Still have 2 running threads on close after that those.

Inspections?

It's all I can think of though. Oh wait, are keyhooks on their own thread?

Ah, yes.

@ThunderFrame They went real fast for a single module here.