@this hence the readme.txt suggestion - "CHANGES TO THE ORIGINAL FILES WILL BE LOST WHEN RUBBERDUCK IS UPDATED. MAKE A COPY IF YOU WANT CUSTOMIZED TEMPLATES" should be clear enough
> After some additional discussion - the consensus seems to be KISS + YAGNI; we will simply assume total ownership of all built-in templates and always overwrite the built-in templates if there has been changes between resx and rdt files for the built-in templates. We should add a readme.txt to warn that the built-in templates are owned by Rubberduck and may be overwritten.
“You’re not just going to understand this theoretically. You have to prototype. You have to code it to get it.”—@jensimmons on css grid, but equally good advice for any new tech. Learn the grain of the technology by working with it. Dive in, friends. Splash in puddles. #aeasf
When someone screen shares Visual Studio with me and their solution explorer is on the left, my default assumption is they're intentionally screwing with me and I don't care what their code says or what the bug is just WHY ARE THEY MESSING WITH ME?!?
On the other hand, you have more sunlight in summer than I would down here. I really liked it when the summer day would stay lit until almost 10 PM.... :-\
A worksheet is literally made of thousands of little textboxes (cells). Have you considered not using a TextBox control, and naming a specific [merged?] range instead, nicely formatted, with borders and shading? — Mathieu Guindon10 secs ago
> I'm a Community Program Manager w/the @Microsoft MVP Program. I love tech, MSU & knitting. I'm a photo nerd, beer geek, spork expert. Michigander in NYC.
#awesome!
I guess that means I should probably update my MVP activity... it's a wee bit lagging
I might be as well, but my understanding is that because VBA builds on top of COM, and considering that COM is meant to be an ABI, it shouldn't care a fig about the low level hardware details.
I mean, I can't tell from a glance if this thingee is a COM, a COM+, a DCOM, a OLE, an ActiveX, an Automation, and there might be more I don't even know about.
for me, I'd have more issue with the fact that we have different ways to cast something. I don't need to care about whether I should (cast) or as otherType.
let the compiler figure out the optimum path so I can focus on expressing the logic instead of the mechanics.
public interface IFoo {}
public class FooBar : IFoo {}
public class FooBuzz : IFoo {}
public void DoSomething(IFoo foo)
{
DoSomethingElse((dynamic) foo);
}
public void DoSomethingElse(FooBar val);
public void DoSomethingElse(FooBuzz val);
it's one thing to break some pretty icons on a user's windows; it's entirely another thing to break a crucial ActiveX dll on all computers in a company's domain and hemorrhage money due to lost productivity.
The Oklahoma supreme court has clearly never seen Chinese Drunken Boxing, or "deft clumsiness" would not have been their word choice =) — Cort Ammon21 hours ago
@mansellan right. and in light of how they apparently continue to support VB6 applications, it probably won't actually die until MS actually drop the runtime support.
VBA Rubberducking
VBA Rubberducking