not that I know

puts off worrying about queries to another day

can't remember off the cuff if it will enumerate all Access objects via declarations and correctly identify them. Since that requires using the COMProject to do so, I'm thinking no.

@noob Saving Private Ryan and Shawshank Redemption are in my top-3

but hey, I can be wrong.

@MathieuGuindon you count pretty well.

:-p

:)

@noob If you take animation movies as well, add Princess Mononoke, possibly Akira (though that one is ... strange) and Spirited Away

Coco was cute

@this you suggested ToFileExtension(component.Type) to get a file extension. However, for acModule, that is the type and I get no indication of whether it should be .bas or .cls. Does it matter to .LoadFromText, or will that figure it out on its own?

Unless there's some other property I'm not seeing that I can key off of for the acModule

ah, you're right - both classes and modules are acModule to Access OM.

so in that case, you probably should read from component.Type instead.

aye carumba!

the joy of mixing OMs?

Yeah, working on my BS in OM Mixology

'cause that's about how I'm feeling about it right now...

be happy it's not as bad as other.

yeah, I'm sure I've not even scratched the surface of the confusing bits

glances over at internet controls, XML library and MSHTML library Yeah. definitely not as bad as those.

sqth

new acronym for me.

snickers quietly to himself

:)

[rubberduck-vba/Rubberduck] build for commit aa0f1995 on unknown branch: AppVeyor build succeeded

made that up mahself!

[rubberduck-vba/Rubberduck] codecov[bot] created comment on pull request #4935: Fix settings headers

[rubberduck-vba/Rubberduck] build for commit aa0f1995 on unknown branch: 64.44% (target 0%)

lol

picture a Sheldon-style laugh, but quietly

@this 'As' is meant for returning specific interfaces of objects, not type conversion. C.f. AsEnumerable.

[rubberduck-vba/Rubberduck] codecov[bot] edited comment on pull request #4935: Fix settings headers

makes sense.

@mansellan I know I've read that somewhere, but I can't seem to find it.. got a link for that convention?

Heh, I'm in the same boat. Will see if I can find one.

I might have read it in Framework Design Guidelines (the actual book) circa 2009

I have that book somewhere

when I got my 1st gig as a ".net developer", the team handed me "Framework Design Guidelines" and "Clean Code" and said "read these two. you're not writing a single line of code until you've gone through both."

forever thankful

@this .rpt a reasonable file extension for reports?

yup

@this, your face and name changed!

:)

thx

@FreeMan iirc that's what the source control plugin exported them as, so yes absolutely.

SSRS reports are .rdl (server) or .rdlc (client), but "RDL" apparently stands for "Report Definition Language", which I'm guessing is glorified XML

I think Crystal Reports are .rpt

in end, it's whatever you want

^

.wyw

wtfydwp

some use prefix/suffix with a .def extension. others (myself included) use tbl, qry, frm, rpt, mac, and bas/cls but meh.

FooReport.def is rather elegant

I like Mug's wyw, but, for simplicity and minimizing documentation (cause who wants to write documentation), I think I'll stick with rpt

OASIS-SVN uses suffix + .def as a default (it supports the other convention, though).

sometimes, Access doesn't prompt me to save when I exit, and I'm paranoid I'm losing changes. Sometimes, when I try to save, then exit, it prompts me to save again.

loves shoots Access

Excel considers changing the active sheet as a change worth prompting for

so, there's that :)

It considers changing the active cell a change worth prompting for. Which is also annoying.

if you are not getting prompt to save changes, you might be leaking DoCmd.SetWarnings

which is why they should be never used. Ever.

grabs paper towel

I'm about 99.9999999% certain I've got no DoCmd in my code. Yon other guy may have tossed a couple in.

far too many "sample" code include it

so if the guy likes his pasta....

OK, time to stop by the hospital. FIL had quadruple bypass yesterday. Recovering well - his wit was rapier sharp when I stopped by this morning...

FIL = father in law?

@this - thanks again for the hand holding and the castle identifying!

