@mansellan at least you weren't a grandpa at age 32. My old man had a friend growing up that had a kid a daughter at 16 who also had a daughter when he was 16. 32 years old and everyone calling him gramps.
@mansellan That is a textbook case of 'Dick-move' right there.
@23fc9a62-56de-47fb-97b4-737890 I derped pretty hard last night. Had the overriding method on the wrong class. :cringe:
@IvenBach Uhm, technically I was a grandpa at 20 depending on how you trace it through.
@IvenBach Yep, totally. And I still had to fight social services to adopt my daughter, because her biological father had to be contacted and decided to object.
Oh wait, there's no technically about it. I was a grandpa at 20. OK, definitely feel old now.
But if you count grandchildren as "your children's children" (not including step-children), then I'm still waiting. Yay!
I'm trying to find a useful way to deal with annotation information that's static without losing the fact that annotation instances are tied to specific parser contexts
right now, you want to set up type hierarchy but you want to use static members and somehow inherit. That's the painful part about mixing statics in instances.
what you're proposing is basically an extension method that's tacked onto a specific part of the type hierarchy
but I'm pretty sure it won't work, because you still need to somehow get the type you're looking at to the basetype.
if it's a static member of the basetype, that means it can't access GetType() (which would return the runtime type), but if you can't take advantage of that, you may as well have an extension method that takes any Type and does the magicking
Wow, I feel dumber than a guy trying to write an ampersand on a whiteboard. When you get talking about rhis stuff, I realise how much I don't know about computer science.
Dim f As Scripting.FileSystemObject
Dim ds As Scripting.Drives
Dim d As Scripting.Drive
Set f = New Scripting.FileSystemObject
Set ds = f.Drives
Set d = ds.Item("C")
var mock = new Mock<Scripting.Drives>();
var mock2 = new Mock<Scripting.Drive>();
mock2.Setup(x => x.Path).Returns("abc");
mock.Setup(m => m["m"]).Returns(mock2.Object);
Assert.AreEqual("abc", mock.Object["m"].Path);
I think I might just have Item be swallowed and converted into an indexer.... this is the original failing mock setup:
var provider = new MockProvider();
var mockFso = provider.Mock("Scripting.FileSystemObject");
var mockDrives = mockFso.SetupChildMock("Drives");
var mockDrive = mockDrives.SetupChildMock("Item", provider.It.Is("abc"));
mockDrive.SetupWithReturns("Path", "foobar");
var obj = mockFso.Object;
@Vogel612 depends.. user code gets to decide if they want one, two, three, or all @Ignore annotation arguments on one line, or if they want to separate each inspection type say, to allow the space for adding a separate justificative comment for each one?
[rubberduck-vba/Rubberduck]retailcoder pushed commit 1dec1e34 to next: hotfix for ExcelHotkey annotation; quickfix for MissingMemberAnnotation is broken for this annotation though, presumably because of the "\n" in the attribute value.
@all interesting food for thought as per CodeProject
Suzdalnitski argues. Object-oriented programs instead end up with variables and their mutable states “shared promiscuously between various objects.”
“In most cases, OOP programs turn out to be one big blob of global state, [which] can be mutated by anyone and anything without restrictions,” he tells me in an email.
Suzdalnitski also believes that object-oriented code is harder to refactor and harder to unit test, and his essay builds up to a bold pronouncement that “It is impossible to write good and maintainable object-oriented code…”
Thank you very much indeed for having created and for supporting this fanstatic free tool -- I am very grateful to you and all who participated and so generously donated their time and expertise to the creation and maintenance of this tool. I feel a little awkward needing to point that in my case there seems to be a problem with the tool and that I may need your help (and thus detract your attention from whatever more useful and important you might be doing).
Here's the timeline for the parsing runs you attached. The first run is the initial parse. All modules are parsed here.
Notably, Inspections are not run here, which means the initial parsing clocks in at about 220 seconds, roughly three and a half minutes (10:25:57 -> 10:29:38)
``` 2019-08-23 10:25:57.4501;DEBUG-2.4.1.4627;Rubberduck.Parsing.VBA.ParseCoordinator;Parsing run started. (thread 10).; 2019-08-23 10:25:57.4501;INFO-2.4.1.4627;Rubberduck.Par
> I see that you use the stable last release. Could you try the current prerelease, or one from the last two months?
I recall observing this and analyzing it under a profiler. I think some (partial) fix has been implemented at some point after the last stable release.
> @Vogel612 The stages do not contain the invokation of the event handlers for the state changed events. I think the problem here was/is in the CE refresh.
@Mast no it's not. we're not even in EXCEL in the first place
the problem is that our UI worker doesn't yield control for the event loop to possibly kick in
and it really can't, if my understanding is correct
so if the event loop is not running due to RD doing some heavy lifting on the UI thread it looks like the VBE is completely locked up (because the UI is unresponsive), but we're still doing things in the background
> I did some digging. The freeze mentioned here has already been observed in issue #4905 and the main sources should have been fixed in the PRs #4918 and #4914.
The main source was that the CE refresh reloaded settings over and over from file because of a bug in the code for loading the settings. This bug prevented the intended caching to happen.
Unfortunately, there has not been a stable release since the fix.
This is the most in-depth explanation for the behavior I observed yesterday. Unfortunately, this still comes up short in actually explaining how the compiler determine whether a property on a COM type should be made into an indexer.
I see that I could have used the get_XXX but I worry that setting it up will cause more problem since it's a method and I'd have to also setup the set_XXX, which feels more complicated.
For now my working assumption is that if the member is the default member (which I can know that because it'll have DispId attribute set to 0), then I can try to treat it liked an indexer but I am not confident that this assumption is true in all cases.
**THE ISSUE IS NOW _RESOLVED_ FOR ME** -- as advised by MDoerner I installed the latest release available at this time (which was Rubberduck v2.4.1.4869-pre) and the problem seems to have disappeared.
This was truely great response from you both -- thank very much indeed for your help and time. Thanks to MDoerner for suggesting to use the latest release, and to Vogel612 for helping with the initial analysis (and for even editing my first post to make it more
**THE ISSUE IS NOW _RESOLVED_ FOR ME** -- as advised by MDoerner I installed the latest release available at this time (which was Rubberduck v2.4.1.4869-pre) and the problem seems to have disappeared.
This was truely great response from you both -- thank you very much indeed for your help and time. Thanks to MDoerner for suggesting to use the latest release, and to Vogel612 for helping with the initial analysis (and for even editing my first post to make it m
VBA Rubberducking
VBA Rubberducking