Re: WPF Dialog Service via Binding - WPF Discussion Boards

SledgeHammer01 wrote:
ICommands are only created when you need to invoke some operation from the UI.

That's exactly correct, and that's what's happening in this case. Just as you bind an ICommand to Button.Command, using my approach you associate an ICommand with a button on the message box.

I wish you the best of luck.

Adrian Alexander wrote:
That's exactly correct, and that's what's happening in this case. Just as you
bind an ICommand to Button.Command, using my approach you associate an ICommand
with a button on the message box.

Yes, I completely agree. For my VMs that have 15 message boxes, thats:

45 additional ICommand members (45 lines of code) +
45 additional ICommand properties (about 10 lines each = 450 lines of code) +
45 additional methods (stubs alone are 3 lines each = 135 lines of code)

= 630 lines of additional code I have to hand type just for message boxes!!!

Please ignore the fact that my average class size is about 600 to 1000 lines and that you'll be doubling the size of every class.

Fabulous design!!! Makes things so much easier! Keep up the good work! Thumbs Up | :thumbsup:

Moving on from this train wreck Dead | X|

Using the code I have supplied, you would only need the additional methods. You would not need the additional ICommand members or properties.

And as I suggested earlier, you could easily modify the approach to accept just one callback method per message box. The method would accept the result value and you could use a switch statement if that's what you like.

Actually, you suggested creating ICommands for each before Smile | :)

.

Obviously, I think we can agree that the 45 method approach is bad Smile | :)

.

Going the single callback / switch (result) route is starting to get better Smile | :)

.

However, going back to my real world scenario of 15 message boxes in my VM, I'd need to create 15 methods. HandleMsgBox1(...), HandleMsgBox2(...), etc. because each MessageBox has its own handling code. You also complicate the handling code in certain scenarios because you may have to pass around a bunch of objects that you normally wouldn't have to.

I really suggest you read up on ServiceLocator here and why its so awesome:

Using a Service Locator to Work with MessageBoxes in an MVVM Application[^]

As you can see, you can do this WITHOUT the 15 extra functions and maintain testability Smile | :)

. That was my point. Ok, I'll admit it to make you happy Smile | :)

, your technique "fundamentally" works, I never said it did not... BUT it requires jumping through too many hoops to get it to work in the real world and maintain testability.

You can write your code any way you wish, but the "standard" MVVM practice is to use ServiceLocator, DI or MEF.

Personally, as I said, I use DI in new code which is ServiceLocator on steroids.

All the WPF "big boys"... say Pete O'Hanlon and Sacha Barber (who you can obviously respect a lot more then me Smile | :)

) are using MEF.

Indeed we do. Look for something from me and Sacha soon which uses and abuses MEF. Big Grin | :-D

*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington

"Mind bleach! Send me mind bleach!" - Nagy Vilmos

My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility

The word "abuses" is, in my opinion, quite appropriate in regards to using MEF to display a message box.

Can you point me to some articles on these DI specifically.

Never underestimate the power of human stupidity
RAH

Honestly, when I was trying to figure out DI, I was never able to find any good articles, thats why it was so hard to wrap my head around. All the samples were very complicated Smile | :)

. The way you write the code depends on what DI container you use (there are about 10+ open source ones -- I use my own light weight one).

Basically, using the ServiceLocator pattern, you'd write code like:

C#

class MyClass : ViewModelBase
{
   private IDialogService _dlgService = null;

   public MyClass()
   {
      _dlgService = ViewModelBase.ServiceLocator.GetService<IDialogService>();
   }
}

DI (Dependency Injection) does it automatically for you:

C#

class MyClass : ViewModelBase
{
   private IDialogService _dlgService = null;

   public MyClass(IDialogService dlgService)
   {
      _dlgService = dlgService;
   }
}

The benefit of DI is that depending on your MVVM framework, everything is automatic. In my MVVM framework, I have the DI integrated with the ViewLocatorService, so when the view is created, it uses the ViewLocator to automatically create the ViewModel. It automatically passes in all the dependent objects into your VM constructor.

Basically instead of new'ing up MyClass, you do something like:

