Confirming I'm understanding this because I need to not mix up the 2 layers here. On the MVP (winform) layer, I should be only concerned with opening the dialog, and then set up the event to listen for closing so I can clean up the winform dialog. However, for the presenter, we have a factory to create the presenter, and we pass the model through the factory.
From what I see, the model is the same for both MVP layer and the MVVM layer, so we don't need a separate model between the layers.
For the V of the MVP layer, it's basically a container to the VM of the MVVM layer.
This would be my first time, I'm learning along. I'm familiar with HTML & JS, so it helped that I knew bit about MVC and MVVM.
I already have the layout in XAML all set up for the Extract Method; I'm currently getting NRE when it's instantiated and that's because I'm not passing in all data I need in my VM for the WPF control, so that's why I'm looking at the code again.
LOL, yeah, that!
and looks like I'm going to have join you in the smoking WPF nested in WF
I'm feeling a bit uneasy about this code which I emulated from other refactoring dialogs (Reorder Parameters dialog in particular)
using (var view = new ExtractMethodDialog(new ExtractMethodViewModel()))
{
var factory = new ExtractMethodPresenterFactory(Vbe, view, _indenter, _state, qualifiedSelection.Value);
var refactoring = new ExtractMethodRefactoring(Vbe, module, factory);
refactoring.Refactor(qualifiedSelection.Value);
}
My issue with that snippet is that we have 3 new'd objects.
and whether we really need to pass in vbe, view, state, and selection just to get a factory.
(which BTW, was a source of my confusion earlier - there is no way to give a model or view to the dialog directly to the presenter. It has to go through a factory, which seems weird to me.)
so I guess I need to understand... a) why are we putting view & model through the factory and not handing it to the presenter after it has been created? b) does it seems weird that we new an instance of dialog, only to build a presenter; isn't it presenter's concern to manage the dialog? Likewise, isn't it refactoring's concern to manage the dialog/presenter?
By implementing the MScorlib IComparer Interface, my PropertyComparer Class enables sort Objects added to an ArrayList by the their properties. You can also determine if an Object is in the ArrayList using a BinarySearch.
In order to do a BinarySearch you will need to sort the list with a Prope...
Duck check: getting into github.com/rubberduck-vba/Rubberduck/blob/next/RetailCoder.VBE/… and wanted to know if the repetition warrants following DRY and adding another layer of abstraction in the form of a method for the identifier name and selected parameters.
There are quite a number of very nice looking changes since to the duck since I last had the opportunity to look. Y'all are doing great work! (As predicted by previous experience.)
I need to amend my question A earlier - it makes sense to pass through the vm and other stuff via the factory. What does not make is that it's passed through the factory's ctor, rather than factory's Create method, since one'd thunk the purpose of the factory is to create a customized instance of whatever it's creating. Passing it via its ctor makes it a one-trick pony?
I also realized one more problem with my code as well - I feel like I really should be passing in the model, not a bunch of parameters. If I need vbe, state, and whatever else, shouldn't they be all part of the model --- new up the model, constructed using the selection, then pass it through to the dialog.
var model = New ExtractMethodModel(selection, vbe, state);
var factory = RefactoringDialogFactory();
var dialog = factory.Create(ExtractMethodDialog, model);
IMO, I should not have to touch the P (or even V) of the MVP layer. They are going to be all the same. I should only care about the underlying WPF's MVVM.
so if we made one generic class, and made the VM field generic, then we can just have a single factory, single presenter, and push all the concerns into the model & VM, no?
it's also not completely clear to me why the original code isn't actually creating a model but a viewmodel. One'd think that at the time of creating the dialog, I should be passing in the model. The VM is pretty much immutable since it only describe what to do when something happens, no?
@this sounds about right... and definitely in line with where we're headed WRT single-dockable pane hosting everything.
> Good morning team,
I've been using your Add-in for a while, and by now I believe it will be very useful to my team, as we're working with VBA fulltime. So I'd like to participate in the project. As if adding funcitonality or hunting down bugs. So I'd like to ask you, where can I get started? Your project is quite big by now :)
I've been following the SourceControl project. I'm a bit new to COM on .NET, I asked you about COM info a few weeks ago and I've been learning a lot about it by now. But now I also want to ask you how's the whole workflow of the Solution? How are the branches and …
That's some great news! Do you have an account on Code Review Stack Exchange? We use SE chat (here) to, well, chat, and coordinate everything. If you don't have 20 reputation points on a SE site, as a moderator on Code Review I can grant you explicit write access to the chatroom.
So there's the main Rubberduck repository, with a [master] and a [next] branch; we only merge into [master] when we make a "green release", and every PR merged into [next] automatically creates a "pre-release" CI build. Contributors work off a fork of the repository (e.g. I have mine at github.com/re…
@Mat'sMug Thanks for confirmation that I'm not insane. Being my first time dealing with MVP (used Winforms before but badly) and WPF (familiar with MVVM but not WPF itself), had to make sure I wasn't missing something fundamental.
Regarding auto-magic factories in CW, you have to define and register an interface for them with functions returning the objects you want to create. The only restriction on the parameters is that they must be a subset of the parameters of a constructor for the objects; CW will provide everything else, if possible. (Parameter matching can be by type, provided this is not ambiguous. Otherwise, it has to be done by parameter name, IIRC.)
CW will dispose of everthing any of its auto-magic factories has created when the container gets diposed.
However, this has the downside that you have to actively release objects created by the factory from tracking by the container if they should be disposed/GCed earlier.
Hmm. The problem, however, is that we are creating a lot of things -- the dialog, the presenter, the viewmodel, and the WPF view. To make it simple so that factory can take only the model, I suppose I'd need to ensure that the presenter created by the factory will take care of creating the dialog and the creation of the VM (ideally in a generic manner), so that ultimately, only thing that get passed through is the model.
I should not even be thinking about presenters or dialogs or viewmodels.
That is done via a void method on the factory interface that takes an instance of the class. The name does not matter, except that is must not be Dispose, which is reserved for disposing the factory entirely.
Not sure I completely understand the last part. Why using auto-magic factory to handle the releasing would be cumbersome? And what do you mean by "released again"?
Well, for one, you cannot just use a using block. That will dispose the object, but not release it from the factory. Accordingly you have to deal with the excepetion safety yourself.
or instead of reinventing the wheel use something like MailChimp or Constant Contacts -- they have services for validating the emails and providing you with a report of what bounced to keep your contact emails current
@NelsonVides so, I take it that you've browsed around and then got nauseous with the sheer size of the thing, and now you're like "ok cool, so where do I start"?
Duck check: When creating a brand new workbook and then inserting a unit test. I noticed it barfs if you save the file. It still looks out for the default Book1.
> Adding a Test Module, with or without stubs, invokes a reparse. Adding any StandardModule, ClassModule, or Userform doesn't. Deleting a TestModule, StandardModule, ClassModule or Userform doesn't invoke a parse.
``` Rubberduck version: Version 2.1.1.2478 Operating System: Microsoft Windows NT 6.1.7601 Service Pack 1, x64 Host Product: Microsoft Office 2013 x86 Host Version: 15.0.4971.1000 Host Executable: EXCEL.EXE ```
I manage a SQL Server and all SSRS reports coming out of it, and of course I'm the office's "Excel guy" that inherits every little bit of VBA code ever written by anyone in the company
hmm, IDK. For one thing, the n variable is undeclared.
Didn't test but think that declaring it (and having Option Explicit) would have avoided that error 6.
Thinking about it further, a valid inspection would be if the parameter had to be a Variant (because we gonna handle null... grumble), then yes, an inspection for explicit conversion would make sense.
By implementing the MScorlib IComparer Interface, my PropertyComparer Class enables sort Objects added to an ArrayList by the their properties. You can also determine if an Object is in the ArrayList using a BinarySearch.
In order to do a BinarySearch you will need to sort the list with a Prope...
A Mod B is equals to A - Int(A / B) * B, so you can try to use c = z ^ e - Int(z ^ e / n) * n instead c = z ^ e Mod n. It works for me
VBA Rubberducking
VBA Rubberducking