Oh wait - I bet it was one of the !foo.Guid.Equals(Guid.Empty) asserts.

VBA doesn't register anything, so they'd probably? be empty.

Indeed yes

RELOAD!

[rubberduck-vba/Battleship] 1 commit. 1 addition. 1 deletion.

[rubberduck-vba/Rubberduck] 4 issue comments.

Now, it crashes in the ComCoClass ctor.

Hmmm... Maybe choking on the ComProject.KnownTypes.TryAdd(attribs.guid, intface); line?

You are using waynes typelib/typeinfo, not originals right?

Doesn't TryAdd throw with a null key?

Yes, I am using Wayne's typeLibs cast to ITypeLib.

ok

I had the false hope that the ComProject could simply consume them.

Hmm... MIght want to try it as a ComModule - that would skip all of the implemented interface stuff and only grab fields.

the thing s that VBA dont adhere to conventions (like providing a guid) since its for its internal consumption.

Right.

@M.Doerner Can you push to your fork?

I already did that.

so the com collector needs to be a bit more lenient either way i think

Will push my first steps regarding the type kind as well in a second.

OK, gimme a minute and I'll take a look.

Is this in the CacheUserComProjects branch?

I just ignored the asserts with no-op for the VBAClasses.

I get the declarations for all standard modules in the locked project.

27 days without a Rubberduck blog post.. I'm guessing the 2.3 release will be blogged, to break the drought?

I.e. the assert will probably have to go and we have to see what is the right approach for VBAClasses.

@ThunderFrame oh yes, it definitely will get a blogpost

github.com/MDoerner/Rubberduck/blob/CacheUserComProjects/…

and if it's only a copy of the release notes

pushed it ^^

TTGTB

OK, I'll let you know what I find.

Sleep well :)

^

[rubberduck-vba/Battleship] bruglesco starred us

Interesting. The VBAProject does have a GUID.

Oh wait, that's not the project - it's one of the document classes.

ThisWorkbook has a GUID of {38ba8591-5eae-465f-a8a2-f06cfee7e95f}.

And it has one implemented interface: {000208da-0000-0000-c000-000000000046}, which is _Workbook...

Ummm... score?

Oh, snap.

> The program '[4824] EXCEL.EXE' has exited with code 255 (0xff).

Home Time.

OK, found the crash. If I process TKIND_VBACLASS as a ComInterface, it's crashing Excel on info.ReleaseTypeAttr for the _Workbook interface. Everything up until that works just fine.

It's when the using block on line 91 of ComInterface exits.

Faulting application name: EXCEL.EXE, version: 15.0.5085.1000, time stamp: 0x5bcb78d4
Faulting module name: ntdll.dll, version: 10.0.17134.376, time stamp: 0x60d78cf9
Exception code: 0xc0000374
Fault offset: 0x00000000000f4d7b
Faulting process id: 0x21ac
Faulting application start time: 0x01d481fe7022d423
Faulting application path: C:\Program Files\Microsoft Office\Office15\EXCEL.EXE
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: ad6b68af-d060-4a5d-bcf5-e8e28e7481bf
Faulting package full name:

@Comintern Pinging @WaynePhillipsEA for possible insights in the typelib api crash

Yeah, I'm not sure what the deal is there - that's passing the function call back to the native object AFAICT.

Is it similar to the one with cco library?

looks awfully similar

It's literally just this:

    void ComTypes.ITypeInfo.ReleaseTypeAttr(IntPtr pTypeAttr)
        => target_ITypeInfo.ReleaseTypeAttr(pTypeAttr);

@this The exception is just generic heap corruption, so I'm not sure there's much help there.

Yes but with cco we were using native typeinfo and crashing on releasing typeattr, iir

It should just be using the same TypeInfo that you'd get from LoadLibrary.

BBL

Yep

lol googled releasetypeattr crash, guess who got first hit

@ThunderFrame Yo bro! :)

Congratulations @IvenBach so your sanity is your own measure of wisdom:)

Huh?

@PeterMTaylor I guess I'm sane.

Definitely not "normal" by anyones measure though.

However a good one.

Hiya

8 more stars will break the 700 barrier.

howdy

with regards to the crash, first test if my Document() routine causes a similar crash

Hi @WaynePhillipsEA I think @Comintern had a question/bug for the ITypeLib code

the document routine goes through all implemented interfaces etc, and will also call the GetTypeAttr/ReleaseTypeAttr on them all, so if it should also show up there.

if it doesn't show up in the Document routine, then you've probably already corrupted the heap elsewhere, and the error is simply manifesting itself at the ReleaseTypeAttr point in time

hey @ThunderFrame

@this my instinct says it's likely a double release of something... but not necessarily a TYPEATTR

