« first day (1753 days earlier)      last day (84 days later) » 

12:01 AM
RELOAD!
[banane-io/PDB] 1 commit. 1 addition. 1 deletion.
[skiwi2/pokemon-buylist] 13 commits. 4478 additions. 281 deletions.
[Zomis/FactorioMods] 3 commits. 5 additions. 1 deletion.
[Zomis/minesweeper-ai-mario\‌​] 6 commits. 6346 additions. 2 deletions.
Minesweeper: Games Played: 163, Bombs Used: 110, Moves Performed: 22934
 
in Coding Projects and Vue.js Heaven :), 23 secs ago, by Simon Forsberg
@Duga NOT THAT BLOODY BACKSLASH BUG AGAIN!
 
 
1 hour later…
1:09 AM
You sure chrome isn’t masquerading under that process?
 
 
2 hours later…
here we go!
 
Merge pull request #4873 from Vogel612/v2.4.1bump

Bump version to 2.4.1
 
4:18 AM
[rubberduck-vba/Rubberduck] build for commit ace6df1c on next: AppVeyor build succeeded
[rubberduck-vba/Rubberduck] build for commit ace6df1c on next: 64.54% (target 0%)
 
hmm, should we not fix the GroupingGrid issue before green-releasing though?
 
4:48 AM
Little late for that, is it not?
 
 
4 hours later…
8:56 AM
Hi there. Just referring to your pieces of advice so that you know how to too :-) About integrating .DLL files into .EXE file.

So after few hours and many angry moments it finally works.
Using: https://bitbucket.org/wvd-vegt/ilmergegui
1) Installed ILMerge from the link in repo (official MS, admin rights neede even for "user installation"...)
2) Downloaded ILMerge-gui portable
3) just select EXE and all DLL, drop it there
4) specify where to save the merged .EXE file and hit Merge.

Works like a charm.
 
 
4 hours later…
1:04 PM
[rubberduck-vba/Rubberduck] Vogel612 pushed 317 commits to master
Merge pull request #4863 from rubberduck-vba/next

Release 2.4.1

Co-authored-by: <bgclothier@gmail.com>
Co-authored-by: Max Dörner <maxdoerner@gmx.net>
Co-authored-by: Mathieu Guindon <retailcoder@gmail.com>
Co-authored-by: <brent.mckibbin@gmail.com>
Co-authored-by: Jonas <Inarion@fastmail.fm>
 
@Duga considering that the version bump was merged, I'm merging this now..
 
[rubberduck-vba/Rubberduck] build for commit 2925035f on master: GitHub Pages successfully built your site.
 
We're behind schedule for two weeks already anyways...
 
1:24 PM
That feeling when you get a ticket: Severity: Minor; Priority: Resolve ASAP.
 
[rubberduck-vba/Rubberduck] build for commit 2925035f on master: AppVeyor build succeeded
[rubberduck-vba/Rubberduck] build for commit 2925035f on master: 64.53% (target 0%)
 
~sigh
urgency versus importance, I guess
 
1
Q: Public Function to remove empty or "" elements from a single dimension array

Samuel EversonI've written a function to remove empty or "" value elements from an array or in other words return an array consisting only of elements containing a value. Option Explicit Public Function RemoveBlanksFromArray(ByVal TheArray As Variant) As Variant Dim temp As Variant ReDim temp(LBoun...

 
1:43 PM
Oh, it's pretty important.
I accidentally prevented the user from entering decimal numbers in certain fields, so they can only enter integers.
OK, more accurately, I fixed the system that prevented users from entering decimals, and it was flagged like that in the wrong spot.
So the fix also "fixed" some fields that weren't supposed to be fixed.
 
2:09 PM
Question: should the build process be automatically green-releasing? The latest release is still a "draft".
 
that's correct.
release notes and tag need to be adjusted
 
oh, so that step is manual.
 
yes. appveyor can't really know where the release notes will be
unless we write the release notes and put them into the repo... but even then it's not really something we can automate completely with AV, I think
 
I should write a wiki page on how to release this so the git history doesn't look different for each damn release...
oh well ... paying work is calling.
 
