« first day (1656 days earlier)      last day (1524 days later) » 

9:06 PM
> This is an opportunity to enhance the Find all References feature to locate all early-bound references to a given type library!
 
@Duga I already fixed that IIR.
 
in the CE not-yet-a-PR? ;-)
 
@MathieuGuindon Yep.
 
be a wee bit hard to get....
 
9:09 PM
by disabling the command on ref nodes, or enhancing find all refs to issue search results for all references to a type lib?
 
I noticed it was "off" when I was testing it. It never got tied to the CE - it always executed the selection in the active pane
I fixed the intended behavior. I'd have to check the current behavior to see how hard it would be to add references to the search dialog.
It's disabled on the reference nodes in my local.
That reminds me - the find all implementations command is broken in the same way.
 
ok
true
IIRC it doesn't quite work in the CE
(didn't?)
 
I split the 2 find references commands and gave them a common "provider" class that actually performs the find.
I'll probably do the same thing with the find all implementations too. IIR there was an open issue for that.
 
should "find implementations" behave like "go to definition" given a concrete type?
 
IMO, yes.
that's how R# does it, no?
 
9:14 PM
yeah
/VS
 
That shouldn't be hard.
It's the peek definition that's the hard one..
 
yeah, should be just a fallback handler
@Comintern #NotYet :)
 
There's a reason I'm exercising my WPF.
 
@Comintern pfft. it already exists in VBE
It's called.... wait for it....
 
MDI?
(couldn't wait)
 
9:16 PM
lol, close, but Split
(yes I know - llllaaammmmeeee)
 
been giving some more thought to SCP eating quick-info intellisense.... is there the slightest chance the VBE could be invoking rtc_Beep internally when the "quick info" command isn't available?
 
Ooooo... fancy. Like tiling.
 
> Discovered in the logs for #4644:

```
2018-12-17 14:27:44.0304;WARN-2.3.1.4308;Rubberduck.Inspections.Rubberduck.Inspections.Inspector;System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
at Rubberduck.Inspections.Concrete.ProcedureCanBeWrittenAsFunctionInspection.<>c__DisplayClass4_0.<DoGetInspectionResults>b__3(QualifiedContext`1 context) in C:\projects\rubberduck\Rubberduck
 
@Comintern IKR?
 
@MathieuGuindon Possibly. You could set a hook on it to check.
 
9:17 PM
yeah
 
@MathieuGuindon why not go lower and look for a window message?
 
[rubberduck-vba/Rubberduck] Vogel612 is checking what fun stuff @Duga can say about project cards
 
(it is a window message of its own, right?)
 
@this kinda hard, I'm already inside the msg loop
 
9:17 PM
WM_BEEP?
 
is the msg loop still running async?
or are you synchronized?
 
Nah, just return a value that says "ignore the next beep you see".
 
I'M IN UR MSGLOOPZ HANDLIN UR KEYPRESSES
 
lol
 
@Comintern I totally read that as "exorcising".
 
9:18 PM
lol
 
> Spotted in the logs presented in #4644. This was originally reported under #4258, but seems to have resurfaced:

```
2018-12-17 14:27:43.7524;WARN-2.3.1.4308;Rubberduck.Inspections.Rubberduck.Inspections.Inspector;System.NullReferenceException: Object reference not set to an instance of an object.
at Rubberduck.Inspections.Concrete.UnreachableCaseInspection.ParseTreeValueVisitor.GetConstantContextValueToken(ParserRuleContext context) in C:\projects\rubberduck\Rubberduck.CodeAnalysis\Ins
 
ok, i have to admit there's one thing I don't understand - surely the message loop has to be running async? Otherwise how would it even beep if you're quick-info'ing it?
 
[rubberduck-vba/Rubberduck] Vogel612 created project card
 
@Hosch250 If any WPF needs to be exorcised, it's probably mine. Hacking my way through it.
 
@this I'm equally baffled
 
9:20 PM
so I assume you already did try to ignore WM_BEEP
 
yeowch:
> 2018-12-17 14:35:42.9514;TRACE-2.3.1.4308;Rubberduck.Inspections.Abstract.InspectionBase;In‌​tercepted invocation of 'SheetAccessedUsingStringInspection.DoGetInspectionResults' ran for 78111ms;
 
is that from Freeman's log?
Cos if it's, he's running Access. That inspection does not belong.
 
@Vogel612 wuuuut
 
LOL.
 
@this nope. that's from #4644
 
9:23 PM
@this It's probably posting a message either directly to the desktop or to the VBE. I don't recall having the VBE subclassed.
@Vogel612 Holy sh!t. Is the code analysis contained to the procedure it's in?
I don't remember having run times like that on my torture workbook.
 
@Vogel612 Yikes! I know that parse/inspect can take a while on my projects, but I don't remember any that long!!!
 
@Comintern Ok that would make more sense. Sucks though because that mean yet another sublcassing just to listen for that one li'l beep.
 
That was an awesome 6 hour leadership/manager training session I got to sit through! Obviously, it's not working all that well - I'm not in management. Unless they're planning on springing a surprise on me come January...
 
I presume the code is bloated with repeated Worksheets("name").Range("A1").Select calls, for 10K lines or something, making the inspection basically walk through pretty much every single string literal in the code
 
4 Objects returned seems to contradict that
 
9:30 PM
wah
 
> The issue seems to be a COM-Exception that's blowing up when we're inspecting for that.

```
2018-12-17 15:02:01.0154;WARN-2.3.1.4308;Rubberduck.Inspections.Rubberduck.Inspections.Inspector;System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.
at Microsoft.Vbe.Interop._VBComponent.get_Properties()
at Rubberduck.VBEditor.SafeComWrappers.VBA.VBComponent.get_Properties() in C:\projects\rubberduck\Rubberduck.VBEd
 
i wonder if just having a lot of string literals is enough to make that happen.
 
@Vogel612 Unless it's being passed around in a Variant.
 
in theory the inspection only cares for literals that are arguments of a ThisWorkbook.Worksheets or Sheets member call, no?
 
@Comintern That shouldn't be an separate inspection result, would it be?
 
9:31 PM
It still has to check them, even if there aren't results.
 
might be a good idea to give it some caching capabilities
 
@this I'm pretty sure that we'd hit it with a couple other inspections in that case, right?
 
"ABC" -> known to not be a statically accessible worksheet -> skip
 
especially if we hit the same strings over and over, that would speed up the lookup consistently
 
hasn't seen the implementation since the original PR for it
that runtime looks like it's hitting the host's worksheets collection more than needed
 
9:34 PM
FWIW the other inspections in that log seem to at a cumulative 2 seconds pretty consistently
soo ... at least everything else is blazingly fast :D
 
@MathieuGuindon remind me again - are inspections in general cached?
 
oof
 
hey it worked super well when there were like 10 inspections
 
for bigger project that could be murder
LOL
 
9:37 PM
@this makes it easy to do invalidation
caching would require the inspection objects to record which module or component they belong to for granular invalidation
 
Any inspection that works off a) parse tree nodes, or b) declarations (no anything about references) in unchanged modules can be cached.
Anything involving references needs to be re-run.
 
