Comments for Reed Copsey, Jr.

Comment on WPF – Common Dependency Property Exception by Steve

Steve — Sat, 04 Sep 2010 01:57:48 +0000

Here’s a suggested topic: FrameworkPropertyMetadata and setting the default binding mode (as well as a host of other settings).

Comment on WPF – Common Dependency Property Exception by Steve

Steve — Sat, 04 Sep 2010 01:54:52 +0000

Now THAT’s a good blog article !
I always appreciate it when someone really knows what they’re talking about.

Comment on Long overdue Enum goodness in .NET 4 by Quagmandir

Quagmandir — Sun, 08 Aug 2010 02:47:02 +0000

Sorry for the necromancy but, I found you whilst looking for Enum goodies.

Now, as I have only today found this out myself, I felt I had to point out that the following statement is inaccurate:

“Unfortunately, removing a flag isn’t quite as easy.”

I believe you can use:

variable &= ~TestFlags.Sixteen;

The ( ~ ) operator, apparently, AND’s the _negative_ of the given flag.

Thanks, and enjoy!

Comment on Better User and Developer Experiences – From Windows Forms to WPF with MVVM: Conclusion by Adam

Adam — Mon, 26 Jul 2010 19:38:57 +0000

Great series.. thanks for taking the time to write it. This will definitely help me as I transition from WinForms to Silverlight (and hopefully some WPF).

Comment on Using Behaviors to Allow the ViewModel to Manage View Lifetime in M-V-VM by Reed

Thu, 22 Jul 2010 22:48:17 +0000

Dave,

The behavior, as is, just provides a single point where you can prevent the Window from being closed. It does this by checking the CanExecute on the ICommand.

One simple option:

The command’s CanExecute property, here, could prompt the user with a OK/Cancel button (and return false on Cancel). This would warn the user, and they’d have to hit “OK” to allow it to close without saving.

Comment on Using Behaviors to Allow the ViewModel to Manage View Lifetime in M-V-VM by Dave

Dave — Thu, 22 Jul 2010 20:14:40 +0000

How would you use this to warn a user they are going to lose their changes if they don’t save?

Comment on Parallelism in .NET – Part 18, Task Continuations with Multiple Tasks by Tweets that mention Blog series on Parallelism in .NET. Part 18, Task Continuations with Multiple Tasks #csharp #dotnet #TPL -- Topsy.com

Tue, 20 Jul 2010 01:53:50 +0000

[...] This post was mentioned on Twitter by ajlopez, Vicente Cartas and Vicente Cartas, Reed Copsey, Jr.. Reed Copsey, Jr. said: Blog series on Parallelism in .NET. Part 18, Task Continuations with Multiple Tasks http://bit.ly/anerWh #csharp #dotnet #TPL [...]

Comment on Parallelism in .NET – Part 13, Introducing the Task class by Parallelism in .NET – Part 18, Task Continuations with Multiple Tasks : Reed Copsey, Jr.

Tue, 20 Jul 2010 01:19:45 +0000

[...] to how the Task class static methods providing a way to block until multiple tasks have completed, TaskFactory contains static methods which allow a continuation to be scheduled upon the completion [...]

Comment on Parallelism in .NET – Part 17, Think Continuations, not Callbacks by Parallelism in .NET – Part 18, Task Continuations with Multiple Tasks : Reed Copsey, Jr.

Tue, 20 Jul 2010 01:18:41 +0000

[...] my introduction to Task continuations I demonstrated how the Task class provides a more expressive alternative to traditional [...]

Comment on Synchronizing .NET 4 Tasks with the UI Thread by Reed

Tue, 06 Jul 2010 17:58:18 +0000

Tillias,

That’s actually not accurate. The default TaskScheduler, which is what is used when you do Task.Factory.StartNew, will use always use a ThreadPool thread to execute your Task, unless the LongRunning hint is specified, in which case it will use a dedicated thread (in .NET 4′s implementation). Either way, it should NEVER run on the UI thread, since the UI thread should never be on a ThreadPool thread.

Tasks will only get scheduled on the current thread when the current thread is a threadpool thread, or the current thread is blocking on the result of a collection of Tasks (including the one that needs to execute).

That being said, if you want to force a task to run on a dedicated thread, you can do so by specifying the LongRunning hint (in the current implementation). This is a much simpler alternative to creating a custom TaskScheduler. Using an STA thread scheduler is really overkill, unless you specifically need an STA thread.

-Reed

Comment on Synchronizing .NET 4 Tasks with the UI Thread by tillias

tillias — Tue, 06 Jul 2010 17:10:53 +0000

Hi Reed!
Task doesn’t guarantee that it will be executed in separate thread. I’ve faced several common scenarios where Task’s delegate is executed in GUI thread and thus the application is stuck. Custom TaskScheduler must be used in order to guarantee that task will be executed in separate thread ( and not in the same GUI one).

You can reed about it here: http://tillias.wordpress.com/2010/07/05/net-4-system-threading-tasks-and-wpf-ui-thread/

Comment on Lazy initialization in .NET 4 – Lazy by Murder, Blood and Thread Safe Singletons | #2782 - Thinking about agile (small 'a') software development, patterns and practices for building Microsoft .NET applications.

Sun, 20 Jun 2010 02:16:45 +0000