@Vogel612 yes

quadruple bypass is not something you walk off, dear me

yw!

#out

something something PRs

I really need to beat the Code Analysis on local builds into submission ...

I just tested the latest next under the profiker again.

We still block the UI thread for several seconds when handling ResolvedDeclarations.

that's not good...

Most of the time is spent reading the code inspection settings.

bleh...

from the ToDoExplorer.

what?

That loads the whole dependency graph for no good reason AFAICT

but I'm sceptical that that's the actual root issue here

unless.....

why would ToDoExplorer need the code inspection settings? Isn't it supposed to have its own settings?

@this it does, but because of copy-pasta it loads all teh settingz and then traverses the settings hierarchy from Configuration downwards

Btw, to test it, I had the deactivate the logging of the ComSafe.

@Vogel612 Yeow.

the problem is that we might be loading the settings for each comment across all parse trees

@M.Doerner clarify - that also block the UI, too? I hoped that it would not since it goes through NLog's async stuff. (but then again, that is only a debug construct....)

also regex matches

It also takes a second to refresh the CE on the UI thread.

@this You used an explicit lock there.

we should really sprinkle some async on the areas where we are on the UI thread but still fetching data

like... don't block the UI thread for I/O...

^

The CE and/or CM queries the host application several times.

whether that's computing regex matches without any caching across all comments in the whole codebase or whatever CE does

I think we might be able to do most of the refresh outside the UI thread anyway and then push the results to it..

Todo explorer has no really good reason to be on the UI thread to compute which comment is a todo marker and which isn't

@M.Doerner ah yes I remember now - I didn't use NLog; I had to keep the threading sequences. That is bad for concurrency which was why I made it a debug-only construct.

@Vogel612 oh shoot.. I think there are a couple of places doing exactly that.

@MathieuGuindon yea there are...

should be downright trivial to fix after I paid down some more tech debt.

the more recent stuff just takes the specialized settings interface it needs

@M.Doerner does it says in which places. It might be related to my changes to the IHostApplication.

Note that all SettingsViewModels currently have their hands in the guts of SettingsProvider (namely IFilePersistenceService) to implement Import and Export

that is a slight bit of a pain

BTW, @Vogel612's settings PR brought the total parse time on the test project down to 48s from 57s.

yikes

question: Can I restrict an interface member on a public interface to be internal?

no

bummer

I want all implementations to expose something to consumers in the same dll, but not to outside consumer

use interface inheritance?

that's the current behaviour.

What you can do though, is to make a separate internal interface extending the public one.

but I don't want to inject the lower interface into the internal consumers :/

^^ that's what I was thinking of.

yea.. what max suggested is the current state

because part of these internal consumers are intended to be extended by outside assemblies... which makes the whole exercise partly moot in the first place :/

So to put names to this: I'm trying to work out whether we really need to separate IPersistenceService and IFilePersistenceService

sounds like one is an implementation of the other, whose explicit interface sounds redundant

just looking at the interface names, I mean

who gets to decide how it should be persisted?

(is there even another option beside file?)

No there isn't right now...

@this registry? db?

and the only write to FileName is in IOC

for the sake of the argument - let's say we have registry and db --- who gets to decide where it goes?

IoC registration

@MathieuGuindon yea, so that's done, I guess...

I'm killing the internal interface and will be making XMLPersistenceServiceBase responsible for setting it's internal FilePath

because IoC shouldn't care where tf. the files go, that's not its Job

I might be being a bit slow here - doesn't that imply if I have a Foo that needs to be persisted to registry, i need to implement FooRegistryPersistence, expose it via the IPersistenceService which is accessible to Foo.... right?

@Vogel612 I'm thinking only something like a ConfigurationFilePersistenceService should know what the xml configuration file is

