REFRESH!

[Minesweeper] 78 Games Played. 35 Bombs Used. 10653 Moves Performed. 20 New Users

solution builds, I've pushed the branch

@this structure should be much clearer now :)

Question: Did you ever have trouble running the unit tests on an unsaved workbook, especially on 32 bit

As in one that had never been saved

@IvenBach is alive!!!!!

@MathieuGuindon Does that mean that it's there on GitHub for us unwashed (individual parts of the) masses to look at?

@FreeMan sort of; there's an open PR in the RD3 repo

@Greedo what would be a use case for making and running unit tests without saving? It seems to me that one should have it saved.

@IvenBach not clear. Can you please confirm if you're comatose, morose, or terminal? Thank you for clarifying.

@MathieuGuindon sweet! I will try to have a look tonight.

In other news, the yet-published PR for dscom is now down to one failing test. Took a bit more time because they already had a name resolution scheme in place so had to be backward compatible while supporting the inline attribute to provide an alias for elements to be exported into the type library.

@this lol

@this For some reason the ITypeLib.GetDocumentation returns an empty string on unsaved 64-bit xlsm until you save, close and re-open, and on 32-bit even saved and reloaded doesn't work, the project needs some kind of maturity I haven't identified. I.E it works on a random big project but fails on a new project

Maybe RD loading as a VBIDE addin gives enough "complexity" that it just works. I'm talking about the secret VBE project accessing code in RD's test runner

VBE is weird

VBIDE is a bug.

Just verifying - did you read Wayne's notes in RD's codebase?

One thing that I remember from his notes is that the type libs cannot be cached. Is that applicable in this context?

Thanks but no that's not it, I haven't cached anything since it is the first call.

didn't think so but he did note several caveats about it - the implementation is not 100% compliant

@this You've got that right :D I'm thinking I might be able to ignore the issue. RD "Finds" the correct project typelib using VBProject.Name = ITypeLib.GetDocumentation(MEMBERID_NIL), I might be able to assume that if a TypeLib has "" for its name then it's the right project. See where it crashes then

@this current status: localdb client app finds the server executable, starts it, ...and then everything closes because the client app isn't creating its main window yet. But it's a start!

@Greedo wrong type lib

you're in the immediate's typelib.

Ahhh that's what all that meant. OK well maybe I don't pick the one with no name. In that case the project typelib isn't even showing up in the linked list of ITypeLibs, or I'm reading them wrong (maybe not reversing or iterating the list the whole way for some reason)

I'll see if tUnitVBA has this issue

It does

the thing is that I'm not sure RD ever runs unit tests on an unsaved project

Yes but does RD work on a nearly blank 32 bit project (that is saved)

sorry was that a question? I am not positive sure but it should?

Yeah a question of sorts:) If RD does work then my VBA port (as used in tUnitVBA) is broken, if it doesn't then the technique might be buggy

lemme go try and see. First does RD work on unsaved projects

it should, not in a place to check that for myself (I no longer have 32-bit Office installs in my regular VMs)

Yeah RD works unsaved 64-bit - it can execute the test alright.

OK. I would expect the same to be true in a 32-bit

Yeah same. Well done RD:) I'll see if I can find why my port isn't picking up all the typelibs. It looks like when it detects blank project name, that's always the immediate window typelib. So I should let it run through all the typelibs and make sure they are all accounted for. I just wonder if RD falls back to another method I haven't uncovered yet.

RD has a test runner

and that's where my memory is vague whether it's using the same method to discover test method as parsing does. I think it should but not sure

Yeah this github.com/rubberduck-vba/Rubberduck/blob/next/… I ported the test runner not the test discovery. But the test runner is what finds the project ITypeLib so it can use that to get the module ITypeInfo with the tests. The ITypeInfo in turn implements IVBComponent and IVBComponent is where the test execution happens. That's my understanding at least

But don't take my word for it because I'm clearly going wrong somewhere

I have got this working though, 64-bit / big 32-bit:

Dim exampleModuleAccessor As Object
Set exampleModuleAccessor = GetExtendedModuleAccessor("ExampleModule", ThisWorkbook.VBProject)

For Each methodName In exampleModuleAccessor
	CallByName exampleModuleAccessor, methodName, vbMethod
Next methodName

Working for public and private methods. You can loop over all the methods in a module and call them with CallByName or `dot.notation. The method names are generated from the ITypeInfo directly

That's some crazy stuff right there

Try it out if you want. github.com/Greedquest/vbInvoke/releases

v1.0.1 you get the vbInvoke_win64.dll and you can add reference to it in VBA. Then you'll see vbInvoke.GetExtendedModuleAccessor and vbInvoke.GetStandardModuleAccessor (public only)

@MathieuGuindon Thanks:) Required quite a bit of VTable hacking to get the interface like that, probably a bit fragile

(backup work before attempting)

or you could do this:

Fixed it 🎉

Off by one error

Was skipping first typelib, which didn't matter except in this edge case

so I probably made the same one-off error. Sorry about that!

If it's any consolation, the top two errors that plagues every programmers are cache invalidation, null references and off by one errors...

:)

*top 3

you forgot about naming stuff

[rubberduck-vba/Rubberduck] 1707 stars vs. [decalage2/oletools] 2318 stars