Raising Events vs Calling a Sub/Function

[webbiz]

I'm sure this is a basic question, but I have been wondering about this since working with the TestChart app.

For example, the usercontrol ucStockChart has a method called RefreshChart.

Within that method there is a call to

     RaiseEvent RenderRecordUsing(Rs, CC, mBarWidth, CC.Surface.Height)

Over on the fChartHost form that contains the uc, you see that the uc has the event called RenderRecordUsing which is a Sub.
I'm curious as to the WHY a subroutine would be setup as an EVENT for the uc rather than simply having a Subroutine (method) and just calling it.

There is a good reason, I'm sure. But perhaps someone can dumbify this for me as to when you create these EVENTS and using WITHEVENTS and just calling Subs/Functions directly.

TIA

[VanGoghGaming]

You're right, it is a basic question but one not so obvious if you're not already familiar with the concept. VB6 is an "OOED" type of programming language (Object Oriented Event Driven). So it really helps to actually use those terms in your way of thinking and developing an application rather than relying on the old "procedural" programming style where you just call "subs and functions"...

Try asking ChatGPT:

what are events in COM programming?

It does a pretty good job at explaining basic concepts. Here is an excerpt of what it said:

"Events enable a form of asynchronous communication between COM objects, allowing one object (the event source) to inform other objects (event sinks or listeners) about important actions or changes without requiring the sinks to continuously poll or check the source for updates."

[Episcopal]

It's already happened to me that I needed to use nested Classes as properties, but WithEvents failed and didn't reach the usercontrol. I created a Sub Friend in my usercontrol and passed the UC as an object between classes.

cProperties1.AddControl Me
[...]
cProperties(N-1).AddControl ObjUC

In the last instance, if I needed to generate an event, I would do:
objUC.SetEvent "Change"

In my UC:

Friend Sub SetEvent (byval sEvent as string)
       [...]
End Sub

I don't know if you're referring to this, but sometimes events are better if they're done that way. In vbAccelerator, as far as I remember I saw something like this.

[dilettante]

Events can also have multiple "subscribers." Then there are COM Callbacks, something that on first blush might smell like an Event but it is really something else.

But this stuff is already covered in the manuals that come with every legal copy of VB6.

[Zvoni]

Think about it this way:
You're driving in your car.
At a crossing you see someone trying to cross the road in front of you without seeing you.
You raise the event "Honk the Horn"
The person crossing the road is "subscribed" to this event, and reacts to it.
As are probably many other persons!

The difference: Your Alternative of calling a Sub "ShoutAtPerson" only targets that single person,
and for that Call to that Sub to be successful, that Person must be "Created"

[webbiz]

Think about it this way:
You're driving in your car.
At a crossing you see someone trying to cross the road in front of you without seeing you.
You raise the event "Honk the Horn"
The person crossing the road is "subscribed" to this event, and reacts to it.
As are probably many other persons!

The difference: Your Alternative of calling a Sub "ShoutAtPerson" only targets that single person,
and for that Call to that Sub to be successful, that Person must be "Created"

@zvoni , that was a pretty good illustration. Multiple 'listeners'. And I'll have to dig into the subject deeper to understand how multiple subs/functions can be 'listening' (can they all respond also? multiple subs triggered??)

What I didn't understand was the last part.

Your Alternative of calling a Sub "ShoutAtPerson" only targets that single person,
and for that Call to that Sub to be successful, that Person must be "Created"

The part about targeting a single destination, that I get. But for the call to the sub to be successful, that Person must be "created" is not clear.

Any call of a sub or function acting on 'something' requires that the 'something' actually exist. So what am I missing from this part of the example?

Thanks!

[webbiz]

You're right, it is a basic question but one not so obvious if you're not already familiar with the concept. VB6 is an "OOED" type of programming language (Object Oriented Event Driven). So it really helps to actually use those terms in your way of thinking and developing an application rather than relying on the old "procedural" programming style where you just call "subs and functions"...

Try asking ChatGPT:



