RELOAD!

[rubberduck-vba/Rubberduck] 13 commits. 1 closed issue. 10250 additions. 10236 deletions.

@IvenBach the entry point is in Extension.cs in the main project, which initializes the App.cs and from there, the magic begins in a castle.

Just checking -- normally we use stuff like MyResource.SomeResource. In this case, I am getting the SomeResource as a string, rather than as a type. I think I can do MyResource.ResourceManager.GetString("SomeResource", someCulture) but... do we have a way of knowing which culture?

Hmm seems I can just call GetString("SomeResource")

@Vogel612 / @Comintern fyi I noticed this:

that seemed suspicious to me since this shouldn't be showing up in the list at all.

I believe this is due to the globbing: <Resource Include="**\*.txt" />

Changed it to <Resource Include="**\*.txt" Exclude="$(IntermediateOutputPath)\**" />

and that made it go away. Not sure if that's the right thing to do?

any living soul?

Just a dead one here.

And a baby duckling that says "Hi pond".

lol

@this welp. now if that's not weird

yea, making it go away was the right thing to do definitely

unrealtedly: I shouldn't have installed "They are billions"

I wasn't expecting to hear from you until tomorrow. :) Must have been a fun game.

Thanks for confirming, though. I will add the same exclusions to the other 2 globs just in case.

yea that's on me ... I originally didn't intend to play nearly 5 hours straight

at least did you win?

lol. I was playing on easy. the first 5 or 6 games I died within a few minutes

that game is really unforgiving.

O_O

as soon as the zombies reach your residential areas, you're basically done for

I hate to draw that parallel, but it's a bit like dark souls... just as a strategy game

That looks like a fun strategy game.

I just tried to explain to my wife the idea of RD, what GitHub is, etc... I somehow went on a tangent to reinforce VBA's status as serious language and loaded up Mat's Battleship. In the Random AI vs. Merciless AI battle that ensued, the Random AI came close to defeating the Merciless AI - only 2 hits on the remaining ship were missing. :D

Hm, I just learned the correct term would be cue banner. More fitting as well.

@Inarion text boxes should have an "EmptyValue" and a "Hint" or something like that in their API in WPF

@Vogel612 Oh, then I need to look again. More closely this time. :)

hmm ... if you're trying to have initial text, it seems that in a TextBox you can only set the Text property

[rubberduck-vba/Rubberduck] bclothier edited wiki page IoC Container

@Duga @M.Doerner when you can have a quick look to make sure what I added is still accurate. I had to modify some stuff to make it clearer (at least in my mind) and also i changed the code regarding the disposal of heavy component.

Gee ... @this I think I won't have time to work on RD tonight, probably not on Monday either.

No worries. It'll get done when it gets done. :)

I also think I might be able to try and make more headway on the refactoring class itself without the UI in meanwhile but I don't think I'll get to that until after the release.

I'm not really aiming for the refactoring to be in the release anyways.

I'll need to give the German translations a one-over anyways, though...

yeah. Hopefully the 2.4 won't be 9 months away, though. ;-)

Wanna help me poke Mug about it regularly?

I don't really want to take over decisions about when to release :/

Yes. We do have to keep it consistent at least.

[rubberduck-vba/Rubberduck] MDoerner edited wiki page IoC Container

just so I'm clear --- for CommandBase, we already have object parameter in both CanExecute and OnExecute -- if one defines a CommandParameter in the xaml, does that becomes the parameter? Are we allowed only one parameter?

[rubberduck-vba/Rubberduck] MDoerner edited wiki page IoC Container

@Duga @this I had to change a few things again because the changed version did not mean the same thing as the original one.

I also saw you caught more typos that I had missed, too. Nice job!

I see I might not have completely understood this part - so let me rephrase to see if I understood.... We will only use property injection only when the class is or derived from ViewModelBase, and only into its properties where the type is or derived from CommandBase?

Yes

ah ok. I'll edit this into active voice.

[rubberduck-vba/Rubberduck] bclothier edited wiki page IoC Container

^ at least in my mind, this reads easily. Let me know if think otherwise.

