Search Results

Search found 1486 results on 60 pages for 'winrt async'.

Page 2/60 | < Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • What is the right pattern for a async data fetching method in .net async/await

    - by s093294
    Given a class with a method GetData. A few other clients call GetData, and instead of it fetching data each time, i would like to create a pattern where the first call starts the task to get the data, and the rest of the calls wait for the task to complete. private Task<string> _data; private async Task<string> _getdata() { return "my random data from the net"; //get_data_from_net() } public string GetData() { if(_data==null) _data=_getdata(); _data.wait(); //are there not a problem here. cant wait a task that is already completed ? if(_data.status != rantocompletion) _data.wait() is not any better, it might complete between the check and the _data.wait? return _data.Result; } How would i do the pattern correctly? (Solution) private static object _servertime_lock = new object(); private static Task<string> _servertime; private static async Task<string> servertime() { try { var thetvdb = new HttpClient(); thetvdb.Timeout = TimeSpan.FromSeconds(5); // var st = await thetvdb.GetStreamAsync("http://www.thetvdb.com/api/Updates.php?type=none"); var response = await thetvdb.GetAsync("http://www.thetvdb.com/api/Updates.php?type=none"); response.EnsureSuccessStatusCode(); Stream stream = await response.Content.ReadAsStreamAsync(); XDocument xdoc = XDocument.Load(stream); return xdoc.Descendants("Time").First().Value; } catch { return null; } } public static async Task<string> GetServerTime() { lock (_servertime_lock) { if (_servertime == null) _servertime = servertime(); } var time = await _servertime; if (time == null) _servertime = null; return time; }

    Read the article

  • WinRT 8.1 Phone - ListView reordering

    - by Jan Kratochvil
    I need to create a reorderable ListView in a Windows Phone 8.1 app created using WinRT. The XAML is the following (it binds to an ObservableDictionary in the codebehind): <Grid Margin="24"> <ListView x:Name="MainListView" CanDragItems="True" CanReorderItems="True" AllowDrop="True" VerticalAlignment="Stretch" HorizontalAlignment="Stretch" > <ListView.ItemTemplate> <DataTemplate> <Border Padding="24" Margin="16" Background="CadetBlue"> <TextBlock Text="{Binding}" /> </Border> </DataTemplate> </ListView.ItemTemplate> </ListView> </Grid> The ListView does nothing when I try to reorder the items (it looks like the "reordering mode" is not activated). When I run this sample in Windows 8.1 (the XAML is shared) it works as expected. According to the documentation Windows Phone 8.1 should be supported. Is this functionality supported on the phone (and the documentation wrong) or do I need to do something special for the phone?

    Read the article

  • WinRT ControlTemplate ItemsPanel

    - by user1427149
    I'm new to WinRT and am trying to create a standard gridview which has a group heading with a number of tiles beneath it. That bit is easy. I'm trying to modify it so that beneath the grid of tiles I can also add a footer using the containers style: <GridView x:Name="itemGridView" AutomationProperties.AutomationId="ItemGridView" AutomationProperties.Name="Grouped Items" Margin="116,0,40,46" ItemsSource="{Binding Source={StaticResource groupedItemsViewSource}}" ItemTemplate="{StaticResource Project200x200ItemTemplate}" SelectionMode="None" IsItemClickEnabled="True" ItemClick="ItemView_ItemClick"> <GridView.ItemsPanel> <ItemsPanelTemplate> <VirtualizingStackPanel Orientation="Horizontal"/> </ItemsPanelTemplate> </GridView.ItemsPanel> <GridView.GroupStyle> <GroupStyle> <GroupStyle.HeaderTemplate> <DataTemplate> <Grid Margin="1,0,0,6"> <Button AutomationProperties.Name="Group Title" Content="{Binding Name}" Click="Header_Click" Style="{StaticResource TextButtonStyle}" FontWeight="{Binding IsSelected, ConverterParameter=FontWeight, Converter={StaticResource BooleanToFontWeightConverter}}" /> </Grid> </DataTemplate> </GroupStyle.HeaderTemplate> <GroupStyle.Panel> <ItemsPanelTemplate> <VariableSizedWrapGrid Background="Red" Orientation="Vertical" Margin="0,0,40,0" /> </ItemsPanelTemplate> </GroupStyle.Panel> <GroupStyle.ContainerStyle> <Style TargetType="GroupItem"> <Setter Property="Template"> <Setter.Value> <ControlTemplate> <StackPanel> <ContentPresenter/> <ItemsPresenter/> <TextBlock Text="*** End of group ***"/> </StackPanel> </ControlTemplate> </Setter.Value> </Setter> </Style> </GroupStyle.ContainerStyle> </GroupStyle> </GridView.GroupStyle> </GridView> This almost works but after adding the container style, the grid of tiles no longer shows... the group header and 'End of group' textblock is showing, but I've lost the tile grid. Can anyone spot what I'm doing wrong...?

    Read the article

  • F# Async problem.

    - by chrisdew
    Hi, I've written a dummy http server as an exercise in F#. I'm using Mono 2.4.4 on Ubuntu 10.04 x86_64, with MonoDevelop. The following code fails to compile with the error: Error FS0039: The field, constructor or member 'Spawn' is not defined (FS0039) Could someone try this in VisualStudio please, I don't know whether this is a Mono problem, or my problem. I have tried several Async examples from the F# book, and they also all produce similar messages about Async.* methods. Thanks, Chris. #light open System open System.IO open System.Threading open System.Net open System.Net.Sockets open Microsoft.FSharp.Control.CommonExtensions printfn "%s" "Hello World!" let headers = System.Text.Encoding.ASCII.GetBytes("HTTP/1.0 200 OK\r\nContent-Type: text/html; charset=UTF-8\r\nContent-Length: 37\r\nDate: Sun, 13 Jun 2010 05:30:00 GMT\r\nServer: FSC/0.0.1\r\n\r\n") let content = System.Text.Encoding.ASCII.GetBytes("<html><body>Hello World</body></html>") let serveAsync (client : TcpClient) = async { let out = client.GetStream() do! out.AsyncWrite(headers) do! Async.Sleep 3000 do! out.AsyncWrite(content) do out.Close() } let http_server (ip, port) = let server = new TcpListener(IPAddress.Parse(ip),port) server.Start() while true do let client = server.AcceptTcpClient() printfn "new client" Async.Spawn (serveAsync client) http_server ("0.0.0.0", 1234)

    Read the article

  • Need help regarding Async and fsi

    - by Stringer Bell
    I'd like to write some code that runs a sequence of F# scripts (.fsx). The thing is that I could have literally hundreds of scripts and if I do that: let shellExecute program args = let startInfo = new ProcessStartInfo() do startInfo.FileName <- program do startInfo.Arguments <- args do startInfo.UseShellExecute <- true do startInfo.WindowStyle <- ProcessWindowStyle.Hidden //do printfn "%s" startInfo.Arguments let proc = Process.Start(startInfo) () scripts |> Seq.iter (shellExecute "fsi") it could stress too much my 2GB system. Anyway, I'd like to run scripts by batch of n, which seems also a good exercise for learning Async (I guess it's the way to go). I have written some code and unfortunately it doesn't work: open System.Diagnostics let p = shellExecute "fsi" @"C:\Users\Stringer\foo.fsx" async { let! exit = Async.AwaitEvent p.Exited do printfn "process has exited" } |> Async.StartImmediate foo.fsx is just a hello world script. I'd like also to figure out if it's doable to retrieve a return code for each executing script and if not, find another way. Thanks!

    Read the article

  • Asynchrony in C# 5 (Part I)

    - by javarg
    I’ve been playing around with the new Async CTP preview available for download from Microsoft. It’s amazing how language trends are influencing the evolution of Microsoft’s developing platform. Much effort is being done at language level today than previous versions of .NET. In these post series I’ll review some major features contained in this release: Asynchronous functions TPL Dataflow Task based asynchronous Pattern Part I: Asynchronous Functions This is a mean of expressing asynchronous operations. This kind of functions must return void or Task/Task<> (functions returning void let us implement Fire & Forget asynchronous operations). The two new keywords introduced are async and await. async: marks a function as asynchronous, indicating that some part of its execution may take place some time later (after the method call has returned). Thus, all async functions must include some kind of asynchronous operations. This keyword on its own does not make a function asynchronous thought, its nature depends on its implementation. await: allows us to define operations inside a function that will be awaited for continuation (more on this later). Async function sample: Async/Await Sample async void ShowDateTimeAsync() {     while (true)     {         var client = new ServiceReference1.Service1Client();         var dt = await client.GetDateTimeTaskAsync();         Console.WriteLine("Current DateTime is: {0}", dt);         await TaskEx.Delay(1000);     } } The previous sample is a typical usage scenario for these new features. Suppose we query some external Web Service to get data (in this case the current DateTime) and we do so at regular intervals in order to refresh user’s UI. Note the async and await functions working together. The ShowDateTimeAsync method indicate its asynchronous nature to the caller using the keyword async (that it may complete after returning control to its caller). The await keyword indicates the flow control of the method will continue executing asynchronously after client.GetDateTimeTaskAsync returns. The latter is the most important thing to understand about the behavior of this method and how this actually works. The flow control of the method will be reconstructed after any asynchronous operation completes (specified with the keyword await). This reconstruction of flow control is the real magic behind the scene and it is done by C#/VB compilers. Note how we didn’t use any of the regular existing async patterns and we’ve defined the method very much like a synchronous one. Now, compare the following code snippet  in contrast to the previuous async/await: Traditional UI Async void ComplicatedShowDateTime() {     var client = new ServiceReference1.Service1Client();     client.GetDateTimeCompleted += (s, e) =>     {         Console.WriteLine("Current DateTime is: {0}", e.Result);         client.GetDateTimeAsync();     };     client.GetDateTimeAsync(); } The previous implementation is somehow similar to the first shown, but more complicated. Note how the while loop is implemented as a chained callback to the same method (client.GetDateTimeAsync) inside the event handler (please, do not do this in your own application, this is just an example).  How it works? Using an state workflow (or jump table actually), the compiler expands our code and create the necessary steps to execute it, resuming pending operations after any asynchronous one. The intention of the new Async/Await pattern is to let us think and code as we normally do when designing and algorithm. It also allows us to preserve the logical flow control of the program (without using any tricky coding patterns to accomplish this). The compiler will then create the necessary workflow to execute operations as the happen in time.

    Read the article

  • Say goodbye to System.Reflection.Emit (any dynamic proxy generation) in WinRT

    - by mbrit
    tl;dr - Forget any form of dynamic code emitting in Metro-style. It's not going to happen.Over the past week or so I've been trying to get Moq (the popular open source TDD mocking framework) to work on WinRT. Irritatingly, the day before Release Preview was released it was actually working on Consumer Preview. However in Release Preview (RP) the System.Reflection.Emit namespace is gone. Forget any form of dynamic code generation and/or MSIL injection.This kills off any project based on the popular Castle Project Dynamic Proxy component, of which Moq is one example. You can at this point in time not perform any form of mocking using dynamic injection in your Metro-style unit testing endeavours.So let me take you through my journey on this, so that other's don't have to...The headline fact is that you cannot load any assembly that you create at runtime. WinRT supports one Assembly.Load method, and that takes the name of an assembly. That has to be placed within the deployment folder of your app. You cannot give it a filename, or stream. The methods are there, but private. Try to invoke them using Reflection and you'll be met with a caspol exception.You can, in theory, use Rotor to replace SRE. It's all there, but again, you can't load anything you create.You can't write to your deployment folder from within your Metro-style app. But, can you use another service on the machine to move a file that you create into the deployment folder and load it? Not really.The networking stack in Metro-style is intentionally "damaged" to prevent socket communication from Metro-style to any end-point on the local machine. (It just times out.) This militates against an approach where your Metro-style app can signal a properly installed service on the machine to create proxies on its behalf. If you wanted to do this, you'd have to route the calls through a C&C server somewhere. The reason why Microsoft has done this is obvious - taking out SRE know means they don't have to do it in an emergency later. The collateral damage in removing SRE is that you can't do mocking in test mode, but you also can't do any form of injection in production mode. There are plenty of reasons why enterprise apps might want to do this last point particularly. At CP, the assumption was that their inspection tools would prevent SRE being used as a malware vector - it now seems they are less confident about that. (For clarity, the risk here is in allowing a nefarious program to download instructions from a C&C server and make up executable code on the fly to run, getting around the marketplace restrictions.)So, two things:- System.Reflection.Emit is gone in Metro-style/WinRT. Get over it - dynamic, on-the-fly code generation is not going to to happen.- I've more or less got a version of Moq working in Metro-style. This is based on the idea of "baking" the dynamic proxies before you use them. You can find more information here: https://github.com/mbrit/moqrt

    Read the article

  • What's the best practice for async APIs that return futures on Scala?

    - by Maurício Linhares
    I have started a project to write an async PostgreSQL driver on Scala and to be async, I need to accept callbacks and use futures, but then accepting a callback and a future makes the code cumbersome because you always have to send a callback even if it is useless. Here's a test: "insert a row in the database" in { withHandler { (handler, future) => future.get(5, TimeUnit.SECONDS) handler.sendQuery( this.create ){ query => }.get( 5, TimeUnit.SECONDS ) handler.sendQuery( this.insert ){ query => }.get( 5, TimeUnit.SECONDS ).rowsAffected === 1 } } Sending the empty callback is horrible but I couldn't find a way to make it optional or anything like that, so right now I don't have a lot of ideas on how this external API should look like. It could be something like: handler.sendQuery( this.create ).addListener { query => println(query) } But then again, I'm not sure how people are organizing API's in this regard. Providing examples in other projects would also be great.

    Read the article

  • Async Call To Services

    - by Pita.O
    Hi Is there any time it would not be a good idea to call web services async? My data layer is a REST-based interface and I thinking of adopting an async-only approach to all the CRUD in the system. Is there anything I should know?

    Read the article

  • Making Ninject Interceptors work with async methods

    - by captncraig
    I am starting to work with ninject interceptors to wrap some of my async code with various behaviors and am having some trouble getting everything working. Here is an interceptor I am working with: public class MyInterceptor : IInterceptor { public async void Intercept(IInvocation invocation) { try { invocation.Proceed(); //check that method indeed returns Task await (Task) invocation.ReturnValue; RecordSuccess(); } catch (Exception) { RecordError(); invocation.ReturnValue = _defaultValue; throw; } } This appears to run properly in most normal cases. I am not sure if this will do what I expect. Although it appears to return control flow to the caller asynchronously, I am still a bit worried about the possibility that the proxy is unintentionally blocking a thread or something. That aside, I cannot get the exception handling working. For this test case: [Test] public void ExceptionThrown() { try { var interceptor = new MyInterceptor(DefaultValue); var invocation = new Mock<IInvocation>(); invocation.Setup(x => x.Proceed()).Throws<InvalidOperationException>(); interceptor.Intercept(invocation.Object); } catch (Exception e) { } } I can see in the interceptor that the catch block is hit, but the catch block in my test is never hit from the rethrow. I am more confused because there is no proxy or anything here, just pretty simple mocks and objects. I also tried something like Task.Run(() => interceptor.Intercept(invocation.Object)).Wait(); in my test, and still no change. The test passes happily, but the nUnit output does have the exception message. I imagine I am messing something up, and I don't quite understand what is going on as much as I think I do. Is there a better way to intercept an async method? What am I doing wrong with regards to exception handling?

    Read the article

  • C# async and actors

    - by Alex.Davies
    If you read my last post about async, you might be wondering what drove me to write such odd code in the first place. The short answer is that .NET Demon is written using NAct Actors. Actors are an old idea, which I believe deserve a renaissance under C# 5. The idea is to isolate each stateful object so that only one thread has access to its state at any point in time. That much should be familiar, it's equivalent to traditional lock-based synchronization. The different part is that actors pass "messages" to each other rather than calling a method and waiting for it to return. By doing that, each thread can only ever be holding one lock. This completely eliminates deadlocks, my least favourite concurrency problem. Most people who use actors take this quite literally, and there are plenty of frameworks which help you to create message classes and loops which can receive the messages, inspect what type of message they are, and process them accordingly. But I write C# for a reason. Do I really have to choose between using actors and everything I love about object orientation in C#? Type safety Interfaces Inheritance Generics As it turns out, no. You don't need to choose between messages and method calls. A method call makes a perfectly good message, as long as you don't wait for it to return. This is where asynchonous methods come in. I have used NAct for a while to wrap my objects in a proxy layer. As long as I followed the rule that methods must always return void, NAct queued up the call for later, and immediately released my thread. When I needed to get information out of other actors, I could use EventHandlers and callbacks (continuation passing style, for any CS geeks reading), and NAct would call me back in my isolated thread without blocking the actor that raised the event. Using callbacks looks horrible though. To remind you: m_BuildControl.FilterEnabledForBuilding(    projects,    enabledProjects = m_OutOfDateProjectFinder.FilterNeedsBuilding(        enabledProjects,             newDirtyProjects =             {                 ....... Which is why I'm really happy that NAct now supports async methods. Now, methods are allowed to return Task rather than just void. I can await those methods, and C# 5 will turn the rest of my method into a continuation for me. NAct will run the other method in the other actor's context, but will make sure that when my method resumes, we're back in my context. Neither actor was ever blocked waiting for the other one. Apart from when they were actually busy doing something, they were responsive to concurrent messages from other sources. To be fair, you could use async methods with lock statements to achieve exactly the same thing, but it's ugly. Here's a realistic example of an object that has a queue of data that gets passed to another object to be processed: class QueueProcessor {    private readonly ItemProcessor m_ItemProcessor = ...     private readonly object m_Sync = new object();    private Queue<object> m_DataQueue = ...    private List<object> m_Results = ...     public async Task ProcessOne() {         object data = null;         lock (m_Sync)         {             data = m_DataQueue.Dequeue();         }         var processedData = await m_ItemProcessor.ProcessData(data); lock (m_Sync)         {             m_Results.Add(processedData);         }     } } We needed to write two lock blocks, one to get the data to process, one to store the result. The worrying part is how easily we could have forgotten one of the locks. Compare that to the version using NAct: class QueueProcessorActor : IActor { private readonly ItemProcessor m_ItemProcessor = ... private Queue<object> m_DataQueue = ... private List<object> m_Results = ... public async Task ProcessOne()     {         // We are an actor, it's always thread-safe to access our private fields         var data = m_DataQueue.Dequeue();         var processedData = await m_ItemProcessor.ProcessData(data);         m_Results.Add(processedData);     } } You don't have to explicitly lock anywhere, NAct ensures that your code will only ever run on one thread, because it's an actor. Either way, async is definitely better than traditional synchronous code. Here's a diagram of what a typical synchronous implementation might do: The left side shows what is running on the thread that has the lock required to access the QueueProcessor's data. The red section is where that lock is held, but doesn't need to be. Contrast that with the async version we wrote above: Here, the lock is released in the middle. The QueueProcessor is free to do something else. Most importantly, even if the ItemProcessor sometimes calls the QueueProcessor, they can never deadlock waiting for each other. So I thoroughly recommend you use async for all code that has to wait a while for things. And if you find yourself writing lots of lock statements, think about using actors as well. Using actors and async together really takes the misery out of concurrent programming.

    Read the article

  • jsTree: async loading

    - by vandalo
    Hello everyone, I am trying to use this jQuery plugin (jsTree) in one of my project. All the others I've found haven't been recently updated. Anyway, I am using this plugin to load a folder structure, but I would like to do this operation async. The examples I've found on their site (called async) are ridiculous. I've tried to check on the Internet but it seems that most people load the whole tree. I would like to load a branch on every single node click. I am using JSON. Thank in advance

    Read the article

  • jQuery-ajax call: async property is not working?

    - by user269386
    Hi, given to certain circumstances, I'm forced to keep page settings (Javascript-values) in the session and it has to be done right before leaving the page (I can't use cookies, since "pageSettings" can become quite large and localStorage is not an option yet ;) ). So this is how I tried it. However it seems that when I call the page directly again, the call of "http://blabla.com/bla" happens asynchronous, even though the async-attribute is set (I don't receive the settings of the previous call, but of the one before): $jQ(document).ready(function () { $jQ(window).unload(Main.__setSessionValues); }); var Main = { pageSettings: {}, __setSessionValues: function __setSessionValues() { $jQ.ajax({ type: "POST", async: false, url: "http://blabla.com/bla", data: { pageSettings: Object.toJSON(Main.pageSettings) } }); } }; Does anyone know what the problem might be? thanks in advance

    Read the article

  • Strange WPF Behaviour With WCF Async calls

    - by gvigsgb
    I have a WPF application calling WCF via Async calls. The application has four tabs in which each are loaded from seperate async calls, each tab has a busy indicator. The problem: When running within Visual Studio I can click a refresh button on each tab and each tab's busy indicator starts and the data is retrieved from the WCF service. As each tab's data comes back it is refreshed. When I deploy the application via one click the application's UI hangs after only two tabs start refreshing. So in this case I press refresh on tab one, then on tab two and the application hangs until one of the two tabs data comes back. I thought at first that it was something to do with the WCF service throtteling and that was not the case as both the Visual Studio and the One Click deployments of the application point to the same service. Anyone have any ideas on where to look? I cannot reproduce the hang issue within Visual Studio?

    Read the article

  • C# 5 Async, Part 1: Simplifying Asynchrony – That for which we await

    - by Reed
    Today’s announcement at PDC of the future directions C# is taking excite me greatly.  The new Visual Studio Async CTP is amazing.  Asynchronous code – code which frustrates and demoralizes even the most advanced of developers, is taking a huge leap forward in terms of usability.  This is handled by building on the Task functionality in .NET 4, as well as the addition of two new keywords being added to the C# language: async and await. This core of the new asynchronous functionality is built upon three key features.  First is the Task functionality in .NET 4, and based on Task and Task<TResult>.  While Task was intended to be the primary means of asynchronous programming with .NET 4, the .NET Framework was still based mainly on the Asynchronous Pattern and the Event-based Asynchronous Pattern. The .NET Framework added functionality and guidance for wrapping existing APIs into a Task based API, but the framework itself didn’t really adopt Task or Task<TResult> in any meaningful way.  The CTP shows that, going forward, this is changing. One of the three key new features coming in C# is actually a .NET Framework feature.  Nearly every asynchronous API in the .NET Framework has been wrapped into a new, Task-based method calls.  In the CTP, this is done via as external assembly (AsyncCtpLibrary.dll) which uses Extension Methods to wrap the existing APIs.  However, going forward, this will be handled directly within the Framework.  This will have a unifying effect throughout the .NET Framework.  This is the first building block of the new features for asynchronous programming: Going forward, all asynchronous operations will work via a method that returns Task or Task<TResult> The second key feature is the new async contextual keyword being added to the language.  The async keyword is used to declare an asynchronous function, which is a method that either returns void, a Task, or a Task<T>. Inside the asynchronous function, there must be at least one await expression.  This is a new C# keyword (await) that is used to automatically take a series of statements and break it up to potentially use discontinuous evaluation.  This is done by using await on any expression that evaluates to a Task or Task<T>. For example, suppose we want to download a webpage as a string.  There is a new method added to WebClient: Task<string> WebClient.DownloadStringTaskAsync(Uri).  Since this returns a Task<string> we can use it within an asynchronous function.  Suppose, for example, that we wanted to do something similar to my asynchronous Task example – download a web page asynchronously and check to see if it supports XHTML 1.0, then report this into a TextBox.  This could be done like so: private async void button1_Click(object sender, RoutedEventArgs e) { string url = "http://reedcopsey.com"; string content = await new WebClient().DownloadStringTaskAsync(url); this.textBox1.Text = string.Format("Page {0} supports XHTML 1.0: {1}", url, content.Contains("XHTML 1.0")); } .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } Let’s walk through what’s happening here, step by step.  By adding the async contextual keyword to the method definition, we are able to use the await keyword on our WebClient.DownloadStringTaskAsync method call. When the user clicks this button, the new method (Task<string> WebClient.DownloadStringTaskAsync(string)) is called, which returns a Task<string>.  By adding the await keyword, the runtime will call this method that returns Task<string>, and execution will return to the caller at this point.  This means that our UI is not blocked while the webpage is downloaded.  Instead, the UI thread will “await” at this point, and let the WebClient do it’s thing asynchronously. When the WebClient finishes downloading the string, the user interface’s synchronization context will automatically be used to “pick up” where it left off, and the Task<string> returned from DownloadStringTaskAsync is automatically unwrapped and set into the content variable.  At this point, we can use that and set our text box content. There are a couple of key points here: Asynchronous functions are declared with the async keyword, and contain one or more await expressions In addition to the obvious benefits of shorter, simpler code – there are some subtle but tremendous benefits in this approach.  When the execution of this asynchronous function continues after the first await statement, the initial synchronization context is used to continue the execution of this function.  That means that we don’t have to explicitly marshal the call that sets textbox1.Text back to the UI thread – it’s handled automatically by the language and framework!  Exception handling around asynchronous method calls also just works. I’d recommend every C# developer take a look at the documentation on the new Asynchronous Programming for C# and Visual Basic page, download the Visual Studio Async CTP, and try it out.

    Read the article

  • AsyncBridge? Async on .NET 4.0 using VS11

    - by Alex.Davies
    I've just found something quite cool. It's a code snippet that lets you use the real VS 11 C#5 compiler to write code that uses the async and await keywords, but to target .NET 4.0. It was published by Daniel Grunwald (from SharpDevelop).That means I can stop using the Async CTP for VS2010, which is not at all supported anymore, and a pain to install if you have windows updates turned on. Obviously I couldn't ask all my users to install .NET 4.5 beta, but .NET Demon is a VS 2010 extension, so we already have .NET 4.0. At the time of writing, VS11 is in beta still, but hopefully it's stable enough for my team to use!I would have written the code myself, but I had the wrong impression that the C# 5 beta compiler only looked in mscorlib for the helper classes it needs to implement async methods. Turns out you can provide them yourself. You can get the code here: https://gist.github.com/1961087You just add it to your project, and the compiler will apparently pick it up and use it to implement async/await. I'm at my parents' place for Easter without access to a machine with VS 11 to try it out. Let me know whether you get it to work!This reminds me of LINQBridge, which let us use C# 3 LINQ, but only require .NET 2. We should stick up a webpage to explain, with a nice easy dll, put it in nuget, and call it AsyncBridge.If you were really enthusiastic, you could re-implement the skeleton of the Task Parallel Library against .NET 2 to use async/await without even requiring .NET 4. Our usage stats suggest that practically everyone that uses Red Gate tools already has .NET 4 installed though, so I don't think I'll go to the effort.

    Read the article

  • What are incentives (if any) to use WinRT instead of .Net?

    - by Ark-kun
    Let's compare WinRT with .Net .Net .Net is the 13+ years evolution of COM. Three main parts of .Net are execution environment, standard libraries and supported languages. CLR is the native-code execution environment based on COM .Net Framework has a big set of standard libraries (implemented using managed and native code) that can be used from all .Net languages. There are .Net classes that allow using OS APIs. WPF or Silverlight provide a XAML-based UI framework .Net can be used with C++, C#, Javascript, Python, Ruby, VB, LISP, Scheme and many other languages. C++/.Net is a variation of the C++ language that allows interaction with .Net objects. .Net supports inheritance, generics, operator and method overloading and many other features. .Net allows creating apps that run on Windows (XP, 7, 8 Pro (Desktop and Metro), RT, CE, etc), Mac OS, Linux (+ other *nix); iOS, Android, Windows Phone (7, 8); Internet Explorer, Chrome, Firefox; XBox 360, Playstation Suite; raw microprocessors. There is support for creating games (2D/3D) using any managed language or C++. Created by Developer Division WinRT WinRT is based on COM. Three main parts of WinRT are execution environment, standard libraries and supported languages. WinRT has a native-code execution environment based on COM WinRT has a set of standard libraries that more or less can be used from WinRT languages. There are WinRT classes that allow using OS APIs. Unnamed Silverlight clone provides a XAML-based UI framework WinRT can be used with C++, C#, Javascript, VB. C++/CX is a variation of the C++ language that allows interaction with WinRT objects. Custom WinRT components don't support inheritance (classes must be sealed), generics, operator overloading and many other features. WinRT allows creating apps that run on Windows 8 Pro and RT (Metro only); Windows Phone 8 (limited). There is support for creating games (2D/3D) using C++ only. Ordered by Windows Team I think that all the aspects except the last ones are very important for developers. On the other hand it seems that the most important aspect for Microsoft is the last one. So, given the above comparison of conceptually identical technologies, what are incentives (if any) to use WinRT instead of .Net?

    Read the article

  • jsTree async with preloaded data.

    - by Paul Knopf
    I am trying to make a tree view be async. When the page is rendered, there is default tree items displayed. jsTree tries to reload the root anyway. I want the page to render (with jsTree init'ed) with default items rendered from browser, not the ajax call. Then we the user tries to go deeper, thats when I want to do do the ajax calls. Any help is appreciated. Thanks!

    Read the article

  • python gio waiting for async operations to be done

    - by pygabriel
    I have to mount a WebDav location and wait for the operation to be finished before to proceed (it's a script). So I'm using the library in this way: location = gio.File("dav://server.bb") location.mount_enclosing_volume(*args,**kw) # The setup is not much relevant location.get_path() # Returns None because it's not yet mounted since the call is async How to wait until the device is mounted?

    Read the article

  • SDL & Windows 8 Metro WinRT

    - by Adrian
    I am just beginning to dip my tow into game programming and have been reading up on SDL, SFML, OpenGL, XNA, MonoGame and of course DirectX. (Needless to say there are a lot of choices out there) As much as I like SFMLs syntax I have chosen to read up and start with SDL as it is pretty ubiquitous and available on every platform (Windows, Linux, Mac) and also available on portable devices (Android, iOS) with the current exception of WinPhone 7 After that pre-amble here is my question. I notice that the docs say that for the windows platform the SDL API calls through to DirectX for higher perf. ( http://www.libsdl.org/intro.en/whatplatforms.html ) Microsoft have said that for Metro Game Apps you can only use DirectX (which means no XNA, no OpenGL, no SFML, etc, etc) My question is: If SDL just wraps DirectX calls will I (we) be able to use SDL to bring games to the new Metro WinRT environment and Windows 8 marketplace? This would be great if possible. Additionally as WinPhone 8 is supposedly built on Win8 then this could mean SDL would be available on the win phone in the future too. Thanks for your time in responding to this question and I look forward to hearing your response. EDIT: Based on DeadMG's answer I have installed Visual Studio 11 (beta) in Windows 8 Consumer Preview (CP) and went file-New to check project types. The project types: "Blank Application", "Direct2D Application" and "Direct3D Application" look of interest. I have selected "Direct2D App" but SDL generates its own window when you call: SDL_INIT Is it possible to link/setup the SDL window to point to the Direct2D surface in the this project?

    Read the article

  • Async actions inside Silverlight Method - returning the value

    - by tyndall
    What is the proper way to call an Async framework component - wait for an answer and then return the value. AKA contain the entire request/response in a single method. Example code: public class Experiment { public Experiment() { } public string GetSomeString() { WebClient wc = new WebClient(); wc.DownloadStringCompleted += new DownloadStringCompletedEventHandler(wc_DownloadStringCompleted); Uri u = new Uri("http://news.google.com/news?pz=1&cf=all&ned=us&hl=en&topic=t&output=rss"); wc.DownloadStringAsync(u); return "the news RSS from Google"; } private void wc_DownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e) { //don't really see how this callback method makes it able // to return the answer I'm looking for on the return // statement in the method above. } } MORE INFO: The reason I'm asking this that I have a project I'm working on where I'd like JavaScript code in the browser to use Silverlight like a Facade/Proxy to Web services and complex calculations & operations. I'd like to make the calls to the [ScriptableMembers] in Silvelight synchronously. I don't want Silverlight to callback into the browser's JavaScript

    Read the article

  • Does async and await incease performance of an ASP.Net application

    - by Kerezo
    I recently read a article about c#-5 and new $ nice asynchronous programming. I see it works greate in windows application. The question came to me before is if this feature can increase ASP.Net performance? consider this code: public T GetData() { var d = GetSomeData(); return d; } and public async T GetData2() { var d = await GetSomeData(); return d; } Has in an ASP.Net appication that two codes difference? thanks

    Read the article

  • 'Loading' web page for async call

    - by Sieg
    I have a simple web page in ASP.NET / C#. Currently to fully render the data I require calling a block of code that runs on background threads and can take multiple minutes to complete. I've got it to the point (using the async attribute on the page declaration) to execute and return fine with the html once it's done. What I'd like it to do is allow me to return immediately with a 'loading page' of some sort and then have that page be updated when the background work has been completed. Right now I get nothing on the page while the background work is being processed. Any ideas on the best way or clever way to do that would greatly be appreciated! Thanks, Sieg

    Read the article

< Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >