If I mark a property as [Lazy] what can go in the associated getter? Can I put a call to a WCF service call? And then set the property when I get back from the call? I poked around looking for documentation or examples and didn’t find them. (not that they might not be there somewhere)
you can’t have a getter/setter at all for lazy properties. Instead you use a := setter like:
[Lazy]
property Name: String := GetName();
You can put anything in the expression on the right, it won’t get called till you first use it.
Does that answer your question?
Yes and no. I think you are saying that I can’t do a WCF async call inside that GetName, for instance.
I tried to figure out using future and await too, but it looks like that can’t be used either.
GetName() should be able to do anything you like. but it (of course) must return a value, synchronously, as thats how properties work. If you want a future, you should define the property as being of future type, instead.
eg
property Name: future String := async Whatever();
Will the future allow ANY async activity? Can I call a WCF service in that async routine? Or does the Name property assisgnment wait for just the Whatever routine to finish?
Can you elaborate on how you want that to work? When should the async call start? WHat should happen when you access the property?
I guess what I’m looking for is when something tries to access the property, it would spin off a WCF call that would get the value for the property and, in the WCF Completed event, SOMEHOW, the property would get set from the information in the WCF call. And then the code would flow to the statement after the line that was trying to get the property.
Something like this could work (presuming the WCF call returns a task):
[Lazy]
property GetData: Task<String> := fWCFContext.GetDataAsync;
On the calling side you could then do await myClass.GetData.
Can your example also have WRITE property for GetData? Is that allowed?
I’m trying to make a test case now, but VS crashes when the compiler has a compile error and it takes a long time to reload it (45 projects in the solution). Not sure exactly what the case is that makes it crash. I think it happens when it is the first time compiling the project AND it has some sort of error. Seems to report the error and then crash. I’m sure it is just something with my very old compiler version.
Speaking of which, will this lazy and await stuff work with my Delphi Prism?
It shold have been := not read, fixed. And you can write to that (in which case the initial value will never be evaluated)
Prism: No it’s a feature I JUST introduced with latest Oxygene.
The last version of Prism is over two years old (Oxygene 6.0). This is a feature we shipped last week. I’appreciate if you’d consider renewing to an up-to-date version of Oxygene with us,as we do rely on Oxygene revenue to keep driving the language forward. We gave a lot of features and support and subscription extensions to Prism customers, all for free (as far as revenue we saw), but there’s a limit, if we want to stay in business.
—marc
I already bought at least one new version 
Just no time to switch over to it. I’d LOVE to do that, but the boss wants more new features in our app NOW, so I have to wait to update the project to a more recent version.
And I plug Oxygene whenever I can. Just this morning I was reading a comparison between C# and Swift and I posted a message to consider writing in C# or Pascal using RemObjects for iOS. So I’m doing what I can to get you more revenue.
I TRIED a while back to see if it would be a snap to move up to VS 2013 from 2010 that we run and that version of Oxygene that we upgraded, but it was NOT going to be a snap so I went back to coding in the platform that works for us now.
HOPEFULLY, things will ease up 1st quarter next year and we can try to actually move over to the version we have or even upgrade again to the latest one then.
(oh, and a co-worker is still coding in Delphi 5!!! Shows you the priority the boss places on using the latest compiler. I’ve been pushing him and pushing him to move to RemObjects, but so far he is just too busy)
ck: Can I still do something with the async and wait that allows the WCF service call? Or is that part also only working in your new version?
sure. You can get the same kind of logic by just writing out what the compiler does:
private fData: Task<String>;
method get_GetData: Task<String>;
property GetData: Task<String> read get_GetData write fData;
...
method MyClass.get_GetData: Task<String>;
begin
if fData = nil then
locking self do begin
if fData = nil then
fData := fWCFContext.GetDataAsync;
end;
exit fData;
end;
Great, I’ll see what I can do.
Also, I KNOW it is a lot more work, but it would be nice if the wiki documentation showed which version a feature was introduced in, or had a list of all supported versions, like Microsoft does in their.Net stuff. Just a suggestion.
Ok, after studying your code a bit, are you saying that the GetDataAsync is going to wait there to get the fData result? Usually, you have to set up the Completed handler. And then get your results out of the args argument of the callback routine. The magic TASK just makes it not work that way? Do I have to do something on the service side? I looked for stuff on this before, but I guess I will try to dig into the wiki again unless you have more clues for me.
I’m not sure i understand. What’s keeping you from using the latest version, then — are you having backwards compatibility problems? Any Oxygene code should just compile with the latest version, unchanged. This isn’t Delphi, where you’ll spend half year porting and adjusting everything, Unless we broke something we’re not aware of, you can literally just install Oxygene 8 on top of your Prism install, and start using the new features…
what problems did you have? were they related toVS, or to the Oxygene versions?
ouch! 
I don’t remember the problems I had. I think I also tried to move up to Silverlight 5 at the same time. Very possible THAT was the real problem, not Oxygene. I just remember it was not going to be a 5 minute process, or maybe not even a 5 day process.
And, although my boss had me download a VS 2013 that we thought we got as partners, it THINKS it is a trial version and has now expired so I can’t even try it again. Just no time to resolve all these issues at the moment. Working on stuff for a really big customer now so that gets TOP priority.
1 Like
ck: Thanks a log for that example, but I’m not getting the full picture. I usually do the async wcf calls something like this (I actually use MVVM, but this will suffice for example):
method MainPage.Button_Click(sender: System.Object; e: System.Windows.RoutedEventArgs);
begin
ServiceProxy.HostSource := Application.Current.Host.Source;
ServiceProxy.ServiceUri := new Uri( Application.Current.Host.Source, '..\Service.svc' );
var proxy := ServiceProxy.NewClient;
proxy.GetPeopleCompleted += proxy_GetPeopleCompleted;
proxy.GetPeopleAsync( 'F1E3BF94-A754-4B30-BE13-2C058DF4C5AB' );
end;
method MainPage.proxy_GetPeopleCompleted(sender: Object; e: GetPeopleCompletedEventArgs);
begin
fData := e.Result;
end;
So, from your example, is my equivalent of fWCFContext.GetDataAsync equivalent to my GetPeopleAsync? If it is, isn’t it going to return from the async call right away? I could see if it were a SYNC call that returned fData. But I’m just not seeing what exactly to do to be able to call WCF async in there.
These are pre-“TASK” async apis. Thats what causing the confusion. I think newer WCF does do tasks properly but in this case that’s a bit trickier, since you probably don’t even have a task class. the proper api for this should return a Task type, not use a callback.
Since I’m making the service, I can return a task If I knew how to do that. That is what I was trying to set up, but so far I don’t get the pattern. Haven’t turned up good examples on Bing yet.
Hopefully, Silverlight supports Task type apis. Any links you know would be appreciated.