WPF

backgroundWorker.DoWork += backgroundWorker_DoWork;

private void backgroundWorker_DoWork(object sender, DoWorkEventArgs e)

// Return the result.
e.Result = ??;

void client_GetDataCompleted(object sender, WinService.GetDataCompletedEventArgs e)

musefan wrote:

can you do a version that explains why code behind in a WPF application View is bad

private void F()
{
        // WCF service
	DatabaseServiceClient client = new DatabaseServiceClient();

	// First async
        client.GetSubsystemsByTestRunIDCompleted +=
          new EventHandler<GetSubsystemsByTestRunIDCompletedEventArgs>(client_GetSubsystemsByTestRunIDCompleted);
        client.GetSubsystemsByTestRunIDAsync(testRunID);

	// I want to use lstSubsystems list returned from first async in foreach loop
        treeAdditionalInfo.Items.Clear();
        foreach (string subsystemName in lstSubsystems)
        {
          TreeViewItem subsystemItem = new TreeViewItem();
          subsystemItem.Header = subsystemName;
          subsystemItem.FontSize = 14;
          treeAdditionalInfo.Items.Add(subsystemItem);
        }

	// Second async
        List<KeyValuePair<string, List<TestLogSmall>>> lstFormsAndActions =
          client.GetFormsAndActions(testRunID).ToList();
        client.GetFormsAndActionsCompleted +=
          new EventHandler<GetFormsAndActionsCompletedEventArgs>(client_GetFormsAndActionsCompleted);
        client.GetFormsAndActionsAsync(testRunID);

        ...
}

private void client_GetSubsystemsByTestRunIDCompleted(
  object sender, GetSubsystemsByTestRunIDCompletedEventArgs e)
{
  lstSubsystems = new List<string>();
  if (e.Error == null && e.Result != null)
    lstSubsystems = e.Result;
}

private void client_GetFormsAndActionsCompleted(
  object sender, GetFormsAndActionsCompletedEventArgs e)
{
  lstFormsAndActions = new List<KeyValuePair<string, List<TestLogSmall>>>();
  if (e.Result != null)
    lstFormsAndActions = e.Result;
}

client.GetSubsystemsByTestRunIDAsync(testRunID);

client.GetFormsAndActionsAsync(testRunID);

_Maxxx_ wrote:

(Just to show I'm not a complete doofus, I am aware that most Messenger implementations avoid potential memory leaks by using WeakReferences, which may be an advantage - but is that the only reason for using it?)

_Maxxx_ wrote:

I feel sure that there's a good reason for not doing this, but I'm stuffed if I can think what it is?

Pete O'Hanlon wrote:

. With event subscription you create an implicit hard relationship between the subscriber and the subscribee

Pete O'Hanlon wrote:

If you accept that one of the key tenets of MVVM is increasing testability

Pete O'Hanlon wrote:

having a mechanism that allows you to mock out the source of the "event" makes it much easier to test the VM.

Pete O'Hanlon wrote:

Message/Event. It's up to you how you want to do it.

Pete O'Hanlon wrote:

lighterweight

Pete O'Hanlon wrote:

Have a look at what Marlon and I did in MefedMVVM[^]

lmoelleb wrote:

1) The compiler (and refactoring tools) are unaware of messages. Basic errors normally displayed at compile time are now runtime errors.

Pete O'Hanlon wrote:

string based messages are prone to code smell

_Maxxx_ wrote:

It can't be Silverlight per se