« first day (1747 days earlier)      last day (91 days later) » 

12:01 AM
[rubberduck-vba/Rubberduck] 1 opened issue. 1 issue comment.
Minesweeper: Games Played: 113, Bombs Used: 63, Moves Performed: 13772
@Hosch250 if that's the case, the LICENSE should be within the dll.
soo ... you're probably safe?
2 hours later…
2:06 AM
#mvpbuzz #MVPSummit
1 hour later…
3:23 AM
So happy I finally got to meet Ben at #MVPSummit!!
4:14 AM
@TweetingDuck oh damn! Not only is mug at an MVP summit he’s also tweeting from tomorrow.
He’s mastered time travel before conquering VBA.
7 hours later…
11:15 AM
@this @Comintern yes, as indicated, I had a form open in "View" mode. No, not listening to any events.
ok, so maybe it wasn't perfectly clear that the form was in View mode, but I did say it was open...
2 hours later…
1:30 PM
Well, if it's really form that's gumming up the works, then we should be able reproduce it with the form open and not reproduce when it isn't. Also need to confirm whether it is a particular form or any form
1:40 PM
to be fair, I haven't attempted to reproduce. I'll give it a shot
Different question: Find all references doesn't seem to find Get`Let` references within the project of class properties. Is that expected?
am I misunderstanding something?
i.e., in the class, I hit Find all references on the Public Property Get x line, and it shows me 2 references: the Get where I currently am, and the Let a couple of lines below. However, if I do a VBE Find on x and search Current Project it takes me to where I assign a value to the property and where I use the property.
I would have expected Find all References to show those uses, as well.
@FreeMan There's an open issue for that IIR.
Oh yeah. It's one you opened - #4848. :-P
well, at least I'm consistent!
well, no, this isn't really that situation, actually.
I have the cursor on the Get, and all I see in the results are the Get and Let definitions in the class - I'm not seeing any uses of the Get elsewhere in code.
Here's where I use the Let - it's recognized correctly
and here's where I use the Get - it's also recognized correctly, however it claims 2 references. Find in current project, however, only shows me one use of it
Need to report an issue with logs?
2:11 PM
And if you do an old-school ctrl-F, there's only one, right?
@Comintern so given that the obj file is 32-bit, I think this route is a dead-end. However, would it in theory be possible to rip the execode out of a compiled document, create an obj file from it and link that? Not saying it would be easy, but possibly possible?
Maybe, but I'm guessing it would be fairly difficult - aren't they stored as pcode in the documents?
both iiuc
that's how the obfuscators work, they remove the pcode but leave the execode
It's worth a shot I guess - I'm guessing it's already linked there though.
hmm ok, so "just" need to put it in a PE file...
2:17 PM
Right - you'd need the PE headers, etc. The exports table would be the one I'd worry was missing.
oh, i'm way off being able to even attempt. much readin to be done :-)
just wanted to float the idea, see if I was nuts
Wildly ambitious maybe.
heh, I'll take it!
@Comintern Correct, 1 use of the Get and one of the Let
I might have missed it how did we establish the obj file was 32 bit
2:27 PM
@this I linked the unaltered obj file from 2010. OleWoo then recognised it.
32 bit olewoo but not 64 bit olewoo?
I may have been using the wrong bitness
will double-check when I finish work
2:59 PM
3:15 PM
> I came to RubberDuck via this Stackoverflow thread- https://stackoverflow.com/questions/41240745/version-control-system-for-excel-vba-code#41241438 looking for a way to make code in an Excel project file visible + manageable in Git.

I gather the (experimental) full integration with source control is on the way out, but the `Tools->Export Active Project` function does indeed do the core of what is required. However, it seems you have to remember to do this manually.

Would it be possible t
@Duga 4 ahead :-)
3:49 PM
Well thats fun
a union query is nuking access
4:31 PM
[rubberduck-vba/Rubberduck] MDoerner pushed commit dff81fb5 to next: German translations for 2.4.1
[rubberduck-vba/Rubberduck] MDoerner pushed commit 94420253 to next: Changed new German translations to honorific tone
Merge pull request #4860 from MDoerner/GermanTranslationsFor241

German translations for 2.4.1
apparently access hates it if you change a field name in a table that is used in a union query
in SSMS, it just yells at you, in access, well access dies.
4:48 PM
> Update: problem persists. Opened it again today and the pint-size VBE window presented itself; growing it locked everything up. After restarting Excel, opened the VBE maximized it and closed all panes except the code pane and then was able to open the CE and other panes. Interestingly, when I tried to open the Immediate and Locals panes they didn't seem to respond. The separation/sizing bar was all the way to the bottom of the screen; dragged up to see them.
> This makes me wonder whether the WM_SIZE messages we intercept for dockable windows somehow interferes here... We shouldn't be able to mess with anything, but still...
[rubberduck-vba/Rubberduck] Vogel612 project card. Enough said.
didn't even move it...
[rubberduck-vba/Rubberduck] Vogel612 is bored so why not move a project card
now I did actually move it :)
> i18n has been completed in PRs #4860, #4857, #4854 and #4853. We also have the memoriam for ThunderFrame as well as a few easter eggs.

