Comments on: Property change notifications for multithreaded Silverlight applications

By: Philip Colmer

Philip Colmer — Tue, 27 Dec 2011 11:16:00 +0000

Solved it … I pass the synchronization context for the UI thread to the background thread which then posts to code that calls the registered event handler. It looks like that is the cleanest way to do it … not sure if it really is, but it works

By: Philip Colmer

Philip Colmer — Tue, 27 Dec 2011 10:50:00 +0000

Hi Jeff

I’ve used this to great effect to solve the issue of a background thread needing to update the UI but I’m now stuck where that same thread needs to call a registered event handler. The event handler is registered by a class created in the UI thread but it isn’t a data binding so your code doesn’t seem to help me solve this problem. Any suggestions on how to deal with this, e.g. an article I read, code to try, etc?

Thanks.

By: Anonymous

Anonymous — Thu, 20 Oct 2011 06:54:00 +0000

Either is fine. They are all the same instance.

By: Andreas Hammar

Andreas Hammar — Thu, 20 Oct 2011 06:52:00 +0000

Good stuff.

But, as Anthonywjones said, why not in the SmartDispatcher get the _instance from:

Deployment.Current.Dispatcher

instead of the RootVisual?

Thanks!

By: Bob Baker

Bob Baker — Sat, 17 Apr 2010 02:07:30 +0000

Hmm. Might be Resharper 5.0. I suspended it, and all error indications went away. Resharper seems to think there is no non-generic Action delegate.

By: Bob Baker

Bob Baker — Sat, 17 Apr 2010 01:56:43 +0000

Um, so this appears to be broken in VS2010 RTM. Anything using it built fine in the RC. There is no longer a type System.Action that does not require a generic (or more than one for that matter). Is is just broken on my machine (BOMM lol)?

By: Links (4/12/2010) « Steve Pietrek-Everything SharePoint/Silverlight

Links (4/12/2010) « Steve Pietrek-Everything SharePoint/Silverlight — Tue, 13 Apr 2010 02:06:39 +0000

[...] Property change notifications for multithreaded Silverlight applications [...]

By: Jeff Wilcox

Jeff Wilcox — Sun, 04 Apr 2010 16:56:04 +0000

Sure thing, glad to help.

On the Silverlight 4 thing, you will find that even my solution has some issues that would not work if this was baked into the platform, so its best addressed as a one-off thing for now in my opinion.

By: MicroInnovators

MicroInnovators — Sun, 04 Apr 2010 16:00:40 +0000

Thanks for providing the code. Im surprised this wasnt addressed in SL 4.

By: Anthonywjones

Anthonywjones — Sat, 03 Apr 2010 20:43:41 +0000

It is a sticky problem to solve.

It does smell all wrong to load the solution of this problem on to the data classes. The problem is a result of the way the UI works so it seems only fair that code in the UI should solve the problem. Instead what we have here is the data classes jump through hoops (including the introduction of base class) just in case it might make the UI code barf.

That said it is a pragmatic solution based on reasonable assumptions.

I’m curious about a couple of things though:-

Why not simply acquire a value for _instance from Deployment.Current during a static constructor on SmartDispatcher? It seems to me that would simplify some of the code.

Also are we sure that when running in a designer CheckAccess won’t be called? It may throw if it is since _instance may remain null.

By: Dew Drop – April 3, 2010 | Alvin Ashcraft's Morning Dew

Dew Drop – April 3, 2010 | Alvin Ashcraft's Morning Dew — Sat, 03 Apr 2010 15:00:21 +0000

[...] Property change notifications for multithreaded Silverlight applications (Jeff Wilcox) [...]

By: Haathen

Haathen — Sat, 03 Apr 2010 04:41:47 +0000

@Morten:
This article is about Silverlight and -unfortunately- here they can only be created on the UI thread.

See:
http://forums.silverlight.net/forums/p/164744/371088.aspx#371088

This has not been changed in RC.

By: Joe

Joe — Sat, 03 Apr 2010 02:47:25 +0000

Jeff,

Is there any hard and fast rule about not allowing the property name to be null when calling NotifyPropertyChanged()?

It has been my experience that you can use ‘null’ as a parameter and it has the effect of providing notification for all the properties, not just one specifically.

Regards,

Joe

By: Jeff Wilcox

Jeff Wilcox — Fri, 02 Apr 2010 20:46:39 +0000

@Morten,
Yeah, so I am making the assumption that the listening is only on the main UI thread. With the exception of MVVM zealots, who will already have solutions in place for this sort of thing, property change notifications are a majority (“80% is the number I randomly pick”) of what’s going to be done with those values for most people who aren’t taking this into account today.

By: Morten

Morten — Fri, 02 Apr 2010 19:08:54 +0000

Aren’t you assuming that other objects are listening to the propertychanged event on the UI Thread only? What if the background thread was spun up from another background thread. I would want my events to fire on the other backgronud thread, and not suddenly end up over in a UI thread.
I try only a use dispatcher when I know I’m dealing with UI Controls (ie I think only UI Controls should be using the dispatcher). If I’m just dealing with DependencyObjects, that’s a whole different story, since there’s no guarantee that these have been created on the UI Thread.