TKIND_VBACLASS is essentially a TKIND_INTERFACE, from what I remember. We should probably patch that value up in the TYPEATTR returned by TypeInfoWrapper since it's likely no consumers will care about the undocumented TKIND_VBACLASS value.

I'll try to pop back later when you're around

Oops, if I could read, I'd read, I'd see that you found the ping already

[rubberduck-vba/Rubberduck] alexandruhapco starred us

@IvenBach There's a barrier?

If anything, it's a threshold. RD has no barriers!

We'll, other than the freeze ahead of 2.3 release... And then AvalonEdit here we come....

@Comintern IIRC, the VBA SDK PowerPoint makes mesntion of host-specific classes that aren't document modules. But there's not much else to go on

@ThunderFrame hope you can sleep well again mate.

@Comintern @this See slide 15 in archive.adaic.com/ase/ase02_01/bookcase/sprpts/…

that slides is cool and easy for me to grasp the tech. thanks for that.

[rubberduck-vba/Rubberduck] ThunderFrame edited wiki page VB, VBA and VBE References

^ I added the Tech Ed link to the wiki.

@PeterMTaylor thanks. Breaks out the morphine...

@ThunderFrame hows your pace lately?

Nice weather. Family was in the pool last weekend. I'm sleeping a lot, just not at night!

@ThunderFrame pouring with rain it was last night but easier on us tonite. Still making excuses not to cut our grass currently five weeks high.

@ThunderFrame yep just little hectic weatherwise.

[rubberduck-vba/Rubberduck] ThunderFrame created comment on issue #3214: No Way to Dock Tool Windows after Uncheck Dockable (even after Restart)

[rubberduck-vba/Rubberduck] ThunderFrame edited comment on issue #3214: No Way to Dock Tool Windows after Uncheck Dockable (even after Restart)

[rubberduck-vba/Rubberduck] ThunderFrame edited comment on issue #3214: No Way to Dock Tool Windows after Uncheck Dockable (even after Restart)

Happy Thanksgiving!

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #4225: Adds Add Predeclared Class Module Command

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

BUILD FAILURE!

derp forgot to commit the tests

[rubberduck-vba/Rubberduck] bclothier created comment on pull request #4225: Adds Add Predeclared Class Module Command

> Introduced the foundation for a template system to allow future enhancements providing users with a way to customize the built-in templates and user-defined templates. The main difference with a built-in template is it contains a resource file to provide the code and metadata and can be localized. User-defined templates is currently not lit up but it shouldn't be too hard to light it up. At the moment, there is no UI around the template but the predeclared class now is a template and allows fo

[rubberduck-vba/Rubberduck] bclothier commented on Rubberduck.Core/UI/CodeExplorer/Commands/AddComponentCommand.cs of pull request #4225: Adds Add Predeclared Class Module Command

[rubberduck-vba/Rubberduck] bclothier added label enhancement to issue #4533: File management in RD

[rubberduck-vba/Rubberduck] bclothier added label technical-debt to issue #4533: File management in RD

[rubberduck-vba/Rubberduck] bclothier opened issue #4533: File management in RD

[rubberduck-vba/Rubberduck] bclothier added label up-for-grabs to issue #4533: File management in RD

[rubberduck-vba/Rubberduck] bclothier added label difficulty-02-ducky to issue #4533: File management in RD

[rubberduck-vba/Rubberduck] bclothier added label development-issue to issue #4533: File management in RD

[rubberduck-vba/Rubberduck] bclothier project card. Enough said.

[rubberduck-vba/Rubberduck] bclothier edited issue #4533: Filesystem management in RD

[rubberduck-vba/Rubberduck] bclothier removed label PR-Status: WIP from pull request #4225: Adds Add Predeclared Class Module Command

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #4225: Adds Add Predeclared Class Module Command

[rubberduck-vba/Rubberduck] build for commit 992a7763 on unknown branch: AppVeyor was unable to build non-mergeable pull request

BUILD FAILURE!

wtf

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #4225: Adds Add Predeclared Class Module Command

my wtf was more that it'd complain about a conflict for Thunderframe's branch

i'm not pushing to RD's next; but to Thunderframe's next.

oh

@Duga hmm ... I'm not sure I like the idea of an IPersistencePathProvider. This smells of a layer of indirection too much

Why not just an IPersistancePath?

right. let's keep Provider lingo for factory-ish stuff.

@MathieuGuindon Is there some mixed localization in the bottom screenshot on this answer?

yeah. I never figured out wth I get some French resources with English selected. OS is in French.

(at work)

if I change RD to French then everything is French

Huh. That's bizarre.

very

Caching?