@QuackExchange to me using a dictionary and returning an array of keys after iterating the original array would be the best option. Will write an answer when at work.
 
3:03 PM
Interesting. I just found out there's a UV item requesting a return of MDI to Excel.
 
What's MDI?
 
multiple document interface
e.g. windows in a window
 
wasn't that the windowing thing the VBE hacked around?
 
yeah VBE itself is MDI
 
MDIChildHack and all?
 
3:08 PM
but I think MDIChildHack is VBE thing
not a thing about MDIs in general
Not sure what MDIChildHack was meant to hack around exactly.
 
3:37 PM
My guess would be that it had something to do with docking.
 
Hmm. Didn't Office 2003 have docked panels in the MDI container?
Then again, I don't remember the panels being drag'n'drop-able
 
4:24 PM
Tried a fresh clone for RD and build on work box, same build errors. :+1: for consistency at least.
 
@Vogel612 thanks - I drafted the blog post last night, will finish & publish tonight
 
Would it be worthwhile to have examples of code inspections
 
Sub Foo()
    Dim bar as  Range
    Set bar = Range("A1")
    Debug.print bar
End Sub
 
plan is/was (?) to have them in xml-doc
 
4:30 PM
-_-
man something borked on one of our databases
 
@MathieuGuindon Where would those go in the code base?
 
i have this SSIS package that runs, it was running since sat
normally takes about 1-2 minutes
someone dumped a crapton of bad data into the table
and im not sure how
 
@IvenBach in ///<example> xml-doc tags
 
im assuming it was included in the import somehow
 
every inspection ideally also needs a <summary> tag
 
4:32 PM
Sorry #Words.
mkay. Then each would be with their own inspection.
 
yeah. most sensible place to put it IMO
 
That does seem apparent now that you stated it.
 
then the website can extract the content from xml-doc and generate a page for each inspection
I really need to fix the darn website
 
The /// xml-doc would go before the ctor github.com/rubberduck-vba/Rubberduck/blob/next/…?
 
@MathieuGuindon There's a ticket on GitHub for it :)
I really should help you with that now that I'm an "expert" at it.
 
4:39 PM
@IvenBach on top of public [sealed] class
 
:+1: thanks Mug.
 
4:58 PM
Thunder's icon for the splash screen does feel a bit intimidating: "Get yer code done right, or else..."
 
5:18 PM
It won't be there permanently, though. Not sure how long we'll keep it, though.
 
IDK either. OTOH it's nice to see his avatar there.. since, well, we're not going to be seeing it in here anymore :(
 
Yeah, true.
 
:'(
 
At the rate of our releases it could be there longer than we expect it to.
 
FWIW, I'd like the RD team to at least try and do a monthly release
 
5:29 PM
^
 
(which has no bearing on the memoriam splash, mind you)
 
IIRC, we only did that just after 2.0 came out.
During the 2.0 betas, we were doing weekly, or more often.
 
it doesn't have to be a huge release and we really do want to avoid doing any more big bang releases.
There's a reason why big bang release tend to fail
 
@Hosch250 was nice having a 40 hr/wk slave intern for that :)
 
Yep :)
 
5:30 PM
Was Chris still involved?
AIUI, he was big on consistent releases.
 
No.
I basically had free rein.
 
Gotcha
 
It was my internship, and I basically got tasked with releasing 2.0.
Mat was PM, but was too busy with work to program much.
 
Right how did you find the project and choose it for internship?
 
Uhhh, I was already a regular.
 
5:32 PM
That actually was 2 questions, sorry.
 
I wandered onto CR looking for a review of my asynchronous programming.
 
I asked because I recall you did not really do anything in VBA, so I assumed you came here via other avenues --- sound like CR was the avenue.
 
I quickly learned I had to learn about lots of things, and did. Eventually, I was looking for a more complex project than my personal one to expand my skills more.
Chris recruited me, and I worked on it over my next few college breaks.
Was it 2 or 3? I don't remember. One summer and one winter break for sure.
 
and that's where you got all your async/MT practices. :)
 
Yes.
 
5:34 PM
cool!
 