It does a pretty good job at explaining basic concepts. Here is an excerpt of what it said:

"Events enable a form of asynchronous communication between COM objects, allowing one object (the event source) to inform other objects (event sinks or listeners) about important actions or changes without requiring the sinks to continuously poll or check the source for updates."

@VanGoghGaming

Me and ChatGPT...I told it to pound sand and it has been giving me bogus info ever since.

I understand the OOP concept. I originally programmed in 'C' early 80's when C++ became a 'thing'. So I jumped on the C++ bandwagon and that was my introduction to OOP.

And I understand 'basically' what EVENTS do, the messaging and triggering, somewhat. Didn't stay long in C++, having moved to Borland Delphi RAD then later VB4.

But going back to the small code example I posted, we have 1 call to 'RaiseEvent' Sub and 1 Sub to react to it. This in my simple, old mind is just like calling a Sub directly. So I questioned the 'why' the decision was to make it an Event rather than a straight Sub call.

Thank you!

[webbiz]

@Episcopal

Thanks for your example. It looks like an Alice In Wonderland fall in the hole scenario. Nesting makes my head hurt. Am I alone?

[webbiz]

I just had my morning Joe and I think some lights turned on as a result.

In the small example I provided, I 'think' the reasoning to using the RaiseEvent - event trigger in this scenario has something to do with a couple of the purposes of a class (and usercontrol), Encapsulation and Reusability.

With the Usercontrol, if it was a non-event Sub or Function, it would not know what container it will reside on in advance.

Because of this, if you were to just call RenderRecordUsing(), it would not know the host container (you could pass this in the params) nor would it know the Usercontrol object name within that host container.

Passing the Host-Uc name would not solve this either, because you'd have to edit this inside the ucStockChart code every time you added it to a new project, which defeats the purpose of Encapsulation and Reusability (well, you can reuse it, but you'd have to KNOW you had to make these changes.).

Did I get this right?

[Episcopal]

@Episcopal

Thanks for your example. It looks like an Alice In Wonderland fall in the hole scenario. Nesting makes my head hurt. Am I alone?

Hey, it happened and I don't know why it went wrong. But I'll test it again.

[techgnome]

I just had my morning Joe and I think some lights turned on as a result.

In the small example I provided, I 'think' the reasoning to using the RaiseEvent - event trigger in this scenario has something to do with a couple of the purposes of a class (and usercontrol), Encapsulation and Reusability.

With the Usercontrol, if it was a non-event Sub or Function, it would not know what container it will reside on in advance.

Because of this, if you were to just call RenderRecordUsing(), it would not know the host container (you could pass this in the params) nor would it know the Usercontrol object name within that host container.

Passing the Host-Uc name would not solve this either, because you'd have to edit this inside the ucStockChart code every time you added it to a new project, which defeats the purpose of Encapsulation and Reusability (well, you can reuse it, but you'd have to KNOW you had to make these changes.).

Did I get this right?

Yes... now you're getting it. Think of it like this: You have a house ... your friend is in another house... They want to send you a message. But they don't know where you live, all they have is an address. So they write a message and drop it into the post (This is the Raise Event) ... it travels through the system (this would be the internal Messaging System VB has for events) and eventually the letter arrives at your house (the Event Handler) ... You can then respond to the letter as needed (the code in your event handler).

It's a similar kind of thing. You click a button. It doesn't know where it is, or if it's on a form or some other container. It doesn't care. So it does a RaiseEvent(thisButton, Click) and that message goes out. The messaging system then looks to see if there are any EventHandler for that control, for that event, and if so, dispatches to that handler... there can be one. There can be more than one. It's easier to handle the same event for the same object by different handlers than it is in VB6, but I'm sure it's possible (haven't ever done it, nor needed to, so it's out of my realm).


-tg

[Elroy]

Also, something I didn't see mentioned ... the form doesn't have to "listen" to an event, whereas if you call a procedure, it's got to be there or there'll be an error.

Also, while in the IDE, it's nice that IntelliSense makes note of any RaiseEvents we have, and lists them for us.