« first day (2673 days earlier)      last day (67 days later) » 

12:02 AM
[Minesweeper] 65 Games Played. 47 Bombs Used. 8669 Moves Performed. 5 New Users
[rubberduck-vba/Rubberduck] 1 issue comments
Renovations are pretty much finished, I'm moving my desk and setting things up (need to fix some network wiring) this weekend!
1 hour later…
1:55 AM
9 hours later…
11:06 AM
The Mug is back??? Yay!!!!!!
Oh, and congrats on getting the home improvement projects completed, @MathieuGuindon
1 hour later…
12:19 PM
wow... it's so quiet here, even Duga's left!
Mug! Mug! Mug! Mug! Mug!
Good to see you back, even if you're just checking in on the state of things and not (yet) actively ducking
12:34 PM
5 hours later…
5:35 PM
If I have a Collection in a class, does it make more sense to access it as myClass.Collection.Add, or to have a myClass.AddCollectionItem(value) method?
I can see value in both methods, though the first is certainly easier...
6:04 PM
Depends, is the class logically the collection itself? or would this class contain multiple collections? Is the collection merely a property of the class?
Like a class KeyRing is a collection of keys. Then it would make sense to have .Add right on the ring. However, if your class is KeyMaster who happens to have a KeyRing collection then I would expect KeyMaster.KeyRing.Add
Either the class should return a collection as it's default or it should have the collection as a property. Right? But not a public collection directly.
Or maybe you need a class inside your class
this would be a single property inside a small class with other properties.
6:20 PM
I see no problem with a KeyMaster.KeyRing.Add for that.
You can do KeyMaster.AddKey(theKey) pattern if you want but I don't think it's necessary
@HackSlash I think I've done that for a collection in another class in another project, and it worked out to be a royal pain. :/
thanks for the confirmation.
7:18 PM
PSA: Hacktoberfest has started.
I'll still wait till it's really October for me until I open PRs.
7:39 PM
Spooky hacking! I hope the PRs aren't monstrous!
7:57 PM
@FreeMan doesn't ducking mean ... the opposite of actively participating? As in "ducking my responsibility" or "ducking the question"? haha.
8:28 PM
> That no ignore annotation can be applied to any but the first line in a line-continued statement is a direct effect of the current scoping of our annotations. These always apply to the first physical line below them, i.e. the first line in the editor below them.
Since it is impossible to add comments on any but the last physical line of a line-continued logical line, it is currently impossible to apply an annotation to anything not in the first physical line of a logical line.

Changing thi
8:53 PM
> I cannot reproduce this with the current version of RD. Could you check whether the problem is still there for you.
If memory serves right, there was an overhaul of this inspection at some point.

Should the issue still be there, could you verify whether you also see the problem if you use string literals as arguments?
1 hour later…
10:09 PM
> Closes #5845

This inspection usually ignores arrays because they are technically valid without assignment. Moreover, it is a bit unclear what it means for them not to be assigned. (one index vs. all indices)

In the case of a Variant used as an array without an assignment to it, which is possible using a ReDim statement, we do not know that the variable represents an array. So, an inspection result was issued, although some or all array slots were assigned to.

To deal with this, a new
> Closes #5853

Previously, we did not always determine correctly whether there is a member access on the return value of a function. The problem was that the reference in a member access expression goes to the unrestricted identifier while it goes to the whole simple name expression in case of a simple name expression. This makes it necessary to deal with them in different ways; the first member access parent of a reference to a member access is the member access itself while it is a further
> This PR intends to address the issue #5782.

While it does not really fix the root issue while resolving the supertypes of certain controls in Access, it should stop the reolver from bailing out completely.

In general, the implicit contract of the binding contexts has always been to return a failed resolution binding whenever the resolution fails. Unfortunately, that was not actually the case, if unexpected context types were encountered while building the expression tree. To remedy this,
[rubberduck-vba/Rubberduck] build for commit d2dff521 on unknown branch: AppVeyor build succeeded
10:56 PM
[rubberduck-vba/Rubberduck] build for commit b56b19d0 on unknown branch: AppVeyor build succeeded
11:21 PM
[rubberduck-vba/Rubberduck] build for commit 770c5689 on unknown branch: AppVeyor build succeeded
11:47 PM
[rubberduck-vba/Rubberduck] 1422 stars vs. [decalage2/oletools] 1745 stars

« first day (2673 days earlier)      last day (67 days later) »