RELOAD!

[rubberduck-vba/Rubberduck] 1 opened issue. 2 issue comments.

[Minesweeper] Games Played: 123, Bombs Used: 81, Moves Performed: 16505, New Users: 11

That example lets me get a little farther. I'm getting lost in the inheritance hierarchy when the call to protected override IEnumerable<IInspectionResult> DoGetInspectionResults(DeclarationFinder finder).

Based on the supplied code which has an Enum declared on a worksheet finder has a class result.

Since I don't fully understand the process to get the result I don't know how else to proceed.

Maybe a break will help. I'll also look for a simpler inspection to follow.

I'm stuck on the having the enum declarations and subsequently converting them into an IInspectionResult.

I can't find an easy example of how that's done.

The fact that I got the correct result without fully understanding how disturbs me more than when I was frustrated at not getting any result.

mumble mumble will this work mumble :compile: :debug: mumble mumble keep trying mumble.

Is there a way to get the ComponentType on the parent of a Declaration? Testing with a Worksheet and ClassModule containing an Enum I'm unable to find a difference between them.

Regarding the CE discussion yesterday, we already have a structure where we can get declarations by qualified name, the DeclarationFinder. We'll, that is almost true.

Regarding the CE discussion yesterday, we already have a structure where we can get declarations by qualified name, the DeclarationFinder. Well, that is almost true.

@IvenBach Yes: Declaration.QualifiedName.QualifiedModuleName.ComponentType.

There is still the problem that the qualified member names are ambiguous for enum members. I think we should introduce the definition scope as further part of the qualified module name. It would be empty for everything defined on the module directly and local variables, type members and enum members get their parent as scope. That would cover everything since there are only two levels of declaration scope in VBA.

I don't quite follow.

I have a Worksheet and ClassModule within each I define an Enum. When I filter for declarationFinder.DeclarationsWithType(DeclarationType.Enumeration).Where(d => d.QualifiedModuleName.ComponentType == VBEditor.SafeComWrappers.ComponentType.DocObject); it excludes the class module and only returns the Worksheet enum.

That comment was about not exactly being able to identify declarations by qualified module name, atm.

I place money that Tired-Iven is unable to understand any differences. I'm interested to learn what they are but need sleep to process what I worked on so far.

@IvenBach What did you expect?

@IvenBach ^ in reference to my filter or your previous comment?

The filter

That is the exact result I was expecting. I was digging reviewing both the members each result and knew it would work though.

I'm more Mort than Elvis or Einstein as I'm creating this new inspection. Copy-pasta-ing and mirroring what I see modifying it as I need to get the results I want.

What exactly should the inspection do and why do you perform that query explicitly like that?

The inspection aims to find any enumerations defined within within Worksheets.

Anyway, regarding the CE, I do not really like that the individual nodes carry the declarations directly. This means that they carry around a lot of information.

The filter is set up in that way as that is how I was able to achieve the results I intended.

If there's a better/preferred/more-elegant way I'm not seeing it, yet.

Why not use DeclarationInspectionBase as base class?

I don't fully understand what it is used for. I'll get some sleep and a fresh mind will help.

The lack of ///<summary>...</summary documentation makes it hard for me to understand the intent of each class and subsequent bases the inherit from.

If you can provide an explanation I'd very much appreciate anything. I'll review it tomorrow.

Night</iven>

[rubberduck-vba/Rubberduck] yamaiqbs starred us

@Duga 1,201!

About that "minimal mode" thing: crippling RD to turn it into a member-level CE without folders doesn't strike me as very useful, or aligned with what RD means to do.

that's not really the point of it, though?

the idea is to reduce the load for the cases where it's not being actively used

we already have something like that for inspections not being automatically run on every parse

that request just takes that idea to it's next logical level

yeah. what we need is a togglebutton to disable automatic parsing when a module is added/removed

that's possibly one part yea, but if we do that we allow the parsing state to go out-of-sync

at that point we could just as well kick all of the useful things to the curb

i.e. turn into MZ and defer all activity and processing until after the user requested them? we'd need to reintroduce the v1.2 blocking progress indicator or something...

even better, turn into the IDE itself where parsing happens line by line at near instantaneous speeds! :D

Hungarian notation gives semantic information about a variable, telling you the intended use in docs.

> A more common form of Hungarian notation uses prefixes to give type information. This is a perversion of its original intent and should not be continued.

Mug. ^ You have an opportunity to help clarify documentation with the edit button.

@MathieuGuindon - random question. Can you think of any disadvantage to qualifying a workbook-scoped named range with the worksheet?

I'm sure this has been discussed before, I can't recall when/where tho

@BigBen It errors out? Sheet1.Names("WBScoped").RefersToRange.Address barfs.

While a Worksheet scoped named range qualified by a Workbook reference is valid, it is misleading because it now looks like it belongs to the WB.

Sheet1.Range("WBScoped") does not.

^^

I have it barf.

Meaning?

RTE1004

No repro.

What a curiosity. Program behavior changes on different machines.

>.<

You are using Sheet1.Range("WBScoped") and it barfs?

:derp: You're using Range("...") instead of Names("...")

nice

Names barfs while Range doesn't.

Yeah ok you had me confused for a second.

Because of the potential for outright lying I've been using Names() instead.

Public Sub Ambiguouosity()
    Debug.Print Range("WhereDoILive").Address(External:=True)
End Sub

Not fun figuring the active sheet doesn't have that named range.

[rubberduck-vba/Rubberduck] mh166 starred us