Probably the best way to do it would be to attach a listener to the VBProjects events. The much more difficult problem is going to be figuring out where to store the data. We're currently creating and destroying wrappers for the same projects all over the place.
Actually, according to Paul Lomax they're the same.
IsObject is simply a “convenience” function that is roughly equivalent to the
following Visual Basic user-defined function:
Private Function IsObject(varObj As Variant) As Boolean
If VarType(varObj) = vbObject Then
IsObject = True
Else
IsObject = False
End If
End Function
@Duga @BZngr - Did you test that in the VBE in addition to unit tests? Any changes to RubberduckModule will pass all the tests but blow up spectacularly when you run it.
I'm guessing you ran into the same issue with the default factory binding that I did with the folder browser. I'm like you on that one - I try not to touch it if I can.
@BZngr FWIW injecting dependencies of dependencies (of dependencies...) is not "correct" DI - e.g. that view factory is a dependency of the quickfix, but the quickfix is a dependency of the inspection result, which is a dependency of the inspection.. the problem is that we're not doing proper DI here; inspections should probably not be newing up results directly. By doing that we're breaking the injection chain and making things much messier than they should be
So until we figure out a cleaner way, injecting the quickfixes'' dependencies into the inspections is really the only solution for now
Because that's where the injection chain is stopping; beyond that we're instantiating things ourselves
the role of Ninject is to create all objects, and thus to manage their lifetimes
The funny? part is that we're injecting things that we really need to be newing up (anything that crosses the interop barrier) and not injecting the stuff that should be injected.
@BZngr DI feels awkwardly backwards at first - for a reason: it requires inversion of control (IoC), which literally flips everything around - once you get the hang of it though, it's the best thing since sliced bread =)
I may poke around in source control a bit tomorrow. There were enough filepath building errors that I might have inadvertently fixed some stuff I didn't intend to.
But I'm thinking disabling extract method is probably a good idea. Are there any cases where it works?
Huh. There's nothing to the UserControl interfaces at all. Looking at in the OB now.
I'm guessing all we need to implement is IContainerControl.
@Mat'sMug Practically good code beats theoretically good code hands down.
Hmmm...
public virtual object InitializeLifetimeService()
Member of System.MarshalByRefObject
Summary:
Obtains a lifetime service object to control the lifetime policy for this instance.
Returns:
An object of type System.Runtime.Remoting.Lifetime.ILease used to control the lifetime policy for this instance. This is the current lifetime service object for this instance if one exists; otherwise, a new lifetime service object initialized to the value of the System.Runtime.Remoting.Lifetime.LifetimeServices.LeaseManagerPollTime property.
Yeah. I've never really looked that closely at the MarshalByRefObject before - never really needed to get that far into the weeds.
I wonder what an override to that is supposed to look like.
Interesting...
> Whenever an MBR object is remoted outside an application domain, a lifetime lease is created for that object. Each application domain contains a lease manager that is responsible for administering leases in its domain. The lease manager periodically examines all leases for expired lease times.
> If a lease has expired, the lease manager sends a request to its list of sponsors for that object and queries whether any of them commit to renew the lease. If no sponsor renews the lease, the lease manager removes the lease, the object is deleted, and its memory is reclaimed by garbage collection. An object's lifetime, then, can be much longer than its lifetime lease, if renewed more than once by a sponsor or by continually being called by clients.
> Note - this disables a bunch of tests that should have been failing, but were only testing mocked behavior. This will need another round of refactoring before it's worthwhile to re-enable\re-write the tests.
I'm trying to create a Visual Studio Integration Package project which will display data from the debugger.
So I found the EnvDTE namespace, that looks to give me the needed classes and methods.
According to the documentation for VS2005, the following code should be used to get an instance of the...
@FreeMan I haven't read any of them (yet), but I just found 100+ free eBooks that SyncFusion offers for free. There are books on Git and GitHub (and also lots on C#, OOP, SOLID etc).
They may well be compromised by the sponsorship, but they might still be useful
I'm not exactly sure if the VBE objects can use those interfaces or not. I found a couple references to Office installing a envdte .dll, but I don't know if they would marshal to the .NET version or not. They look really familiar though.
My thought was to see if _DockableWindowHost could implement one of the interfaces in there instead of UserControl. That Document interface also looks suspiciously similar to the OLEObject interfaces in Office.
I'd lean toward ModuleState personally. Is there any reason the ModuleState couldn't hold a IVBComponent reference?
@M.Doerner The problem with the QMNs was that we were holding 10s of thousands of IVBComponent references on the Declaration objects and incurring a ton of COM interop overhead because of it. ModuleState would seem like a more reasonable place to have those references assuming that we cache the Name property to be used for the lookups. IIR we're already subscribing to name change events on VBComponents, so it shouldn't be difficult to keep the lookups in synch.
Morning all, would the recent news about preventing Win32 on Win 10 be any concern for RD project? Just learn that certain apps needs to be converted to work. mspoweruser.com/… And mspoweruser.com/…
> Just a clarifying question. When you say "setting it up on the command line", are you talking about the native git shell, or the COM lib via the immediate window?
@PeterMTaylor - Shouldn't be an issue. It appears to be a settable option, and I'm guessing that it will backfire harder than Windows 8 getting rid of the "classic" desktop. Looking forward to the explosion of blog posts explaining how to turn it off.
We don't modify the file path/URI in any way at the library level. This could be confirmed by using a raw `GitProvider` to clone a repository on the file system.
Regarding default control names: The Office UI language determines the default control names. Under an English UI, a control might be named Command1 or CommandButton1, whereas in German, the control would be named Befehl1. But a VBA project might be shared between users with different UI languages, so perhaps the meaningful names inspection should look for the UNION of control names across multiple languages?
VBA Rubberducking
VBA Rubberducking