in other news, I'm considering adding a quickfix for the "keep it to yourself" inspection (form controls being treated as public fields), but early analysis shows that this would be essentially a "move member" refactoring, so... I think the best course of action might be to PR the inspection without a quickfix first, then do the refactoring, and then implement the quickfix. A single PR with a refactoring, an inspection and a quickfix would be too large for its own good, right?
 
Then, I couldn't land an internship because I didn't have a driver's license yet. I almost got one, I think, but they said I needed a license, and I didn't get past the in-person interview.
So, my professor said I could work on this, and Mat just had to agree to fill out a couple forms, and I got to work on it for 500 hours.
 
@Hosch250 I still have all the paper work somewhere :)
 
Me too, LOL.
I have all my digital files from college zipped up on OneDrive--and it's basically all of them, since I went online.
 
And I'm grateful for that. Don't think we could have gotten anywhere close to where we are because of your internship contributions which still is foundational.
 
5:36 PM
I should share my work logs I had to submit with y'all again.
 
@MathieuGuindon I think 3 PRs sounds good. But a bit fuzzy why it would be a "Move Member" refactoring. Isn't that more like "Change accessibility" refactoring?
 
I'm thinking the fix would be sort of like "encapsulate field", but for a Control declaration
whatever we do the controls will be public anyway
 
Yes, "Encapsulate field" makes more sense. Probably can just update the EncapsulateField to handle the control event handlers, so it has different caption but basically same refactoring logic.... right?
 
so the fix involves adding a property and replacing the external calls with calls for that property
where "move member" comes in, is that the ideal fix would be to pop a dialog and let the user pick controls whose state they want to extract to a new class
 
I see that's slightly from what I thought we were talking about - I was thinking of the event handler made (improperly) public.
 
5:41 PM
so the QF is like two steps: first encapsulate the controls, then move them to a new (or existing) class
oh, no, the inspection doesn't care for event handlers being public (IIRC there's another inspection for that) -- it's all about the controls themselves
 
and bear with me but I'm not sure I see the use of encapsulating the field unless you are actually moving it to another class. As you say it's public anyway, so Forms("foo").Controls("bar").Visible is legal even if we don't like that.
what we really want is a class that has ThisThing private variable set at the initialization, and we do ThisThing.Visible instead of Forms("foo").Controls("bar").Visible
Right?
 
You can see what I did starting here (go Previous--this one was released the week before my internship started, or something): github.com/rubberduck-vba/Rubberduck/releases?after=v2.0b
 
meh. what we want is for the form to deal with control visibility (i.e. UI concerns), and for some "model" to deal with "control values" -- exposing control values as readonly properties (on the form itself) is already a good step forward, even if the controls are public
so I want the QF to encapsulate the properties and move them to a model class
 
So encapulsating control means basically Public Property Get SomeValue() As Foo : SomeValue = Me.MyControl.Value : End Property then?
 
5:47 PM
Yes, model class would be better
The visible thing is for a different use case (e.g. a class to provide a standard behavior for a number of forms)
 
Exposing that kind of stuff as a properties as an alternative to direct access to the underlying controls would work well for both UserForms and Access form (bound one in particular).
Whether bound Access form needs a model, that's a matter I have not gotten around to.
 
I'm making it work with DeclarationType.Control declarations that have a DeclarationType.UserForm parent
that would exclude Access forms & reports
which... I think we're ok with
 
IIR, the issue I opened included both cases
 
databound forms would be better off with MVVM than MVP... and MVVM in VBA is... well, quite the hair-puller AFAICT
 
5:51 PM
We do want to encourage people to stop being loose-goosey with their access to controls whether it's forms or userforms
I can see inspections working for any type of controls but having different QFs
at least in the case of the moving to a model class
 
the results' Properties could hold the metadata needed for that
basically with the QF I'm thinking of, you could single-handedly extract the model off how the form's control values are being accessed from the client code
 
Yeah agreed. And that would be also useful in unbound Access form that are used as a dialog of sorts
 
I can totally see that inspection having both "Encapsulate control values" and "Extract control values to model class" QFs
@this not sure how to do that without hard-coding any host-specifics, or without making it work for any document module
 
The TypeLib APi will tell you that
it's just a matter of wiring it up
(which is another PR...)
 