and it would require inspections to work off of modules / components and the inspector to be aware of the parser's caching behavior
 
didn't we want to tie inspection results to parse tree nodes whenever possible, for free caching?
 
soo .... lots of dots to connect, with the danger of turning it all into a giant pile of spaghetti
 
@Vogel612 yeah, and we all know that caching invalidation are a fruitful source of bugs.
 
9:39 PM
The inspection should be able to just say "I'm cacheable!"
And the parser or inspection runner or something should handle the rest.
 
you need to get an invalidation trigger from the inspection, though...
or rather from the inspection result
 
@MathieuGuindon that might not work if hte inspection is based on references (e.g. not used by anyone else for example)
 
I'm seeing it the other way around: a parse tree node could be IInspectable, as could be a IdentifierReference
 
The inspection could implement ICacheable with abool IsInvalidated` or something.
 
9:40 PM
i.e. have the nodes, or identifier reference contain its inspection results
 
the nodes and refs are already cached
 
[rubberduck-vba/Rubberduck] Vogel612 is checking what fun stuff @Duga can say about project cards
 
so, we'd get inspection results cached for free
 
@MathieuGuindon I kinda dislike that
 
9:41 PM
@MathieuGuindon but how would that work for say, MemberNotUsedInspection?
 
I've always been told to be wary of offers of free cash.
 
because it mixes syntax representation with semantic information
 
@this its target is the member declaration
 
I mean... it sounds really cool, but ... Only if we get a non-syntactical representation of the code
 
9:42 PM
soo ... a DeclarationTree, or StatementTree or something like that
 
MOAR RAM!! :D
 
And Annotations should also attach to that....
 
@MathieuGuindon no, say, I have Foo procedure that's not used. It has the inspection result. Cool. I then add a new procedure that calls the Foo. Nothing about the Foo has been changed. How will it get invalidated?
 
@MathieuGuindon meh. Just a different representation for the Declarations, soo ... not that much more.
 
isn't that how Roslyn diagnostics does it?
node.Diagnostics
 
9:43 PM
@MathieuGuindon you talking about the Red-Black-Tree they use for partial parsing?
 
no, higher level than that (I think)
 
well.. we need the "higher than that" abstraction as well 😀 I kinda tried to get at that
 
@this this is the code snipped with the potential memory leak. Git blame says that it is 3 years old.
 
We call that all over the place.
 
I am not really sure whether that caches the image sources or not.
 
9:52 PM
It looks like it should.
 
> To enable closing the overarching issue of Code Metrics that originally only intended to deal with an initial implementation, this issue is a follow-up taking one of the proposed inspections and putting it into it's own issue.

The MaintainabilityIndex of a code base is computed by the [magic formula](http://blogs.msdn.com/b/codeanalysis/archive/2007/11/20/maintainability-index-range-and-meaning.aspx "MSDN blog article on maintainability index"):

```
(171 - 5.2 * ln(HV) - 0.23 * CC - 16.
 
Now, my question is, if you use this converter, will each call use the source to load a new bitmap?
 
> Follow up for the Maintainability Index in #4657
 
It shouldn't, although doesn't that leak the memory streams?
I'm not entirely clear on who's responsible for that stream.
 
Or might this be part of our problem?
The converters get loaded into the WPF control as static resources.
 
9:56 PM
@Comintern OP updated it just for you:
 
@M.Doerner seems like that converter should be marked as disposable and clean up the image resources it caches when disposed, huh?
 
Hm, actually creating instances of the converter should not be a problem as the image streams are cached in a static dictionary.
 
Ouch. Crashed in kernelbase.dll
 
totally VBA code responsible for that, right?
 
Not necessarily.
 
10:00 PM
You should be able to do that with faulty interop code, right?
 
^
We've done that before.
 
after all this time we still don't even now whether the C# app is running in-process, or if it's spawning an EXCEL.EXE process, and we've seen none of it, and zero effort from the OP to treat it as a bug in their C# code. my VTC stands.
 
Yeah, I'm adding mine to the pile.
 
@Comintern lol yep :)
 
