Just wanna say, I am truly thankful for the long-suffering folks in the VBA community on @StackCodeReview
You're some real heroes, and an awful lotta folks have benefited from your work and patient help. Please don't let the haters get you down!
I can see that. I'm really not much on the SL pattern hating. It imposes a DI pattern preference at the detriment of what makes sense. DI doesn't need to mean DI all the time and nothing but DI. That got us in trouble in some places in the past.
There's simply some realities that using DI where it counts implies - and one of those realities is that you can KISS in some places by using an SL pattern.
Just wanna say, I am truly thankful for the long-suffering folks in the VBA community on @StackCodeReview
You're some real heroes, and an awful lotta folks have benefited from your work and patient help. Please don't let the haters get you down!
public bool TryGetProgIdFromComType(Type comObjectType, out string progId)
{
var pTi = Marshal.GetITypeInfoForType(comObjectType);
if (pTi != IntPtr.Zero)
{
var clsid = Guid.Empty;
using (DisposalActionContainer.Create(pTi, x => Marshal.Release(x)))
{
var typeInfo = (ITypeInfo) Marshal.GetTypedObjectForIUnknown(pTi, typeof(ITypeInfo));
typeInfo.GetTypeAttr(out var pAttr);
private bool TryFindCoClass(ITypeLib lib, int originatingIndex, string originatingName, Guid originatingGuid, out ITypeInfo coClass)
{
ITypeInfo coClassTypeInfo = null;
EnumerateTypeInfos(lib, i =>
{
if (i == originatingIndex)
{
return false; //No point in asking if one is oneself's parent...
}
lib.GetTypeInfo(i, out var otherTypeInfo);
UsingTypeAttr(otherTypeInfo, otherAttr =>
Not quite the same code arrow, but the nested invocations and function parameters aren't as readable IMHO. There isn't a way to make it more fluent is there?
The reason I bring it up is that I still want to eventually offer a late-bound -> early-bound refactoring and IntelliSense for late bound members (CreateObject derived variables).
Both of those need the exact same type of services - look up a ProgId, cache the result, optionally create declarations from it, etc.
Ok, I was not sure about using Com*** primarily because I wasn't sure if I wanted to pay the cost of analyzing 10000 types when the Mock provider asked only for 1.
hmm yeah. I'll need to rethink how to handle the CachedTypeService.
I think it still should encapsulate the Marshal.TypeForITypeInfo and maybe? Type.TypeFromProgId to ensure we don't accidentally create 2 types for "same" thing
I'm asking for your help. My research ended up in 2 different macros that combined will give a good utility for my work.
This VBA code will insert image as comment.
This VBA code will fetch Hyperlinks(Local folder path only, not web
based URL) and paste them in destination cell.
I really trie...
After doing some bottleneck testing as shown below (code of interest is at row 10):
I have already resolved several others using Application.Index with Application.WorksheetFunction.Match and reduced time to perform from about 7-8 seconds to milliseconds. My problem is with the code below as I ...
Early Bound: I get Intellisense in the VBE for programming convenience. However, if my end user doesn't have the exact same version of the installed support DLL, it can go up in flames.
Late Bound: I get no Intellisense when coding. However, so long as the method I'm calling is supported by the end user's version of the DLL being loaded, it doesn't matter what version they're on.
So the main advantage of late bound would be found if I have a diverse user group and I don't know what versions of software they may have installed. If I'm in a very homogeneous office environment where everyone is updated to the new version of "software x" within days, or at most weeks, then early bound is basically advantages all round.
The reason I bring it up is that I still want to eventually offer a late-bound -> early-bound refactoring and IntelliSense for late bound members (CreateObject derived variables).
That kind of what I was thinking. I.e., in a loop you really should cache GetIdOfNames, but you can't, because the spec doesn't forbid changing the return values at runtime.
There's nothing that says you couldn't just return random functions in the vtable.
in the end, they end up the same, don't they? Dim MailMessage As = 1, Dim MailmessageX As = 2, Dim MailMessageY As = 3, while Outlook.CreateItem(0).X.Y = 3
or am I not counting correctly?
Both assume you have to Dim Outlook As at some point
Or does the individual Dim method have to dereference all the way from Outlook down for each individual call, it's just that VBA will kindly do it for me in the background?
@FreeMan, try this - you have a <interface>.<method> -- does the <method> another interface (aka object)? Yes, run another method on it? Yes, that's 2nd dot.
@this yeah, I mostly get that, it's just that I'm seeing the same number of dots in my made-up example so I'm not seeing the difference Comintern mentioned.
@Comintern this I can get behind as a good reason for the Dim all the things™ method!
@Comintern so what was the "count the dots" comment if it works out the same? Are there instances other than my contrived example where it won't (be the same number of dots)?
And that's technically late-bound, as well. Let's make it really early bound....
Dim myForm As Form_frmForm
Set myForm = Forms.Item("myForm")
myForm.someControl.Value
This has the same number of dots but I would say that the latter will be better performing because it's all early-bound.
With the original and the 2nd expanded examples, we were using the generic Access.Form interface and default members (is there any performance penalty for implicit default access, @Comintern? ).
@this so that is really the answer, except when you don't know what version of Access the end user is on so you can't add Access.15.DLL (or whatever) to the References list.
If I'm getting the gist correctly: Bind early and declare variables for any intermediate level objects that you're going to use multiple methods on whenever possible. Bind late, declare variables for any intermediate level objects that you're going to use multiple methods on when you don't know the software version the end-user is on because that version may not support the method you're calling.
(As an added bonus, build in alternate methods of getting to the end point, or at least an elegant method to handle the missing methods.)
In those cases, the locked references are loaded by host so it's always fixed to that host's version. But any extra references, yer on your own, buddy.
@this I could install multiple versions in multiple VMs, right? Can I install the same win10 (or win7/8/9) license key in multiple VMs without getting any sort of MS aggro? he asks, switching topics
@Comintern just to double check I'm not being oblivious - I cannot see any place where we are in fact caching the ComProjects -- in the library reference collector, we just new it up to collect the declarations then dispose of it. Is that right?
@this Early bound, no - there is no difference in the default member. Late bound shouldn't matter - it would just request the method by dispid instead of name.
@Hosch250 I ran into the same type of issue with the CE, and the solution is completely non-obvious. If you do an in-place sort, you can minimize the number of collection add and remove events. It's the item rendering that kills.
I'm asking for your help. My research ended up in 2 different macros that combined will give a good utility for my work.
This VBA code will insert image as comment.
This VBA code will fetch Hyperlinks(Local folder path only, not web
based URL) and paste them in destination cell.
I really trie...
After doing some bottleneck testing as shown below (code of interest is at row 10):
I have already resolved several others using Application.Index with Application.WorksheetFunction.Match and reduced time to perform from about 7-8 seconds to milliseconds. My problem is with the code below as I ...
VBA Rubberducking
VBA Rubberducking