{"id":31734,"date":"2023-01-24T05:39:51","date_gmt":"2023-01-24T00:09:51","guid":{"rendered":"https:\/\/jassweb.com\/solved\/solved-why-does-this-causes-the-application-to-hang-closed\/"},"modified":"2023-01-24T05:39:51","modified_gmt":"2023-01-24T00:09:51","slug":"solved-why-does-this-causes-the-application-to-hang-closed","status":"publish","type":"post","link":"https:\/\/jassweb.com\/solved\/solved-why-does-this-causes-the-application-to-hang-closed\/","title":{"rendered":"[Solved] Why does this causes the application to hang [closed]"},"content":{"rendered":"

[ad_1]
\n<\/p>\n

\n
\n
<\/div>\n
\n
\n

The biggest problem here is that your constructor does not return until all of the tasks have completed. Until the constructor returns, the window will not be shown, because the window messages related to drawing the window aren’t going to be processed.<\/p>\n

Note that you don’t really have “deadlock” here per se. Instead, if you waited long enough (i.e. until all the tasks have completed), the window would actually be shown.<\/p>\n

When you add the call to MessageBox.Show()<\/code>, you give the UI thread a chance to process the window message queue. That is, the normal modal dialog includes a thread message pump which winds up handling those messages in the queue, including those related to showing your window. Note that even if you add the MessageBox.Show()<\/code>, that won’t result in the window being updated as your processing progresses. It just allows the window to be shown before you block the UI thread again.<\/p>\n

One way to address this is to switch to the async<\/code>\/await<\/code> pattern. For example:<\/p>\n

public MainWindow()\n{\n    InitializeComponent();\n    var _ = ProcessURLs();\n}\n\npublic async Task ProcessURLs()\n{\n    List<Task<string>> tasks = URLsToProcess.Select(uri => DownloadStringAsTask(new Uri(uri))).ToList();\n\n    while (tasks.Count > 0)\n    {\n        Task<string> task = await Task.WhenAny(tasks);\n        string messageText;\n\n        if (task.Status == TaskStatus.RanToCompletion)\n        {\n            messageText = string.Format(\"{0} has completed\", task.AsyncState);\n            \/\/ TODO: do something with task.Result, i.e. the actual downloaded text\n        }\n        else\n        {\n            messageText = string.Format(\"{0} has completed with failure: {1}\", task.AsyncState, task.Status);\n        }\n\n        this.tbStatusBar.Text = messageText;\n        tasks.Remove(task);\n    }\n\n    tbStatusBar.Text = \"All tasks completed\";\n}\n<\/code><\/pre>\n
I’ve rewritten the ProcessURLs()<\/code> method as an async<\/code> method. This means that when the constructor calls it, it will run synchronously up to the first await<\/code> statement, at which point it will yield and allow the current thread to continue normally.<\/p>\n
When the call to Task.WhenAny()<\/code> completes (i.e. any of the tasks complete), the runtime will resume execution of the ProcessURLs()<\/code> method by invoking the continuation on the UI thread. This allows the method to access the UI objects (e.g. this.tbStatusBar.Text<\/code>) normally, while occupying the UI thread only long enough to process the completion.<\/p>\n
When the loop returns to the top and the Task.WhenAny()<\/code> method is called again, the whole sequence is repeated (i.e. just the way a loop is supposed to work \ud83d\ude42 ).<\/p>\n
Some other notes:<\/p>\n