5:58 PM
IKR?
So many things to do, so little time
Maybe we should be scouting colleges now... Find us another Hosch
 
another slave intern?
 
You have Iven ;)
 
I think Iven's kind of occupied with a job
 
^
 
Need a college kid who has a meal plan and plenty of free time
 
6:00 PM
And there's the issue with RD not building on my work box.
 
and willing to learn the harsh reality that working with legacy products isn't always purty.
I know. That is big puzzler.
 
VBA isn't cutting edge tech?</sarcasm>
 
Oh totally. Just let me finish building this flux capacitor and we can go back to the time when it was.
 
nooooooo!!! then we'd have to redo everything in VB6!
:D
 
@Hosch250 I'll also throw in the fact I've had to learn a lot just to learn what it is the code base is doing. You can call me the "Pitch drop learner".
 
6:03 PM
LOL.
Talking about that kind of thing... I went on a trailride on my horse yesterday.
Still a couple inches of snow and ice out. It was interesting, to say the least.
 
TBH, I don't think we even can have a RD using 97's specs. Even if it was done in VB6.
 
I rode bareback, which made it just a little more interesting... First time bareback on the trail, and I had to pick that day, LOL.
 
Sounds like it'd be hard on your nuts
 
Not too bad. Just a little interesting going up and down icy hills and through tangled branches when we had to go around ponds.
Almost got stuck in the branches a couple times.
Like Absalom, except not by my hair.
 
Well, Absalom lost his scalp, so.
 
 
1 hour later…
7:29 PM
TFW you realise you've over-engineered something and have to rip a bunch of work out to simplify :-(
 
8:20 PM
TFW...you dont have a face...
 
> It would also be quite nice if, like when saving, you are not prompted to select export folder each time. Save + Save As -> Export + Export As?
 
