|
maybe, I think I don't understand this code. 
What wrong if we call like that?
var client = new MyServiceClient();
client.GetDataAsync( (result) => {
textbox.Text = result;
});
Thanks and Regards,
Michael Sync ( Blog: http://michaelsync.net)
Microsoft MVP (Silverlight), WPF/Silverlight Insiders
|
|
|
|
|
In your example the UI will not wait for the call to the GetData service (since its async) but mine will. In my example the UI code will not run in the same thread as the service call but the UI code will only be invoked after the service call has completed...
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
Adriaan Davel wrote: In my example the UI code will not run in the same thread as the service call but the UI code will only be invoked after the service call has completed...
In my code also, the UI code will be invoked after the service called is completed. For example: textbox.Text = result;
Adriaan Davel wrote: In your example the UI will not wait for the call to the GetData service (since its async) but mine will
I haven't tested your code. The problem with sync call is that it makes the UI to be freezed while waiting for the completion. So, Microsoft decided not to support "sync" calls even a lot of people are requesting it.
So, how does it work with your code? How does the UI wait for the call? Will the UI be freezed while waiting? Or will the progressbar or something be shown? Is there any way to refactor the code so that Silverlight developers can call service sequentially like
service1.GetData();
service2.GetOptions();
Thanks and Regards,
Michael Sync ( Blog: http://michaelsync.net)
Microsoft MVP (Silverlight), WPF/Silverlight Insiders
|
|
|
|
|
Hi Michael,
You are correct, your example will also display the data, I wasn't looking carefully enough 
Microsoft's decision to prevent data operations from running on the UI thread is a real mind bender to me, I recon they wanted to protect the reputation of Silverlight from bad developers, so they made it harder for the rest of us. The fact of the matter is that certain things MUST wait for other things (in technology and in business), and the UI needs to be intuitive around the waits, so the UI must wait for certain operations to complete... We are now doing all sorts of jumps & hoops to acheive what is unavoidable...
I'm by no means a threading expert, but to achive your example of service1.GetData(); service2.GetOptions(); in a client side proxy class I think you would have to add a delegate parameter to service1.GetData();, and after all the code of the proxy method has executed you would invoke the delegate, not sure how you would handle the return values though... There might be other mechanisms to achive this, I'm sure one of the CP experts will enlighten us...
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
Adriaan Davel wrote: There might be other mechanisms to achive this, I'm sure one of the CP experts will enlighten us...
yeah..
In our project, we are sharing the service classes that invoke the WCF proxy between Silverlight and WPF. So, it's really painful and we can't ensure one function does one thing. If we follow one function does one thing then the code will be very messy like this example below with a lot of lambda expression.
void GetAllDogOwners(){
var dogServiceClient = new DogServiceClient();
dogServiceClient.GetAllDogsCompleted += (sender, e) => {
var dogs = e.Result;
var ownerServiceClient = new DogOwnerService();
ownerServiceClient.GetAllOwnersCompleted += (sdr, result) => {
var owners = result.Result;
foreach(var owner in owners){
owner.Dogs = (from dog in dogs
join person in owners
on dog.DogId equals person.OwnerID
select dog).ToObservable();
}
};
ownerServiceClient.GetAllOwnersAsync()
};
dogServiceClient.GetAllDogsAsync();
}
If I make if
void GetAllDogOwners(){
var dogServiceClient = new DogServiceClient();
dogServiceClient.GetAllDogsCompleted += new delegate(OnGetAllDogsCompleted);
dogServiceClient.GetAllDogsAsync();
}
void OnGetAllDogsCompleted(sender, e) {
var dogs = e.Result;
var ownerServiceClient = new DogOwnerService();
ownerServiceClient.GetAllOwnersCompleted += (sdr, result) => {
var owners = result.Result;
foreach(var owner in owners){
owner.Dogs = (from dog in dogs
join person in owners
on dog.DogId equals person.OwnerID
select dog).ToObservable();
}
};
ownerServiceClient.GetAllOwnersAsync()
}
we are thinking to remove all async calls now in WPF..
Thanks and Regards,
Michael Sync ( Blog: http://michaelsync.net)
Microsoft MVP (Silverlight), WPF/Silverlight Insiders
|
|
|
|
|
I think the point here though is semantics, not complexity or limitations.
The fact is, asynchronous doesn't mean you can't have the ui wait.
Doing:
enter
callandwait
leave
vs.
enter
beginasync
showmodaldialogforwaiting
leave
receiveasync
hidemodaldialogforwaiting
leave
Is a similar pattern. In other words, there is nothing to prevent you from locking the UI while you wait for the call. We have several pages that are aggregate controls for filters, locations, and other parameters that act on a grid and all must be pulled in before the user can react. Rather than create the awkward situation of freezing the ui while waiting, in which case the user has to be wondering, "What on earth is going?" We can simply set a global state and then lock down the UI and show a user-friendly animation, loading icon, hourglass, or whatever. As each collection of data comes in, the state is updated and when all controls are fully loaded then we remove the modal "hey, we're initializing" and go on with business as usual.
Would that be something that would work in your case? IMHO even if you need it to logically function as if synchronous, asynchronous gives you more flexibility to engage the user appropriately and notify them you are waiting for something as you pull in the call.
|
|
|
|
|
Yeah, I suppose its down to symatics. Functionally its is indisputable that we want to make the user wait for things before the UI responds to results of conditoins, now we just need to get technical work arounds to acheive the functional requirement.
Your example shows where 3 lines of code could achive the same as 7 lines of code for the same functionality, now imagine what the would look like if you were to do 5 different calls, passing the results from each call to the next, possible passing the same results to more than 1 call, managing the status of each async call could be a pain, and you will have far more code on the CPU & RAM than just doing sync calls...
I might be missing something here, but I do not get MS's decision here...
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
Hi Adriaan,
I know it's been a while since you posted your question, but for anyone else reading this thread I thought I'd mention that it is possible to perform synchronous WCF calls in Silverlight. You just can't do them from the UI thread.
Synchronous Web Service Calls with Silverlight: Dispelling the async-only myth[^]
Whether you should or not is another question. I believe that it is AOK to perform sync calls as long as they are not on the UI thread. Without sync call it is very easy to end up with spaghetti code.
Cheers,
Daniel
|
|
|
|
|
|
Your best bet is to ask in the forum that's under the article. The author understands how his code is supposed to work, and we don't.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
I did and like other people, he is not responding. Oh well, I guess I will find something else to use...
|
|
|
|
|
Sorry, I've never used it. I would suggest running his sample and looking for ways your code is different to his sample.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
Back in the late 90's Java was main stream and XML was becoming popular, a Sun researcher from China postulated that a Swing or AWT UI could be represented by dumping the widget cache to an XML file and then reconstituted using XML parser and Java Reflections.
I was unable to find the original white paper...
I used this researcher's design pattern on a contract once to create a XML version for winforms.
'Who said good things don't grow under the Sun?'
~TheArch
modified on Friday, July 10, 2009 4:48 PM
|
|
|
|
|
1 - this is not a question
2 - C# is obviously based on Java, so what else is new ?
3 - Sun is so awesome that they come up with these ideas, but can't make money off them. How many quarters have Sun made a profit in, in recent years ?
4 - anyone who is trying to create new technology would be stupid to set out NOT to learn from what people have done in the past.
Forgot to add - XAML is the worst thing about WPF. Too verbose, for one. It's often better to do stuff in code.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
Christian Graus wrote: 1 - this is not a question
Hmm, Kinda of thought this was an an implied question. Esp. if you can prove other wise.
Christian Graus wrote: 2 - C# is obviously based on Java, so what else is new ?
Yeah, kinda of, but I think the direct relationship faded around 3.0. 3.5 and 4.0 bring new ideas to the table, and Sun has been playing catch up since Generics.
Christian Graus wrote: 3 - Sun is so awesome that they come up with these ideas, but can't make money off them. How many quarters have Sun made a profit in, in recent years ?
Gotta love those guys, but it makes you wonder how many quarters Stanford's research grants increased...
Christian Graus wrote: 4 - anyone who is trying to create new technology would be stupid to set out NOT to learn from what people have done in the past.
Hmm, I wouldn't say stupid. Pig headed maybe.
Christian Graus wrote: Forgot to add - XAML is the worst thing about WPF. Too verbose, for one. It's often better to do stuff in code.
Well Okay, good point. What about designers? Don't they get to play? Try using Model Viewer Presenter with WPF. Where XAML = Viewer, xaml.cs = Presenter, You'r logic = Model. That might work better.
Wow, you owned an Apple ][!
Did you ever program Beagle Bro's?
|
|
|
|
|
TheArchitectualizer wrote: Yeah, kinda of, but I think the direct relationship faded around 3.0. 3.5 and 4.0 bring new ideas to the table, and Sun has been playing catch up since Generics.
True - but that is kind of my point. Innovation and the replication of good ideas from the past, are not mutually exclusive.
TheArchitectualizer wrote: Wow, you owned an Apple ][!
Did you ever program Beagle Bro's?
Hell, yes. I spent hours reading through Beagle Brothers code and learning from it, I had their posters up on the wall around my computer. I loved those guys.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
Me to! My first programing book was Beagle Basic and Pro Dos. The IIe didn't have a clock so my fisrt attempt at programming was a huge sub to count the ticks and update the clock on my BBS with out have to buy a $240 add in board just to tell what time it was. Little did I know I was reinventing multi tasking.
|
|
|
|
|
You can see a demo of my quick and dirty implimentation of MVP in my most recent article:
Big O Algroythm Analyzer for .NET[^]
Q: Would you mind voting on it?
Q: I could use some mentoring, would you be my mentor?
|
|
|
|
|
Christian Graus wrote: 4 - anyone who is trying to create new technology would be stupid to set out NOT to learn from what people have done in the past.
With their upcoming "M" meta-language, I wonder how long it will be before some one make a new declarative curly brace based language.
One which act like XAML but feels like C#!
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.
|
|
|
|
|
TheArchitectualizer wrote: Back in the late 90's Java was main stream and XML was becoming popular, a Sun researcher from China postulated that a Swing or AWT UI could be represented by dumping the widget cache to an XML file and then reconstituted using XML parser and Java Reflections.
And here I was, thinking some idiot at Microsoft just pulled it outa' their ass. In any case, I like my version better because it's a better fit.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Uh hua, Uh hua, <nod>, Uh hua, <nod>, <nod>
Interesting bio.
|
|
|
|
|
|
I have to go check this out!
Been waiting for the cool navigation stuff.
|
|
|
|
|
Make sure you don't get caught out by attempting to install the consumer version when you already have Silverlight 2 Tools installed. I ran into that. You need to install the v3 Tools and all will be OK.
Kevin
|
|
|
|
|
Thanks, I will watch for that.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)