[...] Reed Copsey Jr. blogged about this and he gave me some pointers on my initial implementation. Here I’ve sealed the class and made the constructor private, rather than protected. Usually I’m not a big fan of sealing classes but in [...]

Comment on Parallelism in .NET – Part 8, PLINQ’s ForAll Method by Parallel Programming with .NET

Parallel Programming with .NET — Sun, 23 May 2010 17:51:44 +0000

“Parallelism in .NET” Series by Reed Copsey, Jr….

Reed Copsey, Jr. has been writing a great series of articles on parallelism with the .NET Framework 4…

Comment on Parallelism in .NET – Part 4, Imperative Data Parallelism: Aggregation by Parallel Programming with .NET

Parallel Programming with .NET — Sun, 23 May 2010 17:51:28 +0000

“Parallelism in .NET” Series by Reed Copsey, Jr….

Reed Copsey, Jr. has been writing a great series of articles on parallelism with the .NET Framework 4…

Comment on Parallelism in .NET – Introduction by Parallel Programming with .NET

Parallel Programming with .NET — Sun, 23 May 2010 17:51:12 +0000

“Parallelism in .NET” Series by Reed Copsey, Jr….

Reed Copsey, Jr. has been writing a great series of articles on parallelism with the .NET Framework 4…

Comment on Parallelism in .NET – Introduction by Bruce

Bruce — Wed, 19 May 2010 14:50:20 +0000

[...] This post was mentioned on Twitter by Reed Copsey, Jr., Caspar Kleijne. Caspar Kleijne said: #rocks #mustread: #Parallelism in .NET. Introduction: http://bit.ly/4MEr7h #csharp #dotnet /via @ReedCopsey [...]

Comment on Better User and Developer Experiences – From Windows Forms to WPF with MVVM: Conclusion by Reed

Thu, 29 Apr 2010 21:02:04 +0000

Dean,

Glad I can help

-Reed

Comment on Better User and Developer Experiences – From Windows Forms to WPF with MVVM: Conclusion by Dean Thrasher

Dean Thrasher — Thu, 29 Apr 2010 20:46:02 +0000

Thanks for posting this series of articles, Reed. I understand WPF and the MVVM pattern much better now. It helps to see how things have changed and evolved since the WinForms days!

Comment on Parallelism in .NET – Part 11, Divide and Conquer via Parallel.Invoke by Reed

Wed, 28 Apr 2010 22:55:20 +0000

John,

It actually does 2^cpus, as you saw. I’d have two comments for this, however. First, this was really just written as an example – I’m sure to get this completely optimal, you’d have to find the right balance here. I suspect that this does run faster with extra work (I picked those numbers after profiling) for reasons such as non-optimal pivots, uneven workloads in comparisons, and other similar issues.

That being said, it is often better to have more work items than processors. Depending on the work involved, even CPU intensive work often runs faster if given a few extra threads. It’s all about profiling your algorithm, and finding the right balance.

Comment on Parallelism in .NET – Part 11, Divide and Conquer via Parallel.Invoke by John Lilley

John Lilley — Wed, 28 Apr 2010 21:35:41 +0000

I’m trying to understand the maxDepth setting, but it looks like setting maxDepth=Cpus will result in 2^Cpus threads, as opposed to CPUs threads? Is this true?

Given the potential lopsided-pivot problem of qsort(), is it sometimes better to choose more parallelism than CPUs “just in case” some of the problem sub-parts are much faster than the others?

Comment on Parallelism in .NET – Part 17, Think Continuations, not Callbacks by uberVU - social comments

uberVU - social comments — Mon, 26 Apr 2010 12:36:24 +0000

Social comments and analytics for this post…

This post was mentioned on Twitter by ReedCopsey: Blog series on Parallelism in .NET. Published Part 17, Think Continuations, not Callbacks http://bit.ly/9LnctL #csharp #dotnet #TPL…

Comment on Parallelism in .NET – Part 15, Making Tasks Run: The TaskScheduler by Parallelism in .NET – Part 17, Think Continuations, not Callbacks : Reed Copsey, Jr.

Mon, 19 Apr 2010 20:27:57 +0000

[...] The maintainability and ease of understanding drops. However, just as a standard Task can be created with a TaskScheduler that uses the UI synchronization context, so too can we continue a task with a specific context. There are Task.ContinueWith method [...]

Comment on Using Behaviors to Allow the ViewModel to Manage View Lifetime in M-V-VM by Attached Property port of my Window Close Behavior : Reed Copsey, Jr.

Attached Property port of my Window Close Behavior : Reed Copsey, Jr. — Thu, 15 Apr 2010 21:12:49 +0000

[...] on The Code Project. It is a port of the MVVM-friendly Blend Behavior I wrote about in a previous article to use Attached Properties instead of a Blend [...]

Comment on 2010 Visual C# MVP Award by Nish

Nish — Thu, 15 Apr 2010 21:09:52 +0000

Congratulations Reed! Totally well deserved award!

Comment on Long overdue Enum goodness in .NET 4 by Moby Disk

Moby Disk — Wed, 14 Apr 2010 20:07:59 +0000

Enum is still missing the most obvious one:

public static TEnum Parse(string value, bool ignoreCase);

It can’t infer the enum type since it is a return value, but it still beats passing typeof(T). Oh well.