bah, something that would be trivial in my IoC of choice appears to be something of a PITA in CW :-(

which is it?

CW will do Func<T> for a simple factory, but not an enumerable of them

probably already saw but I believe that was mentioned in the wiki page for IoC

(getting an ienumerable of the types)

oh ok, reading...

for a factory, I suppose you'd have to do IEnumerable<Foo> Create()

(assuming automagic factory)

In this case it's gonna be something like TMenuBar Create<TMenuBar>(/*params*/) where TMenuBar : IMenuBar

(those types are new to my WIP btw...)

not sure if that's the SL (anti)-pattern, but in this case it's kept reasonably narrow by the constraint?

IDK - need more context. Why do you need the factory with parameters.

so I'm trying out a new design for menu\tool bar collections. snippet:

        public override void Initialize()
        {
            Refresh = AddCommand<RefreshCommand>("RubberduckMenu_Refresh", CommandBarIcons.arrow_circle_double, CommandBarIcons.arrow_circle_double_mask);
            UnitTests = AddMenuBar<UnitTestsMenuBar>("RubberduckMenu_UnitTests");
            Indent = AddMenuBar<IndentMenuBar>();
            Refactor = AddMenuBar<RefactorMenuBar>();
            Navigate = AddMenuBar<NavigateMenuBar>();
            Tools = AddMenuBar<ToolsMenuBar>();
            CodeInspections = AddCommand<InspectionResultsCommand>("RubberduckMenu_CodeInspections");

AddCommand works fine, as it ends up wrapping the supplied type

AddMenu needs to new up the supplied type though, hence needing factories

one of my main design goals is to allow collections to be freely assigned to either WPF or to VBE comandbars

or indeed both :-)

just so i'm clear - why those aren't ctor-injected?

design choice - it occurs to me that menus are well-known to RD, and should be explicitly defined. It also allows for calling code to reference items directly, without looking up by tag etc.

in the same way that we know which buttons are on the CE toolbar, for example

everything is interface based though, so it should still be mockable

tbh its an experiment, when I PR it if you guys hate it then fair enough. I won't be offended :-)

it's a ways off PR anyway - need to wait for 2.3 to ship

sorry got pulled away for a bit

AIUi, right now, CW will property inject the commands

and those are strong typed.

But that's for WPF, of course.

yes

so with the change you're looking for, we'd have same system for setting up menus whether it's WPF or directly as COM commandbar***?

that's one of the goals yes

also, even on the WPF side, even though the commands are injected, there's a lot of repitition in the views to actually set up the menus and toolbars

it would be nice if we could just inject a whole menu or toolbar structure, and have a common resource handle all of the binding

Oh, I see.

agreed on templating the menu as a group, though. not all need to be handled as a bunch of individual commands.

so you define what a menu looks like in terms of its commands and submenus (per the example above), and you can chuck it anywhere - into a WPF VM, a context menu, a VBE toolbar...

the menu doesn't know or care where it's going

oh - and a nice internal API for doing so. no more magic enums to define ordering etc

I nerd-sniped myself... started pretty small, then lots of "wouldn't it be nice if" ideas came along...

pretty sure that'll be easier to understand once I see it all together. Did you find answer to your question earlier?

yeah I think I know what's needed

[rubberduck-vba/Rubberduck] retailcoder merged pull request #4491: Clean COM wrappers leak: Round 2 from bclothier/Rubberduck/CleanComSafeLeakRound2 into rubberduck-vba/Rubberduck/next

[rubberduck-vba/Rubberduck] retailcoder pushed 11 commits to next (only showing some of them below)

[rubberduck-vba/Rubberduck] bclothier pushed commit b03a59d2 to next: Add IDisposable Analyzer and assess its usefulness. Fix some legitimate issues. Disable the analyzer due to numerous false positives.

[rubberduck-vba/Rubberduck] bclothier pushed commit 14665a34 to next: Add missing Dispose for conditional returns.

[rubberduck-vba/Rubberduck] bclothier pushed commit 9bfbca0c to next: Fix a failing unit test due to not passing in the mocked vbe object.

[rubberduck-vba/Rubberduck] bclothier pushed commit 84503b7d to next

[rubberduck-vba/Rubberduck] bclothier pushed commit 1d1b55ac to next: Remove unneeded Dispose

[rubberduck-vba/Rubberduck] bclothier pushed commit 06ae0bed to next

[rubberduck-vba/Rubberduck] bclothier pushed commit 71034ff7 to next: Merge branch 'next' of github.com/rubberduck-vba/Rubberduck into CleanComSafeLeakRound2

[rubberduck-vba/Rubberduck] bclothier pushed commit 869f7834 to next: Address PR comments

[rubberduck-vba/Rubberduck] bclothier pushed commit 599e852d to next

[rubberduck-vba/Rubberduck] web-flow pushed commit 08783ee6 to next

2.4 is definitely not 1000 commits away ;-)

I'll have a go at the translations tonight

@MathieuGuindon uh, let me close that loophole for you.... 2.4 is definitely not more than 1000 commits away. ;-)

lol

what's on the table for 2.4 though? add/remove references, block completion, extract method, inspection mechanics redesign, regex search/replace,...whichever comes first warrants a minor version bump IMO

inspection redesign is becoming increasingly important as we approach the 100 inspections mark

then there's the big stuff, like the avalon code pane and everything that comes with it

the sql-based state querying could make a big difference with memory consumption, but then this is far from a trivial refactoring

If we had a "release" branch, could we work on the next minor and the next major in parallel?

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot published prerelease Prerelease-v2.2.0.4175

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created tag Prerelease-v2.2.0.4175

Com shims

[rubberduck-vba/Rubberduck] build for commit 08783ee6 on next: AppVeyor build succeeded

and COM shims too

Basically I think the biggest problem with releasing off next is that we don't get to work on major stuff without compromising/delaying the next minor release; so we either delay the release to get the major stuff in, or postpone the major stuff so we can get a release out. With two "destination" branches for every merged PR, we can get the collaborative ball rolling on avalon without risking to ship a broken code pane in the next minor update

the point of a release branch is to source-control enforce the feature freeze

so ..I got that part right then? =)

well ... not necessarily

because the plumbing for major stuff might as well be in the minor releases

the differentiation between major and minor is a highly subjective one anyways

so something like COM Shims could be a weirdly large minor release

something like the reference dialog and extract method could be a weirdly small major release

we're not releasing a library

which means we don't need to think about API breakage quite that much

usually the criterion for major vs. minor in libraries is API breaking changes

Hey @this the change to the property injection explanation here is incorrect.

but I see it's been fixed in the current version ... ignore me then :=)

[rubberduck-vba/Rubberduck] nvanoorschot starred us

@Vogel612 @MathieuGuindon FWIW. that is more or less what happened with the Extract Method branch. It's also partially my fault for not planning it better but when I started, I realized I need a lot of things...the code string parser and revamp of the dialog/presenter being two examples that weren't really about the EM itself but was needed.

In retrospect I should have had split off each plumbing work as their own PR. But back then I wasn't really thinking of those as components that should be useful to others.

I think that our architecture need to be more oriented toward supporting lighting on/off major features so that we can continue to ship to the next and not worry about it releasing with incomplete feature because they won't be lighted up.