« first day (2299 days earlier)      last day (68 days later) » 

12:01 AM
RELOAD!
[rubberduck-vba/Rubberduck] 32 issue comments.
[Minesweeper] Games Played: 139, Bombs Used: 104, Moves Performed: 19337, New Users: 12
 
 
4 hours later…
 
 
3 hours later…
6:47 AM
Reached page 77 of Working Effectively With Legacy Code. It’s making sense.
Thanks again to introducing the concepts of SRP. Do one thing. Make your method do what it says.
It’s a bit of #VujaDe to now have words for some of the techniques I’ve been doing without realizing it. Thanks @pond.
Tired-Iven is grateful to all the generous and helpful ducks.</night>
 
 
5 hours later…
11:22 AM
@IvenBach interesting. Reset my perspective on what Tech-Debt is (or should be)
 
 
2 hours later…
1:19 PM
quack
 
1:32 PM
@Cyril someone who claims to practice medicine but is a fraudulent charlatan.
 
1:57 PM
1
Q: how to get median value more fast

FabrizioUsing Excel, I'one sheet("db") with data extract from MES, I've to analize this data and I need: Articolo, Fase, Tipo Confezione, TURNO, Macchina, avg and median. I searc everywhere ho to get median whit sql but I found only how to get median for on item alone. Then I wrote this code, and I loop ...

 
 
2 hours later…
3:46 PM
Excel is complaining it's Monday by crashing after a single edit. This bodes well for the week.
3
 
at least you are starting the week with a low expectation.
 
@this is that different for you?
 
it's better than starting out with a false hope only to be sucker-punched later?
 
4:21 PM
I sense a kindred cynic.
 
Sep 14 at 21:15, by this
ugh, why must you suck, Mister Monday?
it's still morning and i'm already having a headache
 
5:03 PM
Been getting crashes at startup lately (latest release), seemingly caused by the initial parse kicking in; manually loading RD after VBE startup fixes it, but I think I'd rather have RD stop trying to automatically parse at startup.
In other news I've made a couple of changes to the MVVM project, streamlined event propagation (like, big time), and added a bunch of unit tests (it found & fixed bugs!)... I've also created a private repo for it under the RD org but didn't initialize it yet, will do that later this week.
2
2nd MVVM article (part 1: unit testing) is under way, too.
been way too long since I wrote anything about unit testing VBA code that wasn't something just mentioned in passing.
Also the "expected error" test template needs a kick in the teeth
 
@MathieuGuindon well, you'll need to add some teeth to the template first in order to kick it.
Looking forward to the part 2!
I'm just curious - does this seems sane thing to do?
Public Enum FooResponse
  UseDefault = 0
  Continue = 1
  Cancel = 2
End Enum

Public Enum BarResponse
  UseDefault = 0
  Continue = 1
  Cancel = 2
End Enum

Public Sub DoFoo(Response As FooResponse)
  Select Case Response
     Case FooResponse.UseDefault
        'Do foo the default way
     Case FooResponse.Continue
        'Meh
     Case FooResponse.Cancel
       'Stop, something went wrong!
  End Select
End Sub

Public Sub DoBar(Response As BarResponse)
  Select Case Response
     Case BarResponse.UseDefault