Hey guys
my co worker deleted a class module using the RD code explorer
and now access keeps on crashing saying file not found
 
10:10 PM
...
 
he cant delete the class module
 
Unless...
He found a bug.
Got a log?
 
probably not. hes using 2.2 i think
 
old version == old bugs
 
yeah
though to be fair, you guys did just release 2.3
and i know because i chill in here talking to you guys
 
10:13 PM
2.4 in a couple days.
 
oh jeez, grats guys
My solution to get him back up and running is to import everything into a new file
see if that fixes it
 
@KySoto 2.3.1 hotfix actually
 
10:37 PM
the import method worked, and i told him to update RD
@MathieuGuindon i just saw the ssis script task thing you posted an answer on
 
did I miss something?
 
that sorta thing (which i didnt even know about) is why if i am manipulating objects and whatnot in access/excel
i just create the script to do stuff IN access/excel
you dont have to worry about all of that insanity
@MathieuGuindon as far as i can tell, you did not miss anything
it was very informative for me.
 
TBH he probably shouldn't be automating Excel in a SSIS anyway.
 
@Comintern ha! I think that question just got me "Waffles" hat on SO
 
10:57 PM
> Currently, it is possible to execute private procedures. Since test modules aren't meant to be run outside well, *tests*, it seems nice to be able to make all procedures as private, as to not pollute the intellisense / global namespace, especially in projects where it's not practical to have a separate test project.

The change would be mainly be in the UI as it currently filters out any private procedures when discovering tests.
 
@MathieuGuindon how do I make code snippet in GH with several lines?
LXXLYY works in the code itself but apparently not inside an issue
 
@this inline snippets only work for specific commits
 
11:14 PM
@MathieuGuindon LOL - I don't think I'm going to let myself get that one.
 
@Vogel612 so lame considering that it works for one line
 
no.
doesn't inline either
 
oh it does
 
huh?
 
using this source text:
 
11:20 PM
I think you just need to post the permalink.
 
We may have a memory leak with some of WPF resources:
github.com/rubberduck-vba/Rubberduck/blob/…
 
yea, that's in commmit 7733e38
 
but add L53 and it breaks
 
Add -L53
 
aw, c'mon!
Had to be the one combo I didn't try.
and what is worse is that the variant without the dash still works on the GH code pane.
 
11:23 PM
> I noticed this while I was meatbagging the Code Explorer. The expression parser in the `UnreachableCaseInspection` apparently has problems with enumerations that use built-in constants. This MCVE...

```
Enum Fubar
Foo = vbObjectError + 1
Bar = vbObjectError + 2
End Enum

Sub Example()
Select Case 42
Case Fubar.Foo
Debug.Print "Foo"
Case Fubar.Bar
Debug.Print "Bar"
End Select
End Sub
```
...results in this error:

```
> We may have a memory leak with some of WPF resources:
https://github.com/rubberduck-vba/Rubberduck/blob/7733e38c57a1d818d507ad374c4d0bab60efcda0/Rubberduck.Core/UI/Inspections/InspectionSeverityImageSourceConverter.cs#L42-L53

and possibly from this:
https://github.com/rubberduck-vba/Rubberduck/blob/7733e38c57a1d818d507ad374c4d0bab60efcda0/Rubberduck.Core/UI/Inspections/InspectionImageSourceConverter.cs#L18-L19

We need to double check that the unmanaged resources are handled appropriate
 

« first day (1656 days earlier)      last day (1524 days later) »