TODOs are:

- [ ] draft release notes
- [ ] prepare version update PR
- [ ] ???
Any ideas on how we should open the Release Notes for feedback?
I'm tempted to just have them in a Contributor-only discussion
alternatively put them in a gist...
@Duga ~sigh ... chocolatey ....
5:21 PM
@KySoto apparently access hates it if you change a field name in a table that is used in a union query <--FTFY
Oh, yes. Much Better.
Interesting. I have Office 2016 64-bit installed on my work machine. Somehow, though, I've got the Access database engine 2010 32-bit also installed.
I wonder if that's causing some of the weird issues I see
The only difference I see is install size and (ENU) - whatever that means...
5:38 PM
Normally they block since combination, but this sounds like an oversight. I am aware there are some people who deliberately install things like that in order to have both 32-bit and 64bit ACE engines on same machine and reported success but that would not be a supported scenario obviously.
I tried running our IT's version of the Office '16 installer and it refused to run because of this. Oddly, going to ARP and running the Office '16 installer from there kicked off just fine - it's currently running a repair in the hopes that it resolves some of Excel crashing I've been having.
Great, Office can't install because I've got Explorer open??? What the heck?
Windows hates you?
I don't take it personally, though, I think Windows is an equal opportunity hater and hates everyone.
5:59 PM
see also: here
@this You should be relaxing enjoying your Summit. Shoo shoo. Take a break from RD and have fun. The pond will be here when you're done funning.
6:16 PM
@FreeMan After thinking for a sec, i think that you need to replace the "you" with "everyone"
3 hours later…
9:37 PM
#MVPBuzz visiting the treehouse with fellow #Excel MVPs
@this Did you ever open an issue regarding us sprincling loggers all over the place?
9:56 PM
@IvenBach sorry just saw that. A bit too late to be worrying about that. :)
@M.Doerner I don't think so. I might have forgotten?
Then I'll just open one with a suggestion.
10:07 PM
> Currently, we sprinkle `LogManager.GetCurrentClassLogger()` all over the code base and, thus, spread a direct dependency to NLog all over the solution. As was discussed in chat several times, we should probably take a nore structurised approach to this.

One concern in the past was that when deriving from a type `GetCurrentClassLogger` in the base gets the logger with the message setup for the base class. However, this can be circumvented using `LogManager.GetLogger(GetType()FullName)`.

10:21 PM
@Duga AppVeyor has been kicked in the backside
@Duga If we really wanted to losen the dependency on NLog, we would need a custom interface for the logger. However, I think that is not necessary, yet.
> Shouldn't we solve this problem by using DI? It seems like a much cleaner solution to just configure static property injection for a Logger interface. Decoupling that interface from NLog seems too much of a hassle TBH.

Since Rubberduck is not a library, we don't really need to be logger-agnostic. I also don't see us changing logger implementations anywhere down the line...
10:43 PM
@Duga @Vogel612 How would you inject the correct logger?
> Personally, I have two problems with using DI to get the loggers, in particular property injection.

As far as I understand, to property inject the logger, we need a public or at least internal settable property on the classes supporting logging. Consequently, the logging would be part of all kinds of public interfaces. I thhink that should be avoided since the logger is an implementation detail.

My second concern is of a moer technical nature: is there a way to DI the correct logger for
So why would we the centralize that concern? I don't really see a need to do that. If it's an implementation detail, so would be any factory we put between our code and the library. If you want to avoid a cost of change when adjusting the logger library we use... define a single standard method to obtain a logger instance and run a search replace for all callsites to change the library
This was originally a concern of this and comintern.
11:00 PM
[rubberduck-vba/Rubberduck] build for commit 12a43280 on next: AppVeyor build succeeded
[rubberduck-vba/Rubberduck] build for commit 12a43280 on next: 64.53% (target 0%)
11:21 PM
Why does git always have to mess up the merge of resources if both sides added keys?
11:50 PM
> # [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/12a4328000102f3e57bf9952f637b32d956a718a?src=pr&el=desc) will **decrease** coverage by `<.01%`.
> The diff coverage is `79.27%`.

@@ Coverage Diff @@
## next #4851 +/- ##

« first day (1747 days earlier)      last day (91 days later) »