views:

57

answers:

2

Hi

I have a problem with calling WCF Service methods with Silverlight 3.

private bool usr_OK = false;

clientService.CheckUserMailAsync(this.mailTF.Text);


if (usr_OK == true)
{ isValidationOK = true; }
else { isValidationOK = false; MessageBox.Show("User already exists.", "User registered succes!", MessageBoxButton.OK); }

CheckUserMail should change usr_OK parameter. However it runs in other thread and it does not change the usr_OK param before IF block begins. I've tried thread.join byt the application freezed and i do not know what to do else. Please help me...how can i wait for WCF method to return param usr_OK.

+1  A: 

Bind the code that checks the usr_OK variable in the event handler for CheckUserMailCompletedEvent

clientService.CheckUserMailCompleted += new EventHandler<CheckUserMailCompletedEventArgs> (clientService_CheckUserMailCompleted);
clientService.CheckUserMailAsync(this.mailTF.Text);


void clientService_CheckUserMailCompleted(object sender, CheckUserMailCompletedEventArgs e) {
    if (usr_OK == true) {
        isValidationOK = true; 
    }
    else {
        isValidationOK = false; 
        MessageBox.Show("User already exists.", "User registered success!", MessageBoxButton.OK);
    }
}
Sijin
OK...that will work. But is there a way to wait for method to end. Threads does not seam to work.
Rafal
I would like to use private AutoResetEvent m_autoResetEvent = new AutoResetEvent(false);
Rafal
This is how silverlight works. There is no support for synchronous web service calls by design.
Erv Walter
+2  A: 

The most direct answer to your question: Don't block on WCF calls. They make it hard for a reason. There, quite likely, is no way to block if you even tried... but don't.

Elaboration: The mode of operation for Silverlight is Asyncronicity. This is something you have to get used to when you are developing in Silverlight. They make it really hard for you to block on anything.

This is a good thing, in my opinion. When you block on the result of something like a WCF service call, you are ultimately blocking the user thread. It does require some getting used to on the developer's part, but again... get used to it.

Lets say you have code that you want to go like this (Synchronous) :

var theResult = clientService.DoSomething(foo);
Process(theResult);

The way to re-write it would be like this (Asynchronous) :

clientService.DoSomethingCompleted += (sender, args) => Process(args.Result);
clientService.DoSomethingAsync(foo);

Taking it a step further, I like to abstract my services out as interfaces (so I can replace them when testing, or running in stand-alone mode while developing). I take that as an opportunity to create an interface that looks like this:

public interface IMyService
{
    void DoSomething(string input, Action<string> whenComplete);
}

I implement the service like the async code above, and then when I call it, it is very clean and simple:

myService.DoSomething(foo, Process);

You will find that much of your system will morph into an asynchronous code base, but it might require you to re-adjust your expectations.

Brian Genisio
Thanks...i understand now:)
Rafal