Using 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 ...
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.
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.
@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.)
> 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.
> 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.
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
> **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.
VBA Rubberducking
VBA Rubberducking