assume that Foo and Bar are two wildly different things (might be even in different classes/modules although right now it's in one module). My thinking is that while the enums overlaps, there's no guarantee they won't diverge in future.
 
5:32 PM
What you're doing sounds sane. If it can/may/might one day diverge I'd rather know it up front. That way if when they do diverge you don't have to find every single usage and separate them.
 
5:46 PM
@this what's the basis for splitting Foo & Bar response enums in the first place?
@IvenBach eh, enum type safety is inexistent, it's just a Long integer value - the danger would be if one of the same-name values were to start having different underlying values... I'd try to make the enum fit all uses cases I think.
 
they represent a different step in a pipeline. Imagine them as a event (though they are not implemented as event) to where external user code could change the response to do something differently. Right now, they are the same but my thinking was "what if I realize I need another enum value for this one step?"
in other steps in the pipeline there are indeed different choices (and they have their dedicated enum). It's just that for those 2 particular steps, there's no difference.
one sideeffect of the enums like that is that you would get an ambiguous reference error if you only referenced the enum member's name. This requires you to fully qualify the enum (hey, just like .NET! Sorta.)
 
^ I find myself doing that even when it's not mandatory.
Belts-n-suspenders has saved me a couple times now.
 
wouldn't stop you from referencing AUniquelyNamedEnumMember without the enum's name, though. So it's not 100% protection.
I find it odd that my Windows 7 still is apparently getting & installing updates, even though it EOL'd months ago.
 
 
2 hours later…
8:01 PM
I'm derping hard on how to properly implement Public Property Get NewEnum() As IUnknown for iteration.
 
8:29 PM
@this seems reasonable. Reminds me a bit of FileVisitResult and DirectoryVisitResult from the Java NIO API for directory traversal
 
interesting; found FileVisitResult but not DirectoryVisitResult....
 
8:44 PM
sigh... brain why you gotta do me dirty like that?
directories are files for java...
 
8:57 PM
@IvenBach make it return the [_NewEnum] hidden member of your internal collection
(having "show hidden members" ticked in the object browser helps)
 
just to spell this out - you can't implement enumeration yourself within VBA. You have to piggyback from a collection that does, like VBA.Collection.
Interesting - I wonder what else implements it. It doesn't appear to me that Scripting.Dictionary does.
 
That would be why Tim's drop-in can't foreach?
 
I think you can foreach over an array of variants?
at least I think that's how you For Each over the Items property of the Scripting.Dictionary, which is an array of Variants.
so I think it won't work if you For Each item In myDictionary; you'll have to do For Each item In myDictionary.Items
 
Yeah. Well dictionary iteration is weird in every way anyway =)
But there's an open bug in Tim's repo about it (#8 IIRC)
 
yeah. I'll be honest - the fact that foreach a IDictionary in C# returns a KVP annoys me.
I understand why but it's still annoying to have to go to Values
 
9:32 PM
@this Took me ~1 hour of ducking around with it before switched over to a collection...
I had this happen the last time I did it too... :le-sigh:
Frustration aside, it feels pretty good being able to tackle these after struggling for a bit.
 
9:52 PM
> This PR refactors/rewrites the EncapsulateFieldRefactoring (EF) to conform to the Split Refactoring design (#5387). The EncapsulateFieldRefactoringAction is now a facade object to coordinate two underlying refactoring actions: the EncapsulateFieldUseBackingFieldRefactoringAction and the EncapsulateFieldUseBackingUDTMemberRefactoringAction. The PR is focused primarily on reducing the technical debt of being the only 'non-split' refactoring. Consequently, it does not add any new...
features or close any issues. The intent is that the EF will operate identically before and after it is merged. Even so, as part of the migration to the split refactoring design, the PR includes the following internal improvements: - Incorporates use of CW/DI and factories for creating objects. - Incorporates use of IRefactoringPreviewProvider to generate previews - Retains the existing battery of EF tests. (Some re-organization but otherwise left essentially unchanged). - Retains the...
properties and method signatures used by the EncapsulateFieldView and EncapsulateFieldViewModel to isolate the UI from all changes. Not an improvement per se, but there is/was some work going on with the UI, and I wanted the PR to avoid impacting that work. Note: A parallel/personal goal of this refactoring was to evaluate and make every class associated with the refactoring more focused and, as a result, smaller. Consequently, I had some hope for a net decrease in lines of code (LOC) but...
it turned out that there was a net increase instead. Some quick analysis revealed that the addition of tests, factories, and preview providers account for nearly the entire net LOC increase - with the added test content comprising most of the total.
 
10:15 PM
[rubberduck-vba/Rubberduck] build for commit b227806b on unknown branch: AppVeyor build succeeded
> At the moment, the value added by this PR is is significantly limited by the fact that the two refactorings that would it benefit most are not ready to use it. And, when they are, will probably drive non-trivial changes to the current implementation:

- `EncapsulateFieldRefactoring` : #5578 should precede this PR.
- `MoveMemberRefactoring`: is still on my local machine and will be refactored significantly based on the outcome of the `EncapsulateFieldRefactoring` PR.
 
Duck check: Does RD have parametric capabilities for unit tests?
 
we discussed it multiple times
Reasonably sure we don't have anything implemented yet, though.
 
But it's never been implemented.
I was afraid of that.
Must. Carve. Out. Time. To. Implement. Features. I. Need.
 
worst case you can try to parameterize yourself, it's just that handyman parameterization tends to break at the first failure, which is not what you want
 
I don't like naming Foo_option1_test_is_valid()
 
10:27 PM
when I had to bodge something like that I implemented the different cases as a loop inside a method
that parent method was the test case Foo_is_valid()
it's a bit sucky, but it can be dealt with
 
Both ways have their respective nastiness. #PickYerNasty
 
yeap
 
10:43 PM
@IvenBach funny you mention that... I mention the need for it in my draft :)
 
10:56 PM
Just hit the lotto already Mug. That way you get to work full time on RD.
 
> **Justification**
Working with C# in VS I've started developing a few habits that I don't immediately see until I :derp: and realize I'm in VBA-landia. A toggle, disabled by default for new users, to enable this would be a nice Quality of Life (QoL) improvement.

**Description**
`foo == bar` --> `foo = bar`
`foreach bar in foo` --> `for each bar in foo` Missing the space within foreach
`counter++` --> `counter = counter + 1` Decrementing operator as well
> **Justification**
Sitting there pressing `F10` or `F11` several wondering why it's not stepping through the code. Then I realize I'm working in VBA-landia which leaves me feeling smrt.

**Description**
Help those with VS habits with a toggle to enable mapping keys to their VBA equivalent.
 
I know we'd mentioned it a few times before.
 
11:41 PM
thanks for that :)
@IvenBach how I wish!!
 
@MathieuGuindon what's the current job status anyways?
 

« first day (2299 days earlier)      last day (68 days later) »