@SmileyFtW duga keeping custom stats and reporting them. I have an api key for it, we could have the number of "vba snippets indented", or number of page views, or whatever we want to tally and quick-report on
Following-up on my last question where I wrapped the Sage API with a familiar IRepository interface, I decided to push the abstraction a step further, and... implement an actual LINQ provider.
So my client code looks like this:
class Program
{
static void Main(string[] args)
{
u...
@theVBE-it'srightforme basically it's the part that translates db.Things.Where(thing => thing.Foo = 42); into SELECT (explicit field list) FROM Things WHERE Foo = 42
@Duga Not sure what 'parser fallback' is/means, but the tests I'm seeing this in use all the general base class code. So - I'm guessing the TestSetup parsing mode is the same as all the other tests I've written.
@BZngr "live" parser starts by attempting a parse with SLL prediction mode, and either succeeds or retries with the slower but more accurate LL prediction mode. Not sure we built that mechanism into the test parser
the most likely is that the warning is just the test parser logging a SLL failure... If that's the case then maybe we need to make them clearer that LL mode is being attempted (assuming it is)
@MathieuGuindon Suspected it might be a test-parser-only thing. I have a parameterized test with a handful of declarations in a list. So, it generates quite a 'wall' of complaints. Thought it was worth identifying once I found the cause. Other than the output 'noise' - the test(s) run just fine.
If the tests run fine, then it's probably just that: a warning about SLL failure. We should find the source of that warning and tweak the text so it's less confusing
MethodInfo[] methods = src.GetMethods();
List<MethodInfo> actual = new List<MethodInfo>();
for (int i = 0; i < methods.Count(); i++) { if (methods[i].DeclaringType == src) { actual.Add(methods[i]); } }
In the old days, a BSOD just meant you hit the reset button or the power switch. Now, you feel obligated to wait 10 minutes or so for it to gather something, then you hit the reset switch when it's showing no further indication of functioning.
@ anyone with any COM interop experience - if i want to marshal <x> as say, currency, instead of decimal, does the MarshalAs attribute have to be applied to every instance of <x> in the type in question? i'm pretty sure i know what the answer is but im hoping im wrong for obvious reasons.
@FreeMan I smother it. Sad state of affairs, but sometimes it just needs to die. Get that pillow and put it over the mouth and just give it the 6 seconds to stop breathing that it needs.
@this yes that is why i said "i'm pretty sure i know what the answer is" :(
@MathieuGuindon yes sorry that wasn't clear, i meant <x> as in a certain data type that a class is oriented around that then might appear in several of its members
@this applying custom attributes in reflection is not particularly fun from my experience with it so far
you know that error i was having yesterday where it said the parameter was out of range when it wasnt? came from custom attribute copying being implemented incorrectly.
so would be like if i wanted to test the Button class in my VBA UI framework to make sure it emulates the standard windows forms button behavior correctly without having to worry about all the junk around it?
Bar in this case being the IFormButtonContainer that holds it and Baz being the actual form etc
Hence, you mock the Bar and Baz with something that looks and acts like either but won't actually write a file, send a web request but simply verify that they were invoked correctly to write a file/send a web request in theory.
but the baseline concept is that you want to isolate a specific component and validate it internally while minimizing the cognitive load of setting up the external dependencies it needs to function correctly?
e.g. you give it a mock button, and let it call drawing methods on the mock button, then check that all the drawing methods were correctly called with correct parameters.
" It just so happens that there is a custom marshaling routine called TypeToTypeInfoMarshaler that transforms an ITypeInfo interface into a System.Type object. "
besides, I think it's impolite to go around merging one's own PR esp. when it has lot of changes without having at least some another pair of eyeballs glancing over the code
"In addition, COM custom marshaling provides capabilities to change object views across the managed/unmanaged boundary. In many cases, some powerful method interception behaviors can be achieved when combining these techniques."
i feel like there is something here even though i couldnt say what it is
do you want me to put this article on the PR as well?
> While researching an unrelated problem I came across several things that concerned the use of IReflect to effectively implement custom IDispatch functionality. Start with the first answer on this SO post which contains a lot of useful ideas itself; the blog post they referenced is very helpful and while it has a broken link it can be accessed [through wayback](web.archive.org/web/20100701000
Assuming that IDispatch-based COM instances can, and generally do, return type information through their IDispatch implementations, it is possible to overcome the inherent shortcomings of .NET Framework reflection with respect to IDispatch.
that seems like a pretty apt description of the problem you are having
I finally realized that the quote about marshaling you quoted was already linked in the link you added to the edit in the PR comment, and read it (finally). Hence self-deprecating remark about reading the comment.
So... 39*80ish UDF references in a sheet... that's still probably better than having 4x index/match in each cell, with 3x if-statements, right? long-term editing, just seems more reasonable to correct a UDF than decipher wtf someone Y years ago thought was a good formula
"the inherent shortcomings of .NET Framework reflection with respect to IDispatch" seems like the core of the issue you are having from what you linked me on GH
"The provider aims to work around a deficiency in the <see cref="Type.IsEquivalentTo"/>, particularly for COM interop types"
Question regarding ShadowedDeclarationInspection: do we want it to exclude all event handlers and their parameters or only those for built-in events and their parameters?
Following-up on my last question where I wrapped the Sage API with a familiar IRepository interface, I decided to push the abstraction a step further, and... implement an actual LINQ provider.
So my client code looks like this:
class Program
{
static void Main(string[] args)
{
u...
VBA Rubberducking
VBA Rubberducking