(and that bothers me a bit - having to write a FooRegistryPersistence - there shouldn't be.)

IIRC the source control configuration was another implementer of these xml-persistence services

@this You could write a RegistryConfigurationServiceBase<T> and configure IoC to inject a correctly closed instance of that

and extend it for special oddball classes. Yeah, that'd work.

Feel that the T can only be a model / DTO / something of that nature, though.

question: should the legacy Smart Indenter settings be read using an implementation that looks something like a RegistryConfigurationServiceBase<IndenterSettings>?

why shouldn't it?

@MathieuGuindon possibly, yes.

the problem with RegistryConfiguration is how the keys are determined

That's why I mentioned that the T must be a DTO; you can then decorate it with something to provide adequate information about how to persist it (the path, data type, those kind of stuff you usually find with a DataContract)

not sure that's Uncle Bob's approved way, though.

As it stands we have that for a ton of XML persisted settings

sod uncle bob, though.

lol

Okay, that sounds harsher than I want it to sound, but...

@this it's currently in IndenterSettings.cs

probably better to just leave it though

He may be a good writer and has good ideas about clean code, but I don't want to blindly follow some "Uncle Bob's Bible"

I understand completely. Theory is all pretty but when you get down and dirty.... theory seems .... theoretical.

can someone remind me why Extension explicitly overrides the default config file with the default config file when loading the initial settings?

that seems... unhelpful

could that to be handle the missing settings?

can't remember if that was a fix for a old bug where RD would blow up if it shipped with a new setting that didn't exist in a setting file created with a previous version.

that's on a different abstraction level, though..

@Vogel612 where's that?

Extension.cs#L152

It makes zero sense to have RD load the initial settings from a nonstandard location

%appdata%\Rubberduck??

because then when we change the default storage location or method, we can fall prey to mismatched settings storage behavior

user may not have write access to the install folder

@MathieuGuindon let me rephrase: It makes zero sense to have RD load the initial settings from a customized location that is never written to when the user changes the settings

which implies that the initial load shouldn't attempt to customize the loading process

it just needs to spin up a part of the dependency graph manually because IoC isn't available yet

and it should do so faithfully... I think that initializer block is a remnant from before there was a PersistencePathProvider

git blame says I did it - to handle case when the file was missing, apparently.

relatedly: making the PersistencePathProvider.Instance be backed by a Lazy shouldn't provide a tangible benefit

hmm... d'you have a commit hash or issue reference so I can try repro?

github.com/rubberduck-vba/Rubberduck/commit/…

nope. you just did a whitespace change to that because you wrapped the whole block in a try-catch...

"Fixes 4964" is interesting...

the code itself is already present in this commit from 3 years ago ("implemented ShowSplash setting")

and a handful of changes before that...

This commit from the 2.0.5-rc introduced the code originally

P sure that specific bit should've been removed with this commit in #4699

i probably chickened out. :-\

I honestly wouldn't've touched it either if I didn't want to kill that specific interface :D

RE: lazy - probably a cargo cult of mine - I recalled that using a static method to invoke a instance constructor could get weird, and it was suggested that a Lazy<> was safe way to do this from a static method returning the instance.

I don't know of any way that would get weird, so long as you didn't reference statics within the class.

The problem should only manifest if you refer to uninitialized statics within the ctor

Thinking about it - I'm pretty sure I followed Jon's advice here

in particular this line at the bottom:

> Solution 5 is elegant, but trickier than 2 or 4, and as I said above, the benefits it provides seem to only be rarely useful. Solution 6 is a simpler way to achieve laziness, if you're using .NET 4. It also has the advantage that it's obviously lazy. I currently tend to still use solution 4, simply through habit - but if I were working with inexperienced developers I'd quite possibly go for solution 6 to start with as an easy and universally applicable pattern.

The universality was what I was looking for (less things to remember)

Solution 4 is sufficient for RDs purposes, but we're not counting peas (because Lazy takes a memory indirection) so solution 6 is just fine as well :)

@FreeMan I read it and at first glance BNW was nothing memorable. The undertones and actually thinking about it and reading it a second time makes it worth it.

@this Heh, I read the same post back in the day and came to the same conclusion.