@KySoto ?
 
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4851?src=pr&el=h1) Report
> Merging [#4851](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4851?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/2925035f5210cb7f56792554a43f6e44052acb82?src=pr&el=desc) will **decrease** coverage by `0.07%`.
> The diff coverage is `69.22%`.


```diff
@@ Coverage Diff @@
## next #4851 +/- ##
=======================
> I still need to add some more test, but since we have released 2.4.1, I removed the draft status.
 
@mansellan just saying dumb things lol
 
> I still need to add some more tests, but since we have released 2.4.1, I removed the draft status.
 
8:30 PM
i do a lot of dumb your face jokes
 
@this Regarding my typeLib API PR, I am a bit unsure whether it is worth merging it before Wayn's PR. It will miss a few things, like all constants, and I am not too sure about the effect on the runtime of the parser.
 
@KySoto ah lol
 
@M.Doerner I suppose we could ping Wayne to see if he has any ETA. If he thinks it'll be longer still, we might as well just go ahead and merge the PR since it solves other problems. Alternatively, we could create a new branch and see how well your PR and his PR work together & solve problems.
Speaking of uncertainties - do you have any particular preference as to whether my COM commands PR should be merged before or after your refactoring PR?
 
> @WaynePhillipsEA there is some uncertainty as whether the PR should be merged before @MDoerner 's work in PR #4535 get merged. I know you've been busy so if we can get an idea of when you will finish the pending tasks for this PR to be ready for merging, that'd help us in planning for the next release -- we just had released 2.4.1 and would like those items included in the next release. Thanks!
 
8:49 PM
FWIW I'm holding off any work on Move Member until the refactorings PR is merged. I guess this pretty much means the "public form control access" inspection can be PRd as-is then (needs more tests though)
 
8:59 PM
[rubberduck-vba/Rubberduck] build for commit c7cc8f0b on unknown branch: AppVeyor build succeeded
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4851?src=pr&el=h1) Report
> Merging [#4851](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4851?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/2925035f5210cb7f56792554a43f6e44052acb82?src=pr&el=desc) will **decrease** coverage by `0.07%`.
> The diff coverage is `69.22%`.


```diff
@@ Coverage Diff @@
## next #4851 +/- ##
=======================
[rubberduck-vba/Rubberduck] build for commit c7cc8f0b on unknown branch: 64.46% (target 0%)
 
@this My typelib PR will need some more work before it is ready. However, as far as I understand Wayn's PR, how to treat vba classes will be different after that PR.
Btw, thanks for the ping.
 
Yeah, it would be. The change he made seems more logical, all things considered.
 
My PR originally really was not intended to deal with the problems of the typelibs for vba classes. Its main intent was to wire up the API in the parsing process.
 
9:15 PM
Yeah, and the changes to the VBA class declaration was more of a byproduct than than main focus of Wayne's PR, among few other things. Those would be welcome changes, and I would rather get it in sooner so we can benefit from the changes, not just for the caching COM project PR.
 
9:45 PM
Can anybody think of a situation in which a user defined module does not have a code module?
 
Can you create a userform without a code-behind?
 
I don't think so.
It is something the rename refactoring guards against.
I am currently writing tests for throwing the validation exception. However, I have no idea how get the code throwing that exception to be executed.
 
I suppose there might be a custom component that do not create an code module but I'm having hard time conceiving how it would be done.
 
I think I will just skip writing a test for it.
 
In Access, for example, one can create a form without a code-behind. However, in that case, no VBComponent object gets created. When you set the HasModule property to Yes via Access UI, it will create a VBComponent object with a corresponding CodeModule object.
In VB6, we have resources and few other types that do not have a code modules.
 
9:54 PM
I guess that check is probably there for the fear of ghost components.
 
But our refactoring most likely already excludes those types.
 
@this you mean someone like me that has free time?
 
Aren't you working a job already?
 
that said: I know the pain of working with legacy apps and technologies... I was born in it, molded by it
@this that's where the thing about the time comes from, yes
 
Yeah.
 
10:03 PM
like... my first professional tech stack was asp classic
And the first thing I did after finishing my education was starting to maintain a project that had been started before I was even born, soo ...
 
ASP classic is very enjoyable, indeed.
hmm should RD rubberduck VBScript in cASP....
Nah.
 
> Adding another issue here since this likely needs another unit test to handle this.

In vanilla VBE, if we type:

```
Public Sub Init()|
```

and type <kbd>arrow-up</kbd>, we get:

```
Public Sub Init()
|
End Sub
```

With feature auto-completion enabled, the behavior changes, and we end up with this:
```
|
Public Sub Init()
```

Missing the `End Sub` altogether. Curiously, this does not manifest if we do any further typing (e.g. editing the name). For example:

```
Pu
 
10:19 PM
Any suggestions for a built-in interface I could implement in the rename tests?
 
> @bclothier on one hand I'm thinking this needs to be handled by block completion.. On the other it's something that's really a consequence of SCP handling the parens completion here - the line being validated/prettified through SCP is preventing the vanilla-VBE block completion.

Feels like special-casing parameterless procedure blocks in SCP would be an overreach of SCP, and yet while putting that concern with block completion would make sense, it would also leave vanilla completion broken
 
@M.Doerner VBA.Collection is slim enough =)
 
I already found a very slim one: Excel.ColorScaleCriteria
It has only two members.
 
TBH, I had never heard about that one before.
 
10:29 PM
Must have something to do with the conditional formatting API
2007+ IIRC
 
wouldn't using Excel OM mean a slower unit test since you must load the library?
 
true that
 
In the rename tests, you either load Excel and VBA or no libraries.
 
sounds good
 
^
 
10:31 PM
I really do not feel inclined to hand-craft the declarations.
It is only two tests anyway.
 
Yeah that's... a large part of why a lot of tests work off mock-parsed code
 
I wonder how much speed up we would get from our 4000 tests if they used declarations bypassing the parsing altogether.
I seem to remember the inspections representing the half of it.
 
probably lots... but I don't think that's realistic until declarations have a full inheritance hierarchy... and inspector no longer gets declarations off the parser state
 
Yeah, and we would have to build something to make it easy to create declarations
because as it is now, writing mock code is much easier than constructing a bunch of declarations with 10000s of constructor parameters.
 
replacing the mock vbe builder with a declarations builder would be a massive perf gain... that's a lot of affected code though.
 
10:37 PM
probably not going to happen until RD 6.0
at which then we'll have 20000 tests and straining the AV limit
 
We actually need the tests we have right now anyway. They are just more like integreation/scenario tests instead of unit tests.
 
also... RPS would need a (test-only?) way to inject the declarations it needs to work with
(or to severe the inspector/RPS dependency)
 
i'll be honest, I'm having trouble visualizing how you can create declarations quickly and easily than a mock code input.
 
AFAIK, the Inspector requires the RPS primarily for state checking.
 
@this yeah the mock code is really convenient
 
10:40 PM
The RPS dependency of the inpections is in their own constructor, or rather or their base class.
 
hmm right, that's InspectionBase or something
 
I mean, a class module Foo with a private variable Bar, and a Public Property Get Baz, is already 4 declarations. Probably need a builder to make this convenient, but the way it is, we can copy'n'paste from the GH issue to create a new failing test.
We wouldn't be able to do that with a hand-crafted declaration.
Actually, there is an idea that'll get us the best of both worlds.
 
usability vs performance ...a fine balance =)
 
We keep using mock code but we serialize declarations (somehow)
so that when building, it can go off the serialized declarations directly, skipping the parsing.
 
@this a lot of them really just need one or two declarations though
 
10:42 PM
That is not that much faster.
 
Would the test still be valid without a proper parse tree?
 
AFAICS, most of the time in the unit tests is spend setting up all the mocks.
 
@this ParseTreeInspections wouldn't like it methinks
 
But hand-crafted declaration would mean less mocks, no?
@MathieuGuindon yeah, for sure.
 
Not the ones for functionality depending on the tree.
 
10:44 PM
that's the majority of them though.. right?
 
so in reality, hand-crafted declaration would only work for a subset of the tests.
 
Really, for inspections and quickfixes, we definetly need the end-to-end tests.
 
which makes the ROI even worse.
 
@M.Doerner agreed
 
10:45 PM
^
 
@this yeah considering the effort needed... probably not worth it
 
There are a few areas where real code is not necessary, though.
 
As far as it goes, maybe we could increase test performance by telling the parser to only run through a certain state?
 
IIRC, Comintern went with hand-crafted declarations for his CE tests.
 
I generally try to get away without parsing anything for utility components like the IProjectsRepository.
 
10:46 PM
All the "declaration not used" tests don't really need any real code, for example
 
Maybe we pass in a flag that says "we only need declarations, not references", and it stops after the declarations pass.
 
@Hosch250 that kinda thwarts "foo not used" though
 
Also, this doesn't help with the fact that setup of a mock is usually more expensive than running a procedure we don't need to.
 
@MathieuGuindon I didn't say put it in all the tests...
 
I think we'd see more of a benefit if we could create a test with less mocks involved than if we skipped some of the procedures.
 
10:47 PM
Perhaps a static bank of hard-coded declarations could do the trick. Minimal effort, maximum ROI
 
Now that makes sense.
 
Kind of like how v2.0 (1.4?) dealt with the built-ins, before the COM collector came to be
 
by serializing it to XML file and adding it to the source code?
 
Haha no, by literally hard-coding new Declaration(all, the, things)
 
Oh my goodness.
 
10:50 PM
Yup
 
Like in the ICustomDeclarationLoader implementations?
 
was thinking that the Serialize button would e used to enable you tow rite mock code, then create declarations from it. You can then add it to the source code control, and pesto, easy deposit.
 
IDK, thinking we don't really need enough of them to make a static helper too annoying. Nothing to deserialize or process, just plain declarations ready to consume wherever they're needed
e.g. public static Declaration UnusedVariable(string name)
(of course it's more complicated than that, but you get the idea)
...might easily turn into a hot mess though
 
11:10 PM
Hm, this is a bit unintuitive: the rename reafactoring tries to rename the containing class if a built-in identifier is selected instead o complaining about the selected identifier being built-in.
 
11:35 PM
Oh wow, RenameRefactoring gets the meaning of IInterfaceExposable.IsInterfaceMember completely wrong.
Hm, maybe not.
Now, I am back at square one why this test fails.
 
11:58 PM
Erm, why is there no case in the resolver to resolve a reference to a module in a referenced project as ClassModule?
The only options are UserDefinedType, Enumeration and ComAlias.
 

« first day (1753 days earlier)      last day (84 days later) »