Results 1 to 7 of 7

Thread: If VB6 does not handle multithreading, how are events handled?

  1. #1

    Thread Starter
    New Member
    Join Date
    Mar 2018
    Posts
    2

    Question If VB6 does not handle multithreading, how are events handled?

    Hello all, I'm having some trouble understanding how VB6 handles "asynchronous" events when it does not support multithreading.

    In my case, I am porting a VB6 application to C#, and have found that in the VB6 application, there are several Global and Public variables that are shared between several event handlers. These event handlers include button Click events, Winsock DataArrival events, and a Timer event.

    How is access to these variables synchronized across all of these events? Or, is this application written incorrectly?

  2. #2
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    1,056

    Re: If VB6 does not handle multithreading, how are events handled?

    [...]
    Last edited by dz32; Apr 26th, 2019 at 11:23 AM.

  3. #3
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,853

    Re: If VB6 does not handle multithreading, how are events handled?

    Hi FSW_Person,

    Welcome to VBForums. Yes dz32 hit the nail on the head. Nothing happens until one event completes execution. Then, whatever next event is on the queue gets fired, and so on.

    The only exception to this is when DoEvents is used, which is highly discouraged. DoEvents pauses the code at the DoEvents line, goes to see if other events are on the queue, executes them, and then returns to the event with the DoEvents line, completing that code. More often than not, using DoEvents just makes a mess of things.

    Now, regarding global/public variables, I don't really see the issue. If they're set by the thread, wherever it happens to be, they're set. And then, subsequent events will see those changes.

    Not to be patronizing, but it all seems fairly straightforward to me.

    Best Of Luck,
    Elroy

    EDIT1: Just to be clear, the DoEvents statement does not start a new thread. It just pauses the current code and goes and executes other events, and then returns to complete the code where it was executed. DoEvents is really only useful (in my opinion) to monitor a "Cancel" button on a long-running procedure. You may want to terminate it before it completes, but the "Cancel" button won't click until the long-running procedure has completed without that long-running procedure occasionally executing a DoEvents statement. And even then, one should be careful that nothing but the "Cancel" button can cause an event.
    Last edited by Elroy; Mar 23rd, 2018 at 06:51 PM.
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  4. #4
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: If VB6 does not handle multithreading, how are events handled?

    There is nothing new or special there, that's how programs work in Windows and similar OS GUI subsystems. This is not unique to VB by any means, and even the Great Pretender VB.Net and C# work the same way... just as a program in C, C++, Delphi, etc. does.

    In a desktop application any additional threads are "deaf and dumb" (as in not in communication with the user) worker threads. A process only has one user interface thread under normal circumstances. Worker threads are much more like a command-line application thread or a batch thread.

    In most higher-level languages you do not write the event loop code, it is provided for you by the runtime library that you use. That saves you from writing a lot of boilerplate code in every program.

    All of the code you write consists of subroutines invoked by the message loop. As these are dispatched they should do their job as quickly as possible and then return control to the caller. The caller (message loop) can then dispatch the next and then the next until the message queue is empty, where it waits for queue insertion before dispatching events again.

    The best way to get an understanding of this is to write a small Windows program in plain old C.

  5. #5
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,853

    Re: If VB6 does not handle multithreading, how are events handled?

    FSW_Person,

    You also said something about the timer. However, it also follows all the same rules that we outlined. In other words, a long running procedure (without DoEvents) will effectively disable the timer so long as that long running procedure is still running. Other than DoEvents, there's no intra-program software interrupt in VB6.

    Now, you may wonder how Windows maintains it's multi-tasking abilities with VB6. But that's at an entirely different level. That's why I said intra-program software interrupt. Windows can still certainly suspend execution of a VB6 program, do other things, and then return to execution where it was suspended. Again, that's at a level beyond any single VB6 program.

    All The Best,
    Elroy
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  6. #6
    PowerPoster
    Join Date
    Feb 2015
    Posts
    2,672

    Re: If VB6 does not handle multithreading, how are events handled?

    Hello all, I'm having some trouble understanding how VB6 handles "asynchronous" events when it does not support multithreading.
    Supports.
    COM uses a messages queue in STA apartments. When you call CoInitialize it creates a hidden window to communicate between apartments. If you receive an event from a COM object in the other apartment COM packs parameters and translates them to caller apartment (marshaling) then wait until the event handling has been finished. All events/calls in STA are synchronous ones.

    In my case, I am porting a VB6 application to C#, and have found that in the VB6 application, there are several Global and Public variables that are shared between several event handlers. These event handlers include button Click events, Winsock DataArrival events, and a Timer event.
    All the events you wrote are synchronous ones because all VB6 objects live in STA. I mean synchronous in term of single threading. The process of communicating between objects in different apartments i shortly described above.

    How is access to these variables synchronized across all of these events? Or, is this application written incorrectly?
    All data are synchronized in STA.

  7. #7
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: If VB6 does not handle multithreading, how are events handled?

    Thread Local Storage is another factor here.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width