@this I think it makes sense to have the client take telemetry data from the LSP server; the client gets to filter everything, and then the editor itself is also going to be a telemetry firehouse if the client lets it
@MathieuGuindon I'm referring more to tracking the internal operations executed by the LSP server that the client may not be aware of? That is, if we are debugging and need a trace to flow through all the components?
well there's telemetry, and then there's trace logging =)
trace logging might trigger TraceTelemetry events, but it'll occur regardless... unless the server's trace level is off.
So internal LSP logging would go through IServerLogger, and the implementation of that logger takes care of the console output and notifications. Basically the idea is that if you run the LSP console server app, you see everything it's outputting.
@MathieuGuindon you speak as if they are not the same thing. :-p I think I sort of gotcha now - it's more that each will have their respective clients that will capture the events.
So the ModuleAccesor code naturally generates ITypeLibs/ ITypeInfo for any modules and projects loaded in the VBE. There was discussion around RD using this to resolve identifiers that point to password protected addins. Is that the idea?
Is it worth me exposing that type info in my vbInvoke code do you think? Does anyone have VB6 declarations for TLI it's a bit fiddly to get them all and test thoroughly.
@this you said something about not being able to cache them?
Also I read in RD code somewhere, I think in the IVBComponent interface, there are "pointers to some related typelibs"... Anyone know if the invocation type information is the same as the stuff RD would require for identifier resolution
As in, maybe the ITypeInfo I get in vbInvoke is not the one you will need. I vaguely seem to remember it not containing Enums or Types or something along those lines
@Greedo Yes, AIUI, it gives us the ability to inspect a project as if it was an external type library. We don't have the same visibility as we do with source code (only public symbols are available) but for the purpose of inspecting references to the protected projects, it would help give more complete information for the references to public symbols from the protected project.
@Greedo TBH I never liked TLI and given that it's 32-bit only, I'd love to see a better replacement. May require some work, though.
@Greedo There are two different issues. First issue is that a reference to a ITypeInfo coming from VBA project cannot be assumed to live beyond any design changes; you'll have to invalidate all the pointers to any ITypeLib/ITypeInfo whenever making design changes or experience the joy of crashing.
The 2nd issue is that the caching of the representing type for the purpose of mocking cause problems when running unit tests due to how types are cached in .NET. That's a .NET only problem and not applicable.
@this they're pretty similar, but then we don't need any "user clicked menu command X" in the trace logs (we'd be trace-logging the execution of the command); the trace log tells you what's running, but the telemetry event tells you how it happened (menu command, or context menu, or hotkey)
@MathieuGuindon #ItDepends. Normally, .NET will never unload a type that's been loaded. Moq works around this problem by using dynamic proxy provided by Castle Windsor. However, Moq doesn't expose a method for invalidating the assembly
@this Yeah I actually meant does anyone have VB6 stub declarations for the ITypeInfo/ITypeLib/FUNCDESC etc. methods and objects so I can have a start point to declare the interfaces in tB. Agreed the helper methods in TLI aren't the best API.
@this That makes sense, similar to persisting a VBA Class over a stop button press using AppDomain, all bets are off on whether it remains valid. There are probably implementation detailsy instances where caching is possible. But TBH reading the structs is pretty instant, it's at the RD level where caching can be done - request the ITypeInfo of only the dirty modules, never save the object. Perhaps I could serialise the ITypeInfo and never expose the object directly...
@Greedo yes, that'd be the way to do it - you may want to cache the information how to find the ITypeInfo/ITypeLib, so that you can refresh the cached information easily while storing the harvested information within the class rather than persisting the pointer to the ITypeInfo/ITypeLib.
Unrelated: dscom now has a new version out. Time to say goodbye to olewoo & WiX. :)
I have a VBA that takes all the rows with the same ID in Column 1 and concatenates the data in Column 3 to a single cell with line breaks. The code then deletes the old rows. The code works, but takes 10+ seconds to run. I have about 3-4k rows of data but I was hoping this could run much faster.
...
VBA Rubberducking
VBA Rubberducking