No announcement yet.

NEW DEMO: GUI + Worker Thread of Execution + Abort

  • Filter
  • Time
  • Show
Clear All
new posts

  • Michael Mattias
    Hmm, if inserting the keyword 'THREAD' in front of 'FUNCTION' is the only change after ten+ years and three major compiler versions I think I can declare victory.

    Leave a comment:

  • Kenneth Levin
    To get this sample code to compile with PB10 change this line of code:

    FUNCTION WorkerThreadFunction (BYVAL hDlg AS LONG) AS LONG
    to this:


    Leave a comment:

  • NEW DEMO: GUI + Worker Thread of Execution + Abort

    I don't often post a separate thread for demos in the source code forum, but over the holiday weekend I created a demo which "should" be of interest.

    Located at, this demo shows how to use a
    separate thread of execution to do 'something requiring lots of time' from a window/dialog command button, and supports the two most common requests I've seen here in this situation:

    1. The main user screen continues to process messages even while the 'file processing' is going on - no "white square where the screen used to be" when you move the dialog; no "application not responding" messages.

    2. An abort function.

    What this demo does is allows you to select a file to "process", reads that file a record at a time with LINE INPUT#, and counts the records one a time; but where I just count is where you could do "anything" with that record.

    In the demo, the abort may occur after any one "LINE INPUT" of the input file has been processed, which should be plenty good enough; and you can always tell the screen is continuing to process messages because the date and time update once per second (WM_TIMER notification message).

    I tried to include enough comments to explain what I was doing, but if there is anything unclear at all about "why" I did something the way I did, let me know and I'll fix up the post to add comments (if within the 15 day edit limit) or add a 'reply' with "questions and answers" if over the 15 day limit.

    (Please post as replies to this thread so everything is in one place).

    Yes, you 'could' do this by polling a GLOBAL variable; setting that variable in the window procedure and reading it within the thread function. However....
    • Polling is terribly inefficient.
    • The WaitForMultipleObjects call will "automatically" cause Windows to check for messages in other threads so your screen(s) will update; polling does NOT force Windows to make this check.
    • Code relying on GLOBAL variables is not quite so instantly reuseable as that which does not.