@Vogel612 I was not sure if it's possible to have different path.

no, it's very consistent

yet all InspectionResult strings are in the same .resx file, so... them being in ..oh wait a minute

For one thing, we have the %APPDATA%\Rubberduck; but there's also the install directory, too. And if we decide we want to manage the temporary files in the %TEMP%, then it makes sense to have one place to get those path?

@this If we're going to refactor the RD folder, this might be a good time to add per-host logging.

looks like one of the resource files isn't getting its culture set

the "La variable" part is very likely not in the same .resx file as the rest of inspection result resources

Hmmm... is that done by the build, or by matching the name with the localization?

@Comintern the "provider" lets you create a new path with a folder specified, so you don't have to worry about the subfolders.

it's done explicitly here

uh oh

I added a new template resource

so I assume I have to add a line there

if it's to be localized properly, right?

yes

ok will remedy

and I think we need a better approach here

could reflection help?

[rubberduck-vba/Rubberduck] MDoerner created comment on issue #4533: Filesystem management in RD

> Note that PR #4444 will introduce a file handling interface.

gtg

^ was just about to suggest reflecting it.

I agree w/ reflecting. It should be one time cost anyway

and if I forget, others'll, too.

should I go ahead and hack it up just for now? or will we be fixing this generally?

May as well. I'm not sure what other general fixes we'd do there.

k

at least i'll add a TODO while i'm there

so we know this is in need of cleaning up

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #4225: Adds Add Predeclared Class Module Command

if I can get my stupid home desktop to realize it does have a wifi connection, I'll include it in my bugfix PR

Just so it is clear, we get the build failures because pushing to ThunderFrame's next automatically synchronizes the PR.

(or, feel free to push to that branch)

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

ugh. I think the GH's merge went the wrong way w/ the xaml file.

[rubberduck-vba/Rubberduck] retailcoder opened issue #4534: Resource/resx-generated classes are hard-coded in App.cs

Anyone there program in js or understand of heroku?

[rubberduck-vba/Rubberduck] retailcoder added label bug to issue #4534: Resource/resx-generated classes are hard-coded in App.cs

[rubberduck-vba/Rubberduck] retailcoder added label difficulty-01-duckling to issue #4534: Resource/resx-generated classes are hard-coded in App.cs

[rubberduck-vba/Rubberduck] retailcoder added label technical-debt to issue #4534: Resource/resx-generated classes are hard-coded in App.cs

[rubberduck-vba/Rubberduck] retailcoder added label up-for-grabs to issue #4534: Resource/resx-generated classes are hard-coded in App.cs

[rubberduck-vba/Rubberduck] retailcoder added label good first issue to issue #4534: Resource/resx-generated classes are hard-coded in App.cs

[rubberduck-vba/Rubberduck] retailcoder commented on Rubberduck.Core/App.cs of pull request #4225: Adds Add Predeclared Class Module Command

@adailtonmoraes wrong room? we do C# here, this is the "war room" of Rubberduck, a VBIDE add-in OSS project :)

[rubberduck-vba/Rubberduck] retailcoder commented on Rubberduck.Resources/Templates.resx of pull request #4225: Adds Add Predeclared Class Module Command

[rubberduck-vba/Rubberduck] bclothier commented on Rubberduck.Resources/Templates.resx of pull request #4225: Adds Add Predeclared Class Module Command

[rubberduck-vba/Rubberduck] ThunderFrame edited wiki page VB, VBA and VBE References

[rubberduck-vba/Rubberduck] ThunderFrame edited wiki page VB, VBA and VBE References

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

That references page is now a very thorough and robust list of links that should get anybody up to speed with VBA.

@ThunderFrame thanks for that :)

^^^

^^^^

funny we were talking pretty much exactly about this just yesterday

Has Lippert been lurking here...?

@MathieuGuindon nothing that hasn't been posted in here before, but good to have it all in the wiki.

@Comintern I don't think so, but now I'm starting to think someone from here has been lurking over there and I've only seen the connection 20 hours later because I'm that slow to connect dots :)

Still, none of those links reference the NBSP variable name feature, so this chat's history is probably the best repository of VBA knowledge, anywhere.

That explains a lot of my search results. :-D

@Comintern Not sure whether we should be proud or sad that we're also the first hits whenever googling anything about problems with COM

wonders how many hits the transcript is getting from random VBA researchers

I think VBA get very few hits.

@this Both, of course.

because we're dwarfed by other sources (e.g. SO). But with COM.... There's Hans, and then there's us.

^

^^

still painstakingly restoring the original xaml with changes --- anyone knows why we'd not have MinHeight originally? github.com/rubberduck-vba/Rubberduck/pull/4225/…

shouldn't that just be Height?

