Click here to Skip to main content
12,696,493 members (28,479 online)
Rate this:
 
Please Sign up or sign in to vote.
I AM BEING DRIVEN MAD BY THIS :(

So I'm trying to write a Metro App. Leaving aside the tiresome fact that half the framework has been ripped out, there is one thing which I just can't get right.

I want to get all the files in a folder (recursively actually but that bit doesn't matter) and I want to do it synchronously. I believe StorageFolder is the class for this as it represents a folder.

Now if it had a GetFiles() method I'd be happy, but instead its got GetFilesAsync(). All I want to do is call this method synchronously.

Now if I call this, it just returns immediately which I understand is the nature of async calls when they block. So I could await for it to finish:

IReadOnlyList<StorageFile> f = await requestedFolder.GetFilesAsync();

But that would mean having to mark the calling method as async and would just propagate the pain to the method above it. And so it goes on, in order to wait for a method to finish you need to 'await' but that means making the caller async etc. etc. until the whole application has become one massive asynchronous soup.

Bearing in mind async methods return Tasks, I've tried Wait()ing on that but that just causes immediate deadlock (on a single thread from what I can tell - nice).

Any ideas? No smart answers about Google being my friend - it isn't. I've been pleading with it for the last 5 hours for an answer.
Posted 18-Oct-12 5:33am
Comments
Sergey Alexandrovich Kryukov 18-Oct-12 12:16pm
   
I never tried it (and don't really want to), but I have bad impression about Metro. I looked for API and found the lack of synchronous methods in Storage. And, long time ago, I got an opinion that asynchronous methods are just lame. They flourished (to certain extent) when multithreading was not a commonplace, so many developers were afraid of creating threads. In fact, multithreading on the level of application is way more straightforward than asynchronous API. Of course, you often need thread synchronization primitives, but when one learns them, their usage becomes universal, agnostic to the application, while all asynchronous APIs are application-specific. Also, with threads you have more control, and the logic is more linear. Maybe I miss something, but I really fail to see a reason for such API, and the lack of the synchronous API (with blocking calls, of cause) does not seem any reasonable to me.

As I share your concerns, I voted 5 for the question. Sorry that I cannot help you at the moment; all I could advise is to avoid Metro. I really don't need any understanding of who may need it and why... There is a good number of some Microsoft technologies which went nowhere, only contaminated heavy legacy load of the OS distributions; who knows, maybe Metro is one of those things... I would rather wait for Midory, still hope they eventually complete this OS, the only reasonable way to go I can see...

--SA

1 solution

Rate this: bad
 
good
Please Sign up or sign in to vote.

Solution 1

Have you tried the AsTask() extenstion method? This may be what you need.

Signature:
WindowsRuntimeSystemExtensions.AsTask<tresult> Method (IAsyncOperation<tresult>)

MSDN Link
AsTask Method
    var f = requestedFolder.GetFilesAsync().AsTask();
    
    IReadOnlyList<storagefile> f = theTask.Result;
  Permalink  
v2
Comments
Rob Philpott 19-Oct-12 12:47pm
   
Nice.

That actually seems to work so thanks very much.

I suppose what they're trying to ensure is that the GUI thread never blocks in order to maintain fluidity of the UI. I can fire this bit of code of on a background thread, but then I suppose without signalling I'm always left with either a Join() or an EndInvoke() both of which are going to block.

Confusing stuff all-in-all.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month


Advertise | Privacy | Mobile
Web01 | 2.8.170118.1 | Last Updated 18 Oct 2012
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100