WPF Discussion Boards

Re: Weak reference keeping objects alive with Mediator

13-Mar-11 1:39

SledgeHammer01 wrote:
If a view doesn't unsub from something and causes a leak, why not fix the view rather then hide the problem?

COuldn't agree more!

S'funny. I started off a while ago asking about why people use messages rather than events - I mean my ViewModel can subscribe to an event raised by another "some singleton object" in response to a request by a ViewModel

I didn't get the difference between that and the situation where my ViewModel can subscribe to a message sent by "some singleton object" in response to a request by a viewmodel.

The difference as I understood it was allowing weak references to be used - but that's really only an advantage I think if you subscribe from one VM directly to an event raised by another VM - rather than some singleton...

I feel lI must be missing something, and perhaps need to go back and read the various articles about this - because I'm back to squeare one again now - thinking I may as well use familiar old events

___________________________________________
.\\axxx
(That's an 'M')

_Maxxx_13-Mar-11 15:10

A basic KIOSK application using WPF/ Silverlight

13-Mar-11 15:10

SledgeHammer01 wrote:
WeakReference has the IsAlive property that you can use.

Unfortunately you're mistaken Frown | :(

The IsAlive property tells you if the object has been garbage collected - not if it is ready for Garbage Collection - so my problem persists.

What I think is needed is a "int TheIbjectReferencedByThisWeakReferenceHasThisManyHardReferences" property (or a bool with HasAnyHardReferences) At least that way I can see that as there are no hard references, I should not use the object (as the GC really should be cleaning it up) and should probably delete my Weak reference.

___________________________________________
.\\axxx
(That's an 'M')

Member 365700710-Mar-11 20:50

Member 3657007

10-Mar-11 20:50

Hi,

I need to develop a KIOSK application in dotnet technologies, like WPF, Silverlight, Expression Blend etc. But I have no idea on how to start this. If you have worked on this, could you share your experiences please? Any sample code provided will be much appreciated.

Thanks in advance,
nishant

Re: A basic KIOSK application using WPF/ Silverlight

Abhinav S10-Mar-11 21:24

Abhinav S

10-Mar-11 21:24

if you've not really programmed on WPF / Silverlight before, you migth want to start with some videos / tutorials on msdn or other websites.

The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.

Re: A basic KIOSK application using WPF/ Silverlight

Richard MacCutchan10-Mar-11 22:31

Richard MacCutchan

10-Mar-11 22:31

Member 3657007 wrote:
But I have no idea on how to start this.

The best starting point would be to buy a book and look at some of the articles here on CodeProject. However, unless you have a reasonable level of experience in C# or VB.NET you have a long learning path ahead of you.

I must get a clever new signature for 2011.

Re: A basic KIOSK application using WPF/ Silverlight

Member 365700710-Mar-11 23:02

Member 3657007

10-Mar-11 23:02

I have done quite a lot programming in C#. I just wanted to know about developing kiosk applications. Anyways thanks for your response.

Re: A basic KIOSK application using WPF/ Silverlight

Richard MacCutchan10-Mar-11 23:48

Richard MacCutchan

10-Mar-11 23:48

Member 3657007 wrote:
I just wanted to know about developing kiosk applications.

Did you try this[^]?

I must get a clever new signature for 2011.

MVVM Messenger / Mediator question

_Maxxx_9-Mar-11 15:29

9-Mar-11 15:29

I've been using the Mediator pattern for a while in MVVM - specifically using the MVVMFoundation implementation mostly.

So this pattern allows you top broadcast a message that can be subscribed to by one or more classes (usually ViewModels) and handled by them.

What I am trying to do at the moment is extend this pattern as follows (an example is worth 1K words)

Customer Lookup allows user to select a customer, and will open an 'Edit' window for that customer. The window is not opened modally.

The user, then, can select the same customer again for editing (because the user is daft).

So I would like the Customer Lookup Vm to send out a 'This customer has been selected' message, to which the Customer Edit VM would subscribe.

If , as a Customer Edit VM I receive the message, and I am currently editing that same customer, then I can take some action (show a 'Silly User' message for example).
If I receive the message and I am not editing that same customer, I can ignore the message.

But if the message is sent and ignored by all VMs out there (because there isn't one editing this particular customer) then I need to get a new Customer Edit VM created to go edit this customer.

Now, I'd like to do this reasonably generically, so I started looking at the Messanger class, to see if I can't add to it, to enable 'IsHandled" type properties. And it works well.

Except!

My Customer Lookup is the first VM instantiated, and so is the first Vm to register to receive the message - and so handles it immediately - without giving he other ViewModels a chance!

Obviously, sending the messages is handled in a loop - so I could reverse the order - but it may not be the last instantiated View Model that I want to handle a message.
Or I could add a 'priority' to the message registration process - and sort the responses in priority order, so that my Edit VMs see the message first.
Or, I could change the messaging into a two-step process - the first stage asks who can handle the message, and the second stage decides who to give the message to.

I guess what I'd like is to hear some discussion on this. Have you done something similar (is there some code out there I can ~~steal~~ look at for inspiration? Have you overcome similar problems some other way?

___________________________________________
.\\axxx
(That's an 'M')

SledgeHammer019-Mar-11 17:21

SledgeHammer01

9-Mar-11 17:21

Sounds like you would need a blocking "broadcast to everybody but x" and if e.Handled = false afterwards, send to x. Listener registeration is in indeterminate order, so you can't really depend on order to know who the fallback listener is.

Pete O'Hanlon9-Mar-11 20:06

9-Mar-11 20:06

If customer lookup is VM that is raising the message, why is it subscribing to it? The whole point is to allow disparate VMs to communicate with each other, so the originating VM doesn't need to be a listener. Perhaps I have misunderstood your scenario, but it seems like the fix is to remove the listener from the originating VM.

I'm not a stalker, I just know things. Oh by the way, you're out of milk.

Forgive your enemies - it messes with their heads

_Maxxx_9-Mar-11 21:25

9-Mar-11 21:25

Hi Pete

The issue is (and bear in mind this is not a real application as yet):

If my VM Customer Lookup sends a message out to say "HEy, the User just selected Customer 123" then something needs to handle the message.

I possibly have not yet instantiated a Customer Edit VM, so don't know if there's anyone out there listening for the message.

My idea was to send the message, then if nobody handles it, handle it myself by getting a CustomerEdit VM instantiated to edit this Customer.

So the only reason the listener is there in the lookup is to handle the instantiation of a VM to handle the event.

I could (of course) have the VM keep a list of all the CustomerEdit VMs it has had instantiated, and compare any new selection against that list, only instantiating a new one should I need to - but that would require my Look UP VM having references to all of the Edit VMs.

___________________________________________
.\\axxx
(That's an 'M')

Pete O'Hanlon9-Mar-11 21:33

9-Mar-11 21:33

No it doesn't. The change you need to make to your messenger class is to see if there are any listeners for that message. Presumably it's in a dictionary internally, so all you need do is check the count of references against that message and react accordingly. In fact, that's such a useful modification that I am going to change my implementation accordingly. Thanks for the idea.

I'm not a stalker, I just know things. Oh by the way, you're out of milk.

Forgive your enemies - it messes with their heads

_Maxxx_9-Mar-11 22:57

9-Mar-11 22:57

I don't know how to express my gratitude. It's so obvious now I don't know how I didn't think of it!

___________________________________________
.\\axxx
(That's an 'M')

Pete O'Hanlon9-Mar-11 23:12

9-Mar-11 23:12

Actually, I owe you gratitude. I didn't think of doing this, but now that I've put it in I can see how useful it is. You gave me the inspiration, so thank you.

I'm not a stalker, I just know things. Oh by the way, you're out of milk.

Forgive your enemies - it messes with their heads

_Maxxx_9-Mar-11 23:45

9-Mar-11 23:45

Well, you know what they say about Inspiration and Perspiration...

Incidentally, I am also passing a Message object around with my messages. This object (amongst other things) allows each Message handler to report whether it has handled the message (and gives it the option to stop the message being sent to any other handlers.

so my implementation rather than returning an effective boolean, returns

MessageHandled,
MessageNotRegistered,
MessageAborted,
MessageRegisteredNotHandled

So , for example, I can send out a message to perform some action, but all of the potential handlers may be too busy, so I get a MessageRegisteredNothandled return value.

This is very much a work In Progress, so I haven't worked out all the ins and outs, but it seems to solve some of the potential issues I was worrying about.

___________________________________________
.\\axxx
(That's an 'M')

Pete O'Hanlon10-Mar-11 0:14

10-Mar-11 0:14

_Maxxx_ wrote:
MessageAborted,

That's interesting. Something I've been struggling with myself for a while is whether the Mediator should wrap exceptions up, or just fail at the first instance. There are arguments for and against this, and I've been toying with the idea that the mediator should have a WorkResult object which includes this information. If I do this, then the status would be the enumeration, and the exceptions would be stored in there as well.

I'm not a stalker, I just know things. Oh by the way, you're out of milk.

Forgive your enemies - it messes with their heads

_Maxxx_10-Mar-11 1:00

10-Mar-11 1:00

Great minds ... etc.
When I started looking into this sort of thing, the problems started to grow. For example, if a Message Handler throws an exception, and catches it, then stores it in the WorkResult object there are two choices - the Mediator aborts as soon as one handler throws an exception, or it continues to try any other handlers - and if they throw exceptions, do you start keeping collections of the damn things?

If the mediator itself gets an unhandled exception, then returning it to the sender might be a good idea - but then why not just leave it unhandled? it is, after all, an exception?

___________________________________________
.\\axxx
(That's an 'M')

Pete O'Hanlon10-Mar-11 1:43

10-Mar-11 1:43

Well, I've changed my implementation and I'm busy testing it out now. The reason I've been toying around with this idea is that in some cases I've wanted to have some VMs continue processing even when one has failed due to a SQL exception because I can handle this later on. This change could be useful.

I'm not a stalker, I just know things. Oh by the way, you're out of milk.

Forgive your enemies - it messes with their heads

_Maxxx_10-Mar-11 2:22

10-Mar-11 2:22

It'll be interesting to see how it works out.
In these sort of cases are you trapping the exception in the VM and adding the info to the Mediator object, or do you leave the exception for the mediator to trap and log?

The reason I;m looking at all of this right now is that I'm writing an article (I say AN article, it's likely to be a series of about twenty the way I'm going!) about they way I'm doing MVVM

As usual with this sort of thing, as soon as I start to describe the whys and wherefores, I think of additional things I'd like to do, and the whole thing expands and expands...

The good thing is that I end up with a good, well thought out "framework" - I just will have to draw the line in the sand somewhere!

___________________________________________
.\\axxx
(That's an 'M')

Pete O'Hanlon10-Mar-11 2:37

10-Mar-11 2:37

_Maxxx_ wrote:
In these sort of cases are you trapping the exception in the VM and adding the
info to the Mediator object, or do you leave the exception for the mediator to
trap and log?

It really depends. I'm a great believer in trapping and handling errors where you can. In some cases though, I want the exception to bubble upwards - but because of the loose coupling between the VMs, I want to still allow the others to continue. In this case, the result is acting almost like a mediator message in its own right - the mediator becomes aware of the exception, but it can still continue.

I'm not a stalker, I just know things. Oh by the way, you're out of milk.

Forgive your enemies - it messes with their heads

Pete O'Hanlon9-Mar-11 22:38

9-Mar-11 22:38

To give you an idea, this is my implementation now:

public NotificationResult NotifyColleagues<T>(T message, object args)
{
  NotificationResult result = NotificationResult.Successful;
  lock (SyncLock)
  {
    if (internalList.ContainsKey(message))
    {
        if (internalList[message].Count == 0)
      result = NotificationResult.NoListenersForMessage;
        //forward the message to all listeners
        foreach (Action<object> callback in internalList[message])
      callback(args);
    }
    else
    {
        result = NotificationResult.MessageNotRegistered;
    }
  }

  return result;
}

I'm not a stalker, I just know things. Oh by the way, you're out of milk.

Forgive your enemies - it messes with their heads

_Maxxx_9-Mar-11 22:58