MyClass m = ViewModelBase.DIContainer.Resolve<myclass>();

doesn't seem like much of a benefit when you are only taking in one service Smile | :)

, but in a complex system, you could be taking in 10 services, and they could have dependencies of there own, etc.

Basically, DI handles passing in any registered objects into constructors and creating all necessary objects for you.

It also makes it easy to see what services a class is dependent on by looking at the constructor. A lot of the DI engines also allow you to not use the constructor method, but inject properties.

Like I said, I use my own light weight DI engine, but I think the most popular "main stream" ones are Unity and AutoFaq.

I'm sorry, but this is not the forum for airing grievances with votes. You have a perfectly adequate forum at the end of the posting for that.

*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington

"Mind bleach! Send me mind bleach!" - Nagy Vilmos

My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility

I agree. I was pointing in that direction, but someone didn't follow.

error SocketError.AccessDenied on silverlight

Read this suggestion[^] then reformulate your question ONCE and someone may attempt to help.

Never underestimate the power of human stupidity
RAH

Try this link out, http://drdobbs.com/windows/208403238[^]
and for a nice simple framework to help with implementing sockets:
http://www.silverlightshow.net/items/SocketsLight-Silverlight-Sockets-Framework.aspx[^]

You need to open up a port (4502-4534) for socket communication in Silverlight.
This needs to be specified in the crossdomain or clientaccess policy file.

Read more here[^].

error SocketError.AccessDenied on silverlight

Hi check out this link. hope it solves your problem.
http://drdobbs.com/windows/208403238[^]

In a Silverlight app, assume you have UI, Data, Business, and WCF projects.

Does the UI talk to the service, which then talks to the BL, which then in turn talks to the DL?

Or does the UI talke to the BL, which then talkes to the service, which talks to the data??

Everything makes sense in someone's mind

In our structure we have 3 solutions:
Models holding the representation of the database objects.
WCF has the DAL and references the Models.
UI has the views and VMs and also references the Models and a service reference.

Within each solution there are additional projects depending on the solution required.

Most of the business logic is in the VM with some done in the WCF solution. As most of the business logic is driven by UI interaction we do it in the VM. However there are some cases where the UI makes a decision and there is a large processing requirement, this is done at the WCF or even in stored procedures. I actually prefer procs for this but am finding the WCF and C#/Linq manipulation is fairly simple.

You can't beat a stored proc for sheer grunt whan there is a lot of data to crunch.

Never underestimate the power of human stupidity
RAH

I would prefer the UI talking to the service, which in turn talks to the BL approach.
This article[^] ought to be of some interest to you.

Is it by any means possible to bind a single listview to two seperate observable collections? So, for example the first column is from collection A and the second column from collection B.
If so, how?

No you can't. What happens if the collections change independently of each other with one collection havin rows added while the other has rows removed?

*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington

"Mind bleach! Send me mind bleach!" - Nagy Vilmos

My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility

No you cannot.
Databinding allows only one data source at a time.

I have a application written in WPF, C#. There are some settings of different modules of the application which I wanted to store, so that when application is launched, I can restore those settings.
I am thinking of using XML file and writing the settings through XML reader. I am using 'Application.CommonAppDataPath' to store the settings.
Is there a better way to implement this feature in WPF application and that can support Windows 7?

Also, as modules gets added to the application, settings get added to the file. What is the best design to handle addition of settings in future?

Please let me know the correct forum, If I have posted the query in wrong forum.

No need to hand job anything. Its already built into .NET for you for free. In solution explorer, expand the Properties folder and double click on "Settings.settings". Set up your application settings in that designer.

In your code, you'll access them like:

Properties.Settings.Default.<property name> = blah;

to save, you'd do:

Properties.Settings.Default.Save();

they'll be auto-loaded when your app is loaded.

There are some annoying details to get everything working in the real world, but this will get you started Smile | :)

.

Thanks for the response. However, I am looking for clean way of loading/saving the application preferences in a loosely coupled manner. I am using MVVM architecture for my application and there are some global settings and some local settings pertaining to a module.