for anyone who is wondering, I finally got a definitive answer to a discussion we had long ago on here --- if a COM object implements only the IUnknown, then it cannot be assigned in VBA to an Object. Such COM object absolutely requires a type library. It can be assigned to an IUnknown variable but it's basically useless because you can't invoke any of the object's methods as a IUnknown.
I'm writing a method that writes the code for a loading routine.
Given an object from the database, I want to put its properties in the right control on a userform.
I have the list of the properties and I have the names of the controls.
For each property, I want my code to search in the controls'...
Extends the IModuleRewriter.Remove() method to clear residual blank lines between the removed declaration and the next declaration. Supports VariableDeclarations and ModuleBodyElementDeclarations removals. Also improves Variable declaration list handling.
Incorporates IModuleRewriter extension method to clean up newlines left by declaration removals. Removes EncapsulateFieldRewriteSession wrapper class that previously handled declaration removals.
@MathieuGuindon I don't think so - it was for something different relating to inspecting whether we can safely ignore assignments like Set myObjectVariable = someIUnknownVariable in an inspection
> The type involved in the cast is defined by MZ-Tools; Carlos explains it in the linked issue, but the problem is ultimately that the IDE is loading two .net-based add-ins, and the two are marshaling COM types into .NET types, and if one "wins" then the other "loses": you can try configuring the MZ-Tools add-in to not load at startup and try to load it manually after Rubberduck finished initializing, but basically in order to fix this interaction we have to "shim" the .NET runtime itself [or
@Duga very much hoping that Net 5 will solve COM automation. There's a heck of a difference between net46 and netcoreapp3.1 (which is what I target at work), RD is missing out on a lot of modern optimisations atm.
Span and Memory especially could help solve some of our memory problems, even absent LSP.
> @retailcoder just a ping to remind that PR #5556 was targeted for this release...it is still in the PR queue. My understanding is that its merge should precede this PR.
@Vogel612 Won't be needed in future, check chat history. Net core (soon 5) dispenses with AppDomains, just keeping a nominal one for back-compat. COM interop changes with core; instead of every add-in sharing a single mscoree.dll, they each get their own entry point, which should provide COM isolation without shims.
hence not wanting to get involved with shims when Net 5 is due out in 3 months :-)
ok, so worst case: COM Automation is not going to be happening any time soon in Core. Not necessarily a problem - if we want to use modern constructs (especially in memory management), that's mainly of benefit for lexing, parsing and analysing, not front-end interaction. So those can be solved with LSP, back-end on (whatever), front-end stays on net fx.
if you write the IDL manually & compile a TLB and it's compatible, then it should work.
one thing i'm still fuzzy is creating a dual implementation. In the Core the ComInterfaceType.Dual is not available (nor is ComInterfaceType.IDispatch)
hmm ok, I misunderstood when you said "Automation is due in Net 5", I guess you meant TLB generation. Whatever, it's still a front-end, interop-y kinda problem. Split out the back-end, problem goes away anyway?
If Net 5 is not going to be ready to solve these problems, maybe we should prioritise front/back split. Then the front-end can be slim - interact with COM, send/receive LSP messages.
(I say this as someone who hasn't PR'd in a couple of years, I realise...)
I know... but the thing is, we're doing some pretty intense things too. We've always shied away from patching, but... The VB6 IDE exe hasn't changed in ~20 years...
Well... not entirely true. Out of the box, VB6 will bitch if you launch it without admin. But there are workarounds (probably implemented by about 13 people in the world...)
Splitting into front-end and back-end will not help regarding the add-in isolation issue. The fromt-end will still have iterate the projects and listen to the VBE events.
Maybe. I think the safety is the main obstacle. COM specifications says too little about safety, and there are lot of conventions that is not part of the programming language itself. That's why .NET is comparably much easier -- you can set conventions as part of the code and enforce it. With COM (or anything C++), the consumer must read lot of documentation to use it properly and hoping that there's no undefined behaviors.
VBA Rubberducking
VBA Rubberducking