« first day (1593 days earlier)      last day (1587 days later) » 

12:01 AM
RELOAD!
[bruglesco/fleet-command] 1 issue comment.
[rubberduck-vba/Rubberduck] 42 commits. 1 opened issue. 3 closed issues. 28 issue comments. 54354 additions. 17596 deletions.
[skiwi2/GeneticBrainfuck] 4 commits. 171 additions. 93 deletions.
 
Hmmm... This doesn't look right.
foreach (var candidate in candidates)
{
    var usedMembers = ((ClassModuleDeclaration) candidate.AsTypeDeclaration).Members
        .Cast<ModuleBodyElementDeclaration>().Where(member => member.References.Any(usage =>
                                                                  usage.Context is VBAParser.MemberAccessExprContext &&
                                                                  candidate.References.Any(access => access.Context == usage.Context)))
        .ToList();

    if (!usedMembers.Any() || usedMembers.GroupBy(member => member.InterfaceImplemented).Count() > 1)
Needs a boatload of tests.
 
anyone has a 32-bit host handy?
 
@MathieuGuindon Does VB6 count?
 
not really, but I'd still be curious about the result
some guy sent me an email today, with some code and an alleged bug affecting 64-bit hosts
 
12:16 AM
Eh? Was it in the unit tests?
 
no
StoringClass.cls
Option Explicit
Private mValue As Boolean

'Doesn't matter if this is commented out or not:
'
'Private Sub Class_Initialize()
'
'End Sub

Private Sub Class_Terminate()
'
End Sub

Public Property Get TheValue() As Boolean
    TheValue = mValue
End Property

Public Property Let TheValue(ByVal value As Boolean)
    mValue = value
End Property
then a stdmodule:
Option Explicit

Public Function CreateStoringClass(ByVal value As Boolean) As StoringClass
    Dim result As StoringClass
    Set result = New StoringClass
    result.TheValue = value
    Set CreateStoringClass = result
End Function


' Problem with Office 2013 64-Bit (incl. 2018-09, 15.0.5045.1000):
' This line of code works wrong:
' If Not Factory.CreateStoringClass(VALUE_TO_TEST).TheValue) Then

' Remark:
' The terminator in "StoringClass" causes this behaviour (even if it is empty).
' When it will be removed or commented out, it runs well!
there's a lot more junk and I've tweaked it a bit, but it does demonstrate the weirdness
output on 64-bit Excel is "This is wrong"
if I extract a local variable for the Create result, I get "This is correct"
 
WTF?
 
^ my exact words
 
Ahah! I can remote in to work and test it.
 
curious if VB6 behaves the same way though
..well, 32-bit should be ok apparently
that makes one hell of a compelling argument for avoiding chained member calls on x64 VBA
 
I'll strip it to a bare-bones MCVE and send it to the Excel team
 
OK, logged in at work. Let's test this sucker in 32-bit.
 
Sub ShortTest()
    Const VALUE_TO_TEST As Boolean = True
    Debug.Print "Value to check: " & VALUE_TO_TEST

    Dim result As StoringClass
    Set result = CreateStoringClass(VALUE_TO_TEST)
    If result.TheValue <> VALUE_TO_TEST Then
        Debug.Print "This is wrong"
    Else
        Debug.Print "This is correct"
    End If
End Sub
^ works as expected
Sub ShortTest()
    Const VALUE_TO_TEST As Boolean = True
    Debug.Print "Value to check: " & VALUE_TO_TEST

    'Dim result As StoringClass
    'Set result = CreateStoringClass(VALUE_TO_TEST)
    If CreateStoringClass(VALUE_TO_TEST).TheValue <> VALUE_TO_TEST Then
        Debug.Print "This is wrong"
    Else
        Debug.Print "This is correct"
    End If
End Sub
^ doesn't
 
Stupid bi-directional clipboard...
 
ok even better
 
12:25 AM
Works in 32-bit Excel.
 
ok now delete the Class_Terminate sub in the class
(I know it's empty)
on x64 it changes the behavior
i.e. removing it makes it work again
 
Same result on 32-bit - "This is correct"
 
ok good
MS broke VBA7... big time
and nobody noticed
 
that shows how often they use classes in VBA, I guess.
 
lol yeah
 
12:28 AM
^
 
if you can prove it causes a buffer overrun, it'll be almost a certainty they will fix it
 
The Terminate thing is what I don't get, because it's acting like it doesn't get fully initialized.
 
@this I don't even know what that is
 
or any security holes, really.
 
12:29 AM
If I can prove it causes a buffer overrun, I'll make them email it to themselves...
 
The point is that if you can show that it's a security-related hole, they will do everything in their powers to fix it.
 
including shipping a VBA8?
:D
 
lol. i wish
more likely, they'd ship a patch of 7.1 VBA? 7.2?
whatever it's now
 
Question re #4299: Given class Foo that implements IBar and given the procedure:
Sub FooBar(ByRef x As Foo)
    x.SomeIBarMethod
    Set x = New Foo
End Sub
Do you return the result 'Foo' can be declared as 'IBar'?
 
if SomeIBarMethod is declared on IBar, I don't see why not
 
12:34 AM
My thought was that it could break the caller.
 
right... need to make sure all member calls are also on that interface
but then you're looking at a ByRef parameter...
 
like, if you sort that one out, might as well fix the false positives for byref-assigned variables reported as unassigned
#NotTrivial
 
Woah. You should put a Debug.Print "Terminating" into that buggy 64-bit code and step through it with the debugger.
 
not there yet lol, refactoring the thing to death...
but I imagine it's terminating too soon?
 
12:39 AM
Yep - on the CreateStoringClass(VALUE_TO_TEST) line.
 
I knew to expect that, ....just not why
 
I should put it in a tight loop and see if it leaks memory.
 
@ThunderFrame will want to see this
 
I almost wonder if it's calling AddRef on the wrong instance.
Like if it screwed up on what pointer it was supposed to be using.
 
off-by-32-ish?
 
12:42 AM
Something like that.
Actually, I'm not convinced that's a bug as much as undefined behavior.
 
No Class_Terminate handler, no local variable: OK
With Class_Terminate handler, no local variable: terminatingSurprise!
No Class_Terminate handler, with local variable: OK
With Class_Terminate handler, with local variable: OK
terminating
 
The spec says nothing of the lifespan of a transient object reference that I can find.
 
but the behavior being inconsistent between 32 and 64 bit hosts is a problem
 
There's no reason for ShortTest to bump a reference for it because it isn't holding one. That means it's free to be disposed.
 
except the refcount should account for the .Value member call, no?
 
12:52 AM
Inconsistency is the hallmark of undefined behavior. You could make the argument that the 32-bit version is wrong.
@MathieuGuindon Does it scope down to the LoC?
 
What is the standard procedure for updating my local repository from the remote?
 
@jcrizk do you have local changes?
 
I mean, With holds a reference by spec. If?
 
I do, but the problem I was working on has been solved by some other solution
 
do you have rubberduck-vba/Rubberduck defined as upstream?
 
12:54 AM
Probably not, unless this is done automatically
 
git remote -v
 
git remote add upstream github.com/rubberduck-vba/Rubberduck.git
git fetch upstream
git checkout next
git merge upstream/next
 
^ well, there ya go :)
 
Optionally solve merge conflicts.
 
Thanks!
 
12:57 AM
@Comintern so RD needs an inspection for inlined member calls, on user objects (?), I guess. "Object may get terminated before the member call is executed, on 64-bit hosts"
 
I was just thinking that.
MemberAccessWithoutHeldReferenceInspection
What I want to know is if it's creating the default instance to call the Property Get.
OK, what sort of WTFery is this?
Option Explicit
Private mValue As Boolean

Private Sub Class_Initialize()
    Debug.Print "Initializing"
End Sub

Private Sub Class_Terminate()
    Debug.Print "Terminating"
End Sub

Public Property Get TheValue() As Boolean
    Debug.Print "Accessing TheValue"
    TheValue = mValue
End Property

Public Property Let TheValue(ByVal value As Boolean)
    Debug.Print "Setting TheValue"
    mValue = value
End Property
Output:
Value to check: True
Initializing
Setting TheValue
Accessing TheValue
Terminating
This is wrong
 
confirmed, With block works as intended
@Comintern wrong because the.. huh wait a sec
it's accessing the value before it nukes the instance???
 
that means the correct value is on the stack then
 
I don't follow. This seems expected?
 
1:05 AM
up to This is wrong, yes
 
Just to confirm:
Option Explicit
Private mValue As Boolean
Private instance As Integer

Private Sub Class_Initialize()
    Static ctor As Integer
    ctor = ctor + 1
    instance = ctor
    Debug.Print "Initializing " & instance
End Sub

Private Sub Class_Terminate()
    Debug.Print "Terminating " & instance
End Sub

Public Property Get TheValue() As Boolean
    Debug.Print "Accessing TheValue " & instance
    TheValue = mValue
End Property

Public Property Let TheValue(ByVal value As Boolean)
    Debug.Print "Setting TheValue " & instance
Only 1 is created.
Value to check: True
Initializing 1
Setting TheValue 1
Accessing TheValue 1
Terminating 1
This is wrong
 
@MathieuGuindon but, This is wrong is outputted after the if statement....
so it has left the town...
 
i.e. the stack goes poof somewhere between the function returning the reference and the member call being made
or the wrong value is read from it
what if the type was Long instead of Boolean?
 
And on top of that, TheValue appears to be reading from uninitialized memory.
 
from a legal chunk of uninitialized memory, right? otherwise we'd long have gone down in flames..
can't believe we're just now witnessing undefined behavior in VBA
 
1:11 AM
Value to check: True
Initialized
Setting the value
Getting the value
Getting the result
Terminated
This is correct
(this is on 32-bit host, though)
using this version of test:
Function ShortResult() As Boolean
    Debug.Print "Getting the result"
    ShortResult = True
End Function

Sub ShortTest1()
    Const VALUE_TO_TEST As Boolean = True
    Debug.Print "Value to check: " & VALUE_TO_TEST

    If CreateStoringClass(VALUE_TO_TEST).TheValue <> ShortResult Then
        Debug.Print "This is wrong"
    Else
        Debug.Print "This is correct"
    End If
End Sub
 
Same thing with a Long.
Value to check: 42
Initializing
Setting TheValue
Accessing TheValue
Terminating
This is wrong
 
yeah OP said 32-bit worked fine
@Comintern sucks we can't know the value without pulling a local variable though
 
IKR?
 
@MathieuGuindon that's why I used function above
Another idea -- wrap the expression in a function: If StoreTheResult(CreateStoringClass(VALUE_TO_TEST).TheValue <> ShortResult) Then
(actually we don't need the If really)
 
Noob question: Do I create my own branch to work in and then update stuff to the 'next' branch or do I work directly in the 'next' branch?
I've been working in the 'next' branch the entire time lol
 
1:15 AM
always make your own branch
 
gotcha
 
I had to do this at work, and then I was like 'woah wait, I think I need to do that here'
 
I'll learn that lesson... eventually
 
in fact, it's OK to have several branches at same time.
When in doubt, think octocat!
 
1:17 AM
by keeping your next clean in sync with upstream, you make it much easier to make a new branch at any time
 
Is there a naming convention we use or no?
for branches
or just do /whatever/your/heart/desires/.jpg?
 
witty is always a winner
 
@MathieuGuindon well, tbh, when I start a new branch, i always pull from RD's next, not my local next.
 
last time I did that my origin was set to upstream and my life was a nightmare
 
ouch
probably because it's set to track
 
1:21 AM
 
Australia?
 
No clue why it uploads upside down. I wasn't in Australia when I took that photo.
Sign was on the way to the Grand Canyon for our summer trip.
 
I think you don't need any more beers.
 
1:23 AM
Best sign I saw recently was on a car repair place: "Our oil changes are gluten free!"
I wanted to get a pic, but I was driving.
 
gosh gmail "smart compose" is the most annoying thing since RD's borked AC
 
My fork on github updates as you guys make changes, right?
 
no
it updates when you pull from upstream and then push to origin
(or if you make & merge a PR in your repo - which is how I was updating it until the merry folks here taught me better)
 
I gotcha
 
I swear one of these days I'm going to start remembering to close Excel before building...
 
1:36 AM
lol
 
@Comintern you aren't alone.
I wonder if the deployment should have a pre-build event to run posh
hey jerkface! Shut down your crap before building!
 
nah
you just wait out the 10 build failures, it's on you
(ps - you close Excel before that, it builds correctly ;-)
 
I'd be slightly more annoyed if I were building Excel.
That's gotta take a while...
 
the thing is that it doesn't just straight up and die
it takes a long pause before it finally dies
rattling the locked door
 
that's RD tearing down, no?
 
1:39 AM
No, it's the build trying to overwrite the in-use .dll.
 
no
^^
 
Is there a way in VS I can check to see if my version of RD is correct? I just want to quadruple check that I did this correctly before I start looking for something to work on
 
And the thing is, no matter how fast I try to close it before it barfs, it's never fast enough. It's like it waits for the IO to complete, but then doesn't care.
 
Yeah that's exactly what I saw
the only hope is to close it before you start the deployment project build
 
@jcrizk I usually just push back to origin and see if I'm even or ahead of next.
 
1:40 AM
but once it has started, it's too late.
@jcrizk remember to make Rubberduck.Deployment your startup project and clean & build
 
@Comintern ok I get the local variable thing. the part that eludes me is the different behavior when there is vs when there isn't a Terminate handler (be it empty or not)
that can't be "just" undefined behavior
 
Undefined compile-time behavior as opposed to run-time behavior?
For example, overflow behavior in C is undefined, but that means that any implementation of a C compiler can do whatever it wants when it encounters it.
 
"Undefined" is just that - it can manifest any behavior.
 
1:56 AM
For the tuple that returns from VBACodeString.Parser.Parse should I be looking at the parseTree to figure out how to navigate it for module declarations?
 
Huh. Just found a resolver bug.
RD apparently allows you to declare an interface from a standard module.
 
wut
seems a rather trivial fix
 
I screwed up my copy-pasta test setup and accidentally implemented a standard module.
It was fine until I tried to cast it to a ClassModuleDeclaration.
I'm not even sure I'd be worried about it (doesn't compile) if there wasn't other code that worked on the assumption that the cast succeeds.
 
> Given `Class1` with a `Class_Terminate` handler (doesn't matter what's in it - same result with it being empty/no-op ...but it needs to be there):

```vb
Option Explicit
Private mFoo As Long

Public Property Get Foo() As Long
Debug.Print "Getting Foo"
Foo = mFoo
End Property

Public Property Let Foo(ByVal value As Long)
Debug.Print "Assigning Foo"
mFoo = value
End Property

Private Sub Class_Initialize()
Debug.Print "Initializing"
End Sub

Private Sub Cl
 
did I get this all right?
 
2:10 AM
rubberduck-vba:next is the the original project's 'next' branch, correct?
 
@MathieuGuindon Looks good to me.
 
@jcrizk yup
 
cool
 
assuming it's pointing to github.com/rubberduck-vba/rubberduck.git
 
had to do a bit of reading to understand some of the terms lol
yes
 
2:11 AM
that's "upstream"
 
"Surprise!" is much better than "This is wrong".
 
"origin" is your fork
 
Should the implement interface refactoring be making the implementations private?
 
meaning?
IFoo_Bar should be private, yes
 
In that case, shouldn't it also implement the Public Bar member?
 
2:17 AM
?
I'm missing something
'IFoo.cls
Option Explicit

Public Sub Bar()
End Sub
'Class1.cls
Option Explicit
Implements IFoo

Private Sub IFoo_Bar()
    'todo
End Sub
implement interface, or extract interface?
 
Implement.
Implements IBar

Public Property Get Bar() As Long
End Property

Public Property Let Bar(ByRef rhs As Long)
End Property

Private Property Get IBar_Bar() As Long
End Property

Private Property Let IBar_Bar(ByRef rhs As Long)
End Property
^ can be used as both a Foo and an IBar.
 
ok but what if you also implements IOtherBar that also has a Bar property?
 
That's just IOtherBar_Bar,
 
was Public Property Get|Let Bar added by the refactoring?
 
If you Dim x As Foo (Foo implements IBar), you can't use Foo.Bar - it gives member not found.
 
2:22 AM
(IMO it shouldn't be)
good. code against the interface!
 
No, I added that.
So you have a co-class with no public members?
 
I don't think implement interface should do more than implementing the interface it's told to implement
who says I want the same members on the co-class?
 
COM?
 
lol
wait, really?
 
Yeah. A coclass is just a collection of implemented interfaces.
You can't call it's members directly - it can't even have it's own members.
 
2:25 AM
hmm, actually my typical interface-implementing class would have the interface members, and then some - e.g. interface has Property Get, coclass has Property Let as well
 
That's why the VBA behavior is kind of weird.
 
coclass is its own interface
 
coclass is a default interface.
Technically, I think it simply means that it can be instantiated.
 
FTR I'm completely foggy about the term "coclass" - never heard it before you guys brought it up in here :)
 
> The Component Object Model defines a class as an implementation that allows QueryInterface between a set of interfaces.
A coclass can have a class factory - an interface can't.
 
2:29 AM
there is no interface then?
 
There is, it always exposes IDispatch and IUnknown. There's nothing that says it needs to expose anything else.
In the example above, VBA creates a default _Foo interface with no public members, then also implements IBar.
So in the vtable, the _Foo table is basically empty. You can only use it from the IBar pointer.
 
makes sense
 
I take that back. _Foo is empty except for the IUnknown and IDispatch members, which are restricted.
When you new up a Foo, you get a pointer to the default interface _Foo.
 
I cleaned & built, but I get a bunch of errors as I build (36 errors). 11 succeeded and 8 up-to-date.
 
that's 36 warnings, and 0 errors :)
 
2:35 AM
good point
ignore?
 
If you assign it to the variable typed to the interface, it implicitly casts it.
Dim x As IBar
Set x = New Foo  '<-- Implicit cast.
 
@jcrizk yeah. although.. feel free to clean them up :)
@Comintern as far as VBA is concerned, that's as explicit as a cast gets though
 
Right, that's not a problem in VBA.
Because VBA hides the default interface completely.
It's like var Foo = new Foo() as _Foo
The New calls the ctor to create the concrete instance, and then it returns the default interface _Foo, which VBA tucks under the rug.
 
^ that was the missing piece
 
But, since VBA doesn't do real inheritance, _Foo doesn't implement IBar.
Foo the coclass implements IBar, but _Foo the default interface doesn't.
Excel coclasses are a good example:
[
  uuid(00020820-0000-0000-C000-000000000046),
  helpcontext(0x0002a410)
]
coclass Worksheet {
    [default] interface _Worksheet;
    [default, source] dispinterface DocEvents;
};
 
2:44 AM
i opened excel to see what changed and i see a vba project named FUNCRES.XLAM. is that supposed to be there?
 
it's an add-in, it would be there with or without Rubberduck
 
pffffff, that's part of the statistics addin I got for my statistics class lol
ffs
 
OMG WTF
I assume we can blame Java for inspiring this code "fixer"
@Hosch250 ^^
 
...and crap. Resolver is busted.
Sub Testing()
    Dim underTest As Foo
    underTest.Bar = 42
    Debug.Print underTest.Bar
End Sub
^ No reference to .Bar's Property Get.
@MathieuGuindon OMG! My eyes!!!
 
3:01 AM
> I don't believe these are creating references at all. I just discovered while hacking on #4299 that the following code doesn't generate an identifier reference for the `Property Get` on the `Debug.Print underTest.Bar` line of the code below:

```
Sub Testing()
Dim underTest As Foo
Set underTest = New Foo
underTest.Bar = 42
Debug.Print underTest.Bar
End Sub
```
 
@Duga wait how does that happen without breaking a single test?
 
It broke a single test apparently.
 
3:13 AM
Damnit - it doesn't even catch the identifier reference for underTest.
 
wouldn't that wreck pretty much every inspection test?
ok 1 red test, but like 2500 yellow?
 
I think it would be more likely to break quick-fixes.
 
and refactorings, and literally everything
 
        [Test]
        [Category("Inspections")]
        public void ReferenceCountIsLegit()
        {
            const string inputCode =
                @"Sub Testing()
    Dim underTest As Foo
    Set underTest = New Foo
    underTest.Bar = 42
    Debug.Print underTest.Bar
End Sub
";

            using (var state = ArrangeParserAndParse(inputCode))
            {
                var declaration = state.AllUserDeclarations.FirstOrDefault(x => x.IdentifierName.Equals("underTest"));

                Assert.AreEqual(4, declaration.References.Count());
An exception of type 'NUnit.Framework.AssertionException' occurred in nunit.framework.dll but was not handled in user code
  Expected: 4
  But was:  2
 
I count 3 though...
 
3:25 AM
Oh, yeah. Typo.
 
@IvenBach found the bug
            if (e.Character != '\b' && !result.CaretLine.EndsWith($"{pair.OpeningChar}{pair.ClosingChar}"))
            {
                // VBE eats it. just bail out.
                return null;
            }
^^ the Me.Range(|) completion for " enters that condition
 
What does it eat? The \b?
 
except at that point the "" is already in place, and returning null leaves e.Handled false
@Comintern trailing ()
 
Oh wait, use your reading skills, @Comintern.
 
I'll make that explicit
Me.Range ("|")
and that looks awkward AF
but it's correct
VBE prettifies it back to Me.Range("") after adding a member call
 
3:34 AM
I think I know why.
It can't determine if it's an indexer or argument list until the argument list is completed.
Their resolver sucks.
 
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4418?src=pr&el=h1) Report
> Merging [#4418](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4418?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/f38ebf776c9de99883f2e3aca5e2291f0569bded?src=pr&el=desc) will **increase** coverage by `0.15%`.
> The diff coverage is `56.03%`.


```diff
@@ Coverage Diff @@
## next #4418 +/- ##
=======================
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4418?src=pr&el=h1) Report
> Merging [#4418](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4418?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/f38ebf776c9de99883f2e3aca5e2291f0569bded?src=pr&el=desc) will **increase** coverage by `0.15%`.
> The diff coverage is `56.03%`.


```diff
@@ Coverage Diff @@
## next #4418 +/- ##
=======================
 
I think this is it
I'll download that installer at work tomorrow, and play with it in every way I can think of during lunch - if all goes well I'm good with merging it as-is.
TTGTB
 
night.
 
huh, we lost another star apparently
why is it that every single time part of me is like "damn, we're still not good enough, that's why"
 
Meh. That's why I've been going after the bug queue.
I really need to take on the default member access at some point.
 
3:45 AM
@Comintern thanks for that. I need to make a bugfix PR too.
 
[rubberduck-vba/Rubberduck] build for commit ab56bcf9 on unknown branch: AppVeyor build succeeded
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4418?src=pr&el=h1) Report
> Merging [#4418](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4418?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/f38ebf776c9de99883f2e3aca5e2291f0569bded?src=pr&el=desc) will **increase** coverage by `0.28%`.
> The diff coverage is `56.03%`.


```diff
@@ Coverage Diff @@
## next #4418 +/- ##
=========================
[rubberduck-vba/Rubberduck] build for commit ab56bcf9 on unknown branch: 60.2% (target 0%)
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4418?src=pr&el=h1) Report
> Merging [#4418](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4418?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/f38ebf776c9de99883f2e3aca5e2291f0569bded?src=pr&el=desc) will **increase** coverage by `0.28%`.
> The diff coverage is `56.03%`.


```diff
@@ Coverage Diff @@
## next #4418 +/- ##
=========================
 
@MathieuGuindon doubled up Foo? Where is has a public auto prop and private backing field with public accessors?
 
4:00 AM
@IvenBach the "fix" turned autoproperties into methods... like, like what they compile down to. useless, Javaesque monstrosity.
</mug>
 
Night mug. I'll pester you about parse tree stuff tomorrow.
 
 
2 hours later…
5:43 AM
I've put about as much lipstick on this pig as it can hold. Gotta wait for it to dry overnight before applying more coats.
github.com/IvenBach/Rubberduck/blob/… works with the simplistic code:
Attribute VB_Name = "Module1"
'@Folder("Foo")
Option Explicit

Public Sub PrintTest()
    Debug.Print "Test"
End Sub
It's a WIP but be honest with how bad the nasty/ugly the pig is.
</iven>
@pond Thanks for helping me get through my derpy block with the Parse method and better groking delegates and the various ways they can be used.
</iven-out-for-real>
 
6:09 AM
> I just realized that this change has the added benefit that we no longer cache objects we change while parsing. More precisely, previously we had to worry about the references we save on the declarations. These got removed on the each load, whoch made it inherently unsafe to run tests in parallel. Now, this is a non-issue because we create the declarations each time anew from the cached command projects.
 
6:45 AM
@MathieuGuindon In your little VBA bug MCVE, what happens if you Debug.Print the value in the property get? (and maybe the termerminste)
 
7:08 AM
@Comintern In that test, why not state.DeclatationFinder.MatchName?
 
7:37 AM
@this: Reacting to:
"@M.Doerner for me at least, I can confirm that it works. @SonGokussj4 can you check what the Rubberduck.log says?"

Well, that's the first thing that came to my mind. But it does not create the log...
Within AppData\Roaming\Rubberduck\Logs

I tried new pull & rebuliid but still nothing.
 
The reason that there is no log is that the default setting is no log.
 
 
3 hours later…
11:57 AM
14 hours ago, by Hosch250
Most of the fluff has been cut away because C# can just figure it out.
This sounds a lot like letting VBA use the default member instead of specifying .Value...
OK, I was reading through the discussions with @IvenBach last night about lambdas.
In a nutshell (I don't want to rehash the full 3-4 hour lesson), a lambda is essentially defining an inline function for use somewhere?
If that's the case, that's a one-time use, right?
what if I need to do that same thing more than once, wouldn't I be better off writing an actual function?
 
you define this function in one place, yes, but it may or may not be called n times.
depending on the implementation.
 
if that's the case, wouldn't an actual function make the code more clear and easier to maintain?
 

« first day (1593 days earlier)      last day (1587 days later) »