Events in VB6

[naveen2629]

Hi,
I know how to create and raise an event.
I want to know
Why are we using event in VB6?
Is there any specific reason or advantage for using events in VB6?

[techgnome]

how else should it be done? If you think about it, the world is full of event-driven design. Take a car for instance, when you start it up, the ignition sends an "even message" to the engine to start. When you press the gas, it sends a message to the engine to increase speed.

It's how Windows works, you click a button and a message goes out saying that it was clicked. Any handler that's subscribed to that message then gets notified.

-tg

[si_the_geek]

Thread moved from the 'CodeBank VB6' forum (which is for you to post working code examples, not questions) to the 'VB6 and earlier' forum

thanks for letting us know tg

[Doogle]

Apart from the obvious events, associated with controls and the like, which are normally triggered by the end user doing something, other events raised by code can in some instances be useful. This is especially the case where you are dealing with Asynchronous activities. For instance, Asynchronous I/O: - you may fire off an async I/O to read or write some data, and then carry on processing. When the I/O has completed, your Asynchronous I/O Completion Routine could raise an Event which your 'main' code would respond to.

eg

Do some processing
Issue an Async I/O to read some data
Carry on processing
.
 At some point in time the I/O completes and raises an Event -> Event Procedure Triggers-> process the I/O result
.
Carry on processing

An alternative would be a Synchronous operation

Do some processing
Issue a Synchronous I/O read
Wait until the I/O has completed
Process the I/O result
Carry on processing

The major difference between the two is that in the first example, you can carry on doing work whilst waiting for the I/O to complete and in the second example you have to wait (i.e. 'waste' elapsed time) for the I/O to complete before you can do anything else.

Whether it's useful or not depends upon the Application and whether you can do some 'useful' work instead of waiting for completion. Controls such as Winsock and MSComm which manage Asynchronous communications are particularly suited to event processing rather than the 'wait for something to happen' approach. This latter approach can cause the UI to 'freeze' and that is often 'cured' by using a loop with DoEvents which can cause significant problems.

Since VB6 doesn't support multi-threading I would suggest that there's limited value in raising events programatically unless you're writing User Controls and / or ActiveX - although I'm sure others may disagree.

As with most things wrt Programming it's 'Horses for Courses'

[dilettante]

VB's Event mechanism is an abstraction of window message processing. This isn't just a "Windows thing" but something you'll see in most OSs' with a GUI shell like Explorer.

If you were writing a program at a low level as in assembly language or plain C, your program has a "console-Main alternative" such the WinMain in Windows. One of the primary things this procedure is responsible for is accepting and processing window messages in a loop until told to go away. In this loop messages are removed from the queue, examined, and dispatched for processing.

In VB programs this WinMain and message loop are embedded in the runtime. The runtime handles many system messages itself, and preprocesses others and then dispatches them as COM/VB Events.

[naveen2629]

Thanks for your replies.
What is the difference between events and delegates?
I know delegates are not in vb6 then how to perform delegate operation in vb6?

[BobRodes]

Let's take a step back in time, to the pre-windows, pre-macintosh world. In this world, you told the computer what to do, using keystrokes. Or, at least, it looked that way to you, but how did the computer know that a keystroke happened? Well, whenever the user hit a key, the computer interrupted what it was doing and handled that keystroke. This is analogous to "events" in the present. Events are stuff that happens to Windows that tell Windows to stop whatever it is doing and handle whatever just happened. Now, you can tell windows how to handle it, too, by writing an "event handler." This is basically what events are.

Delegates are something entirely different, that happen to be used with events in .Net. A delegate is just a pointer to a procedure, but one that checks the procedure call to make sure that it's in the right format. you can't really do this in VB6. Let's take an example of a procedure declaration in VB6, and two calls to that procedure:

Public Declare Sub Sleep Lib "kernel32" Alias "Sleep" (ByVal dwMilliseconds
As Long)

Sleep 1000
Sleep "A"

The first one will stop for one second. The second one will hang everything, so that you probably have to "three-finger salute" (ctrl-alt-delete) and shut down your program. This is because the Sleep function takes a long and we sent it a string.

Delegates allow the .Net environment to throw an exception when their defined procedures are called incorrectly rather than hanging the entire system. When you define an event, you use a delegate to define the signature of the handler so that you can handle errors if someone defines the handler wrong. The closest equivalent in VB is a "wrapper function" which is not a formal thing. An example would be this:

Private Declare Function GetWindowsDirectory Lib "kernel32" Alias "GetWindowsDirectoryA" (ByVal lpBuffer As String, ByVal nSize&)

Public Function GetWinDir() As String
Dim strSave As String
    'Create a buffer string
    strSave = String(200, Chr$(0))
    'Get the windows directory
    GetWinDir = Left$(strSave, GetWindowsDirectory(strSave, Len(strSave)))
End Sub

This wrapper function calls the GetWindowsDirectory function and makes sure that it is called correctly. This insulates the user of the wrapper function from having to know the more complex requirements of calling the API function.