Threading in VB.NET is complex--any alternatives?

[Background and rant first; question below.]

In VB5, I wrote a simulation model with 2-D animation on the form. I could start, pause, continue, and stop the simulation. While the simulation subroutine was running, the form controls still processed user's clicks, and the simulation could query the controls' state and pause or stop as requested. It was all in one thread; I didn't even know what a "thread" was.

Now, I'm writing in VB.NET another simulation with 2-D animation. I want a "control center" form with start, pause, continue, and stop buttons, a small progress bar form, and an animation form. These have to communicate using shared data and event firing.

I am spending a ridiculous amount of time learning about threading, and programming an incredibly complex mass of code to handle threading and inter-process communication. (E.g., I am using David Hill's Task Class approach to interface between the user interface and worker threads, and not using the thread pool.)

It would have been WAY easier for us if .NET still responded to form controls as in VB5 (and probably VB6). Why on Earth did MS make it so difficult If I had known what was involved I would have used VB6 or Borland Delphi or something else.

Question:

Are there current, popular languages that allow simple, interactive control of a worker task (E.g., is any Java implementation like VB5/6 in this repsect Anything else )

Thank you kindly.

"Programming languages should be simple."

-Den



Answer this question

Threading in VB.NET is complex--any alternatives?

  • Dharmbir

    I was wrong. VB.NET can still respond to controls like VB5/6 ... using Application.DoEvents() -- which thankfully has not been marked obsolete. Life is good again.

    Criticism: All the web advice, examples, and information I saw on keeping the user interface responsive leads one to use threading, while DoEvents is fine for many purposes.

    Here, Microsoft admits that DoEvents is workable: http://msdn.microsoft.com/chats/transcripts/vstudio/vstudio_112503.aspx

    These two of many mislead one into thinking that multithreading is the only option:

    http://msdn.microsoft.com/library/default.asp url=/library/en-us/dnforms/html/winforms06112002.asp

    http://msdn.microsoft.com/library/default.asp url=/library/en-us/dnpag/html/scag-ch06.asp


  • GS80

    In Visual Basic .NET 2005 you can use your forms like you did in VB6. But there is a limitation though, your form cannot have a custom Sub New. But other than that, you can do so. Also, Threading is very easy. You're making it out to be some unexplainable math problem or something.

    This is probly the type of Thread you would want to use, you can read more here:

    http://msdn2.microsoft.com/en-us/library/system.threading.thread.aspx


    Also, you can make your Thread sleep and wake it back up, whenever you want.

  • icelava

    VB05 offers the Backgroundworker component to ease the use of multi-threading....

    Simply drop the component on your form and whala start using that background thread...

    http://msdn2.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx

    HTH



  • stswordman

    Yes, DoEvents works - but if you have a log running task, you really should use threading/Background Worker.

    Once you have figured out threading and synchronization, you will never look back (even if i does bring a whonle new host of problems to solve).

    I've upgraded several VB6 applications to use threading: they perform much better and more reliably than the old VB6 applications ever did. They also have less code.

    There's a lot of things in the latest versions of VB designed specifically to get the old VB6 diehards into the .NET world. I think DoEvents is one of them (To be honest, DoEvents, even though it works, is a pretty crappy way of 'getting things working' and should onle be a last resort - there are better methods available in .NET that make this old holdover obsolete).



  • Frank2808

    It's not really complicated, things have been simplified or made much better, and to protect your application from crashing or invoking controls incorrectly and so on - its just better practice, more stability, secure and just safer.

    Again it depends what you want to do. Threading should be used when you are going to do something which may cause the UI to be non responsive or for lengthy processes.

    To create a thread, I am sure you know already:



    Thread theThread = new Thread(new ThreadStart(method));
    theThread.IsBackground = true;
    theThread.Start();
    ..
    ..
    void method()
    {
    try
    {
    //do stuff
    }
    catch (ThreadAbortException)
    {
    //Clean up resources or whatever since the thread is being aborted/killed
    }
    catch (Exceptions)
    { //handle exceptions }
    }



  • Threading in VB.NET is complex--any alternatives?