> There were talks of using xml-docs in the source code to generate the user documentation contents. I think that's the best way to do it. Needs quite a bit of work on the RD-Web repo then, and proper & complete xml-doc on all inspections, quickfixes, refactorings,... And basically all commands.

@M.Doerner / @Mat'sMug Until/unless we find a way to find the type of a document module, what do you think about an annotation like: '@Me: Workbook As Excel.Workbook? RD could then know what Me is, and that Workbook_Open is an event procedure, and usages of Name are references to `Workbook.Name'.

I'm working with the VBIDE API, and can't assume that the host application is Excel, or any Office app either.
So all I know is that I'm looking at a VBComponent, and that its Type is vbext_ct_document.
In the VBE's immediate pane I can get this output:
?TypeName(Application.VBE.ActiveVBProjec...

since predeclared has to be allocated, outside the VBA code, it's different.

If you try this with a UserForm or anything else that's predeclared, I suspect you'll see the same behavior.

I do have to admit, it's very weird to see the Is operator returning true even though the pointers don't agree. I always thought the Is operator was basically checking the pointer's value. Obviously it's doing a bit more than just that.

Regarding identifying document modules, the solution proposed in the SO answer is implemented hallways at the moment. The problem is that the way the COM collector currently exposes the CoClass we cannot identify the methods. Thus we are comparing the properties against the properties plus the methods, which cannot work.

@M.Doerner IKR, I looked at adding the legacy property types, and quickly got lost in a rabbit hole.

There's also the memory structures behind the Project Explorer's Treeview Item's UserData/lparam pointers. Those pointers give me 23 further pointers, which in turn lead to more pointers. And some of those pointers lead to things like a GUID for the project, and the offset into VBRuntime library. I'm hopeful that somewhere in the mix, I can find a GUID for the document modules, and maybe other useful stuff.

But it's hard reverse engineering all that, so I'm building a tool to assist.

And re parsing the FRM files, it seems the MSDN documentation only covers about 25% of the syntax that is actually possible.

@NelsonVides Currently, we are on Antlr 4.3, which cannot be built in VS2017. However, it can be built in VS2015, which cannot build the solution. So any grammar changes have to be done in VS2015 atm and then one has to switch back to VS2017 to actually build the solution.

No worries. just wanted to be sure I got it right, or if I could do better. One thing I do have to do is to see if I can come up with interfaces but I'm not at the point to define interaces so for now the For() and ImplementedBy() uses the same concrete types.

@this Since the implementing type in the first registration is not generic, it does makes sense. In the second, you can drop the IimplementedBy; without it it binds to itself. In the third one, I guess you wnat a transient auto-magic factory, because that is what you get with this registration.

Different question for anyone who can answer... I see that IRefactoring does not have a validation method, forcing the commands to answer the CanExecute. Does anyone else think it really should be the refactoring class's responsibility to determine if it can be executed or not? I'm in another passing-the-buck situation due to the need to share validation results to the refactoring.