Does that prevent it from collapsing if the Visibility get set to false?

shouldn't

If it was Height originally there'd be a deleted line

this is only an addition without corresponding update

it's probably collapsing without child content

huh

OK closer look, it shouldn't do anything - the row definition is a hard 20 height.

in that case i'll chuck it out

[rubberduck-vba/Rubberduck] Vogel612 edited issue #4534: Resource/resx-generated classes are hard-coded in App.cs

another bug bites the dust

I love those giant msgboxes from CW

esp how they've hidden the OK/Cancel out of the sight

[rubberduck-vba/Rubberduck] retailcoder created label reflection

[rubberduck-vba/Rubberduck] retailcoder added label reflection to issue #4534: Resource/resx-generated classes are hard-coded in App.cs

@Duga I think you should have called it preening with a mirror

lol

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #4225: Adds Add Predeclared Class Module Command

^ much better - some weird whitespace but nothing crucial has been lost.

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

@WaynePhillipsEA I had wondered about that - I did not have much luck in finding any documentation indicating whether there'd be other methods that might cause the TYPEATTR or its underlying object to be freed before we get to the ReleaseTypeAttr().

That said, I ran ?Application.VBE.Addins("Rubberduck.Extension").Object.DocumentAll and did not get a crash.

I get the feeling that we are doing something wrong for interfaces. Testing with the VBA classes case not implemented, I do not get a crash.

Just some asserts that can be ignored.

timely

[rubberduck-vba/Rubberduck] bclothier commented on Rubberduck.Resources/Rubberduck.Resources.csproj of pull request #4225: Adds Add Predeclared Class Module Command

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #4225: Adds Add Predeclared Class Module Command

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

Why is the following pasage in the ctor for ComModule?

    Type = DeclarationType.ProceduralModule;
    if (attrib.cFuncs > 0)
    {
        Debug.Assert(attrib.cVars == 0);
        GetComMembers(info, attrib);
    }
    else
    {
        Debug.Assert(attrib.cVars > 0);
        GetComFields(info, attrib);
    }

In other words, why do we assume that either cVars is 0 or cFuncs is 0?

In my test, the standard module from the user project has cFuncs > 0 and cVars > 0.

This is for TKIND_MODULE, right?

Because the specs seems to describe a different behavior for module vs other type.

msdn.microsoft.com/en-us/library/…

msdn.microsoft.com/en-us/library/cc237853.aspx

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #4225: Adds Add Predeclared Class Module Command

Ok, the problem here is that the VBA standard modules have both a method table and a data table.

Reading both the methods and the fields leads to an AV.

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

I wonder where exactly that happens.

I wonder if the both tables are pointed to using same pointer?

I only had a quick look at Wayne's source code for Document but it looks to me that the main difference is his code defers all the releases until end whereas we release it as soon as we are done with it.

Our version seems to be the cleaner one, but if multiple structs are intertvined in the typelib, we might be asking for trouble when releasing one of them.

Maybe comment out the release (and leak memory) as a test to see if that makes a difference ?

If it does then we will need to wrap those accesses.

I wil maybe do that later.

I have just verified that the pointers are different.

is *foo = **bar (unsure of the notation) a possibility? meaning, they look different, but one is actually a pointer to the other?

Might be our multithreading.

^ also

Don't think so. Those supposed to be pointers to structs

the MT theory would be a surprise though. In our cases, the crashes are very consistent. Too consistent to be just a race condition

then..

Apparently, the call it does not like is when we try to marshal the constant in the module to a Variant.

That actually makes sense.

I guess, usually com fileds in typlibs are variants by convention.

However, the VBE might store it as whatever the type of the constant actually is.

the constant in question has the type defined explicitly?

To be honest, I have no idea which constant it is.

That will require some investigation.

But first, I will try whether it blows up, too, when I only look at the fields.

Anyway, the VBE considers all constants typed, no matter whether you specify it or not.

OK, it has nothing to do with multiple release.

It throws on the first marshal to Variant on the first member.

Further investigation shows that marshalling fails because we pass a null pointer.

BTW, the constant is a variable.

Hm, we pass DeclarationType.Constant for all fields in a com module.

That does not seem to be appropriate for VBE modules.

From the documentation, I think I can determine whether it is a variable or constant by testing whether that pointer is the null pointer.

COM constructs are really not too intuitive.

[rubberduck-vba/Rubberduck] Vogel612 commented on Rubberduck.Resources/Rubberduck.Resources.csproj of pull request #4225: Adds Add Predeclared Class Module Command

Did we change something around the dockable hosts? I get exceptions at shutdown.

huh ... new GH feature?

When did we stop calling Release in the dockable window hosts?