none
Avoid program to be unresponsive RRS feed

  • Question

  • Lets say I have a button that executes the following code (its a kind of service used for sending sms)

    Dim obj As New Class1
    Dim strPostResponse2 As String = obj.SendSMS("username", "password", "919897100000", "Dear Partner, your outstanding balance towards Endurance Corp is Rs 1,50,000.00 as on 22-02-2018. Please process the payment, have a great day !")
    Now, when I click the button, its send the sms to the user. Now, here comes the problem, depending on the speed of the Internet sometimes it sends quickly and sometimes it takes longer to send thus making my program unresponsive for few seconds. I am new to vb.net environment, I need this to be done in background so that my program should not become unresponsive, can someone help me out ?

    Thursday, February 22, 2018 3:15 PM

Answers

  • See the following example if using VS2015 or higher in regards to the last click event using Async.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites

    • Marked as answer by Sid Williams Wednesday, March 7, 2018 1:04 PM
    Thursday, February 22, 2018 3:42 PM
    Moderator

All replies

  • See the following example if using VS2015 or higher in regards to the last click event using Async.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites

    • Marked as answer by Sid Williams Wednesday, March 7, 2018 1:04 PM
    Thursday, February 22, 2018 3:42 PM
    Moderator
  • I am using Visual Studio 2013, will this work ?
    Thursday, February 22, 2018 4:43 PM
  • You can use a BackgroundWorker Class. Drag a BackgroundWorker from the tool box and drop onto the form. Set the DoWork event and in it do the SMS. Set a RunWorkerCompleted event and use it to report the message was sent or not sent. The DoWork event will be executed as a separate (background) thread.


    Sam Hobbs
    SimpleSamples.Info

    Thursday, February 22, 2018 6:09 PM
  • I am using Visual Studio 2013, will this work ?

    No it will not as I indicated VS2015 or higher. Best next option is a BackGroundWorker as Same suggested.

    Please refer to the following tutorial

    http://www.vbforums.com/showthread.php?680130-Correct-way-to-use-the-BackgroundWorker


    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites

    Thursday, February 22, 2018 6:31 PM
    Moderator
  • I am using Visual Studio 2013, will this work ?
    Yes it was already in version 2012 there

    Success
    Cor

    Thursday, February 22, 2018 6:42 PM
  • I am using Visual Studio 2013, will this work ?
    Afaik async is related to a later version of .net framework maybe starting with 4.5.1 and not the version of visual studio. However threading works using a background worker or manually used threading with delegates that can update the main ui without cross threading which shoud be avoided. On the other hand I've seen u here before so new to vb???

    La vida loca

    Saturday, February 24, 2018 4:14 AM
  • I am using Visual Studio 2013, will this work ?

    You would just have to use the older event-based async pattern (EAP) instead of the newer task-based async pattern (TAP).  If your Class1.SendSMS() method is dependent on Internet speed then I would assume that somewhere in the method's code you write to a network stream, so just use the old BeginWrite() async method to refactor your SendSMS() code into an async method.

    There is really no need to waste a secondary thread when the program is I/O-bound; that's what asynchronous code is for.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Saturday, February 24, 2018 5:02 PM
    Moderator
  • I am using Visual Studio 2013, will this work ?

    You would just have to use the older event-based async pattern (EAP) instead of the newer task-based async pattern (TAP).  If your Class1.SendSMS() method is dependent on Internet speed then I would assume that somewhere in the method's code you write to a network stream, so just use the old BeginWrite() async method to refactor your SendSMS() code into an async method.

    There is really no need to waste a secondary thread when the program is I/O-bound; that's what asynchronous code is for.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Reed, 

    Can you explain this. 

    I've often one to one chatted with Lucian Wischik the previous Program Manager from VB and C#. He introduced in VB 2012 the keywords "Async" and "Await" (he is a programmer so I think he made a big deal himself). It was the first time since 1998 that real keywords were added in VB. 

    Therefore I'm surprised what you guys and girls are writing. 

     


    Success
    Cor


    • Edited by Cor Ligthert Saturday, February 24, 2018 6:07 PM
    Saturday, February 24, 2018 6:06 PM
  • I am using Visual Studio 2013, will this work ?

    You would just have to use the older event-based async pattern (EAP) instead of the newer task-based async pattern (TAP).  If your Class1.SendSMS() method is dependent on Internet speed then I would assume that somewhere in the method's code you write to a network stream, so just use the old BeginWrite() async method to refactor your SendSMS() code into an async method.

    There is really no need to waste a secondary thread when the program is I/O-bound; that's what asynchronous code is for.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Reed, 

    Can you explain this. 

    I've often one to one chatted with Lucian Wischik the previous Program Manager from VB and C#. He introduced in VB 2012 the keywords "Async" and "Await" (he is a programmer so I think he made a big deal himself). It was the first time since 1998 that real keywords were added in VB. 

    Therefore I'm surprised what you guys and girls are writing. 

     


    Success
    Cor


    Hi Cor,

    It might be better for you to create your own question on the topic to avoid hijacking this thread, but in a short answer to your question you can click that first link (event-based async pattern) to read the documentation and compare it to the TAP article available in the left-hand navigation bar located on that page.

    The original Asynchronous code model in .Net was EAP and relied on using BeginOperation() As IAsyncResult and EndOperation(result As IAsyncResult) methods to be called in pairs according to events raised and handled by these methods and the code which calls them.

    Lucian created the Async/Await behavior which allowed the creation of the TAP model.  He's no longer with Microsoft but I did work with him directly on some of the implementation details of the example code I supplied above, particularly in conferring with other members of the platform team to determine that there was an implementation problem within NetworkStream's async methods.  This was all several years ago and before everything went open source.

    Anyway, the TAP model is the newer, easier way to implement both async and multithreaded code because it handles all the heavy-lifting of synchronization and callbacks for you.  The TAP model also has facilities to wrap the EAP model so that you can write code that takes advantage of the task model while consuming the older EAP model methods and events when that is all that is available.

    So async code has been around forever, it just used to require a lot more scaffolding code to use it correctly.  Even though there was no "async" keyword, the IAsyncResult methods worked together to serve the same purpose.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Saturday, February 24, 2018 6:47 PM
    Moderator
  • Reed,

    Don't become aggressive. I only asked you to explain this. So you did. What is the problem? 

    Be aware, I'm not under the pressure to become a 2018 MVB, I don't care about it my only fun is to help others. 

    :-)


    Success
    Cor



    • Edited by Cor Ligthert Saturday, February 24, 2018 7:19 PM
    Saturday, February 24, 2018 7:16 PM
  • I am also interested in why async/await is emphasized so much. And no, I am not hijacking this thread; I think the choice of the solution was influenced by the experts emphasizing async/await. It is too late to have any influence on the pat but I sure don't understand the problem with BackgroundWorker. Except perhaps everything new is better than something old.


    Sam Hobbs
    SimpleSamples.Info

    Wednesday, March 7, 2018 5:14 PM
  • I am also interested in why async/await is emphasized so much. And no, I am not hijacking this thread; I think the choice of the solution was influenced by the experts emphasizing async/await. It is too late to have any influence on the pat but I sure don't understand the problem with BackgroundWorker. Except perhaps everything new is better than something old.


    Sam Hobbs
    SimpleSamples.Info

    BackgroundWorker is still a legitimate solution for executing long running work on a secondary thread.  Using the Task model is subjectively easier and results in cleaner, more reliable code.

    But first and foremost you have to know why you need a secondary thread.  Obviously it is to keep the main thread responsive, but why is the work causing the main thread to block?  Is it because you are doing heavy processing and the CPU is busy?  Or is it because you are waiting on some I/O operation like reading/writing a network or file stream?

    If the process is CPU-bound, then multithreading could be the answer.  But if the process is IO-Bound then asynchronous code on the main thread is likely the answer.

    The Async/Await model is useful in both scenarios.  Even though, on the surface, it is about asynchronous code it can also be used to wait for a secondary thread process to complete, or allow one to run indefinitely.

    Async/Await and the Task-based threading model are the go-to answers today because they are easier to write, result in cleaner more maintainable code, and are the least likely to result in improper multithreading implementations.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Wednesday, March 7, 2018 5:35 PM
    Moderator
  • Using the Task model is subjectively easier and results in cleaner, more reliable code.

    I think BackgroundWorker is easy to understand and use but BackgroundWorker is not adequately documented and I am working on getting the documentation improved.

    If the process is CPU-bound, then multithreading could be the answer.  But if the process is IO-Bound then asynchronous code on the main thread is likely the answer.

    This implies that asynchronous code avoids multithreading but it does not, certainly not in the sample code being referenced here.

    Async/Await and the Task-based threading model are the go-to answers today because they are easier to write, result in cleaner more maintainable code, and are the least likely to result in improper multithreading implementations.

    I don't see any of that. It seems to me that BackgroundWorker is more maintainable because it provides a more consistent solution; we know what the DoWork and other events do.

    I hope this serves the purpose of helping others in the future consider using BackgroundWorker. This provides myself and others the relevant considerations. I won't try to continue this issue here.



    Sam Hobbs
    SimpleSamples.Info

    Wednesday, March 7, 2018 6:32 PM
  • This implies that asynchronous code avoids multithreading but it does not, certainly not in the sample code being referenced here.

    It only involves multithreading if you start a new thread (e.g. Task.Run).  The async await model itself is purely async.  As I said, you can use async code to wait for secondary thread operations, but you can also use it to wait for truly asynchronous operations such as network data transfers.  Async/Await is a replacement and wrapper for the original IAsyncResult/Begin/End (EAP) async model.


    I don't see any of that. It seems to me that BackgroundWorker is more maintainable because it provides a more consistent solution; we know what the DoWork and other events do.


    Using the Task pattern you can often write, in a single short method, the same functionality which would require multiple event handler methods and shared data constructs between them with a BackgroundWorker.  This becomes especially true when you need to use all of the functionality the BackgroundWorker provides.

    Here are some other examples from other sources:

    https://blog.stephencleary.com/2013/05/taskrun-vs-backgroundworker-intro.html

    https://blog.stephencleary.com/2010/08/various-implementations-of-asynchronous.html

    https://stackoverflow.com/questions/12414601/async-await-vs-backgroundworker

    https://docs.microsoft.com/en-us/dotnet/visual-basic/programming-guide/concepts/async/index

    Note the above article states:

    "The async-based approach to asynchronous programming is preferable to existing approaches in almost every case. In particular, this approach is better than BackgroundWorker for IO-bound operations because the code is simpler and you don't have to guard against race conditions. In combination with Task.Run, async programming is better than BackgroundWorker for CPU-bound operations because async programming separates the coordination details of running your code from the work that Task.Run transfers to the threadpool."


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Wednesday, March 7, 2018 7:44 PM
    Moderator