Is event handling the right tool here?

[Fred4Christ]

Sadly I never got a good feel for OOP. And while I have done "great" things I occasionally hit a wall. I guess I am primarily a web scripter.

I have a VB.net application that performs a list of conversions to an MS Word docs, eventually making them it into a bunch of HTML pages.

I have two forms.
First: Is the main form. Title: Chapters. It comes up on launch.
Second: Title: Problems; opens from a menu item of Chapters.
"Chapters" acts on one type of documents. "Problems" on another, yep, problem docs. I got both forms working fine, including updating their own status area showing what steps have completed while the conversion is running.

I am trying to make a Subroutine in the Main Chapters form that can loop through all the chapters and problems in the chapter. Updating the status of the problems is where I am stuck.

I put all the necessary code that was in the problems form into a new file,
a "Module ProbExport" (See, I didn't use a class, cause I haven't wrapped my head around them yet).

My main form does work. It can act on the chapters and the problems in them, but I don't yet have the ability to show status of what the problems module code is doing. I tried to set up a way to "RaiseEvent", in the "Module ProbExport". And tried to set up an event handler in my main form that could update my status when the event was raised. I failed miserably.

My main question is, am I even thinking of events correctly here?
As in, should something like this work? Do events work in this direction?
Am I required to use a "Class ProbExport" instead of a "Module ProbExport"?

I am getting ready to go and study some more, and I hope I am starting
off in the right direction. I wish I could have an expert "looking over my shoulder" even paid so I could make progress on this faster.

Am I embarking in the right direction?
Have I been succinctly clear enough?

Thanks for your patience with this OOP newbie.

 

[jmcilhinney]

OOP is really very simple because it's based on the way real world objects work. In the real world, Car is a type of thing and each car that is driving around is an instance of that type. If you were to try to program this you'd declare a Car class and then in code you instantiate the Car class to create objects. You'd then want to add properties and methods: stuff the type has and does. Properties might include Engine, because an engine is something a car has, while methods might include Drive, because driving is something a car does.

Now, events are really quite simple too, when you think of them in real world terms. Let's say it's getting close to dinner time. Your mother might walk from room to room to get you, your siblings and your father individually. In that case your mother has explicitly called a method of you, each of your siblings and your father: your ComeToDinner method. Now, what if there was a guest in the house that your mother wasn't aware of? She didn't call their ComeToDinner method so they would miss out.

Now, another alternative would be for you mother to just yell from the kitchen "dinner's ready" and it would be up to you, your siblings, your father and the guest to hear and go to the table. Your mother has raised her DinnerReady event and everyone who was listening for that event has then invoked their own ComeToDinner method. Your mother didn't have to know anything about who would come. She just raised the event and then it's up to the listeners to act accordingly. They could come to dinner or mot as they pleased. The guest your mother didn't know about also heard and came to the table.

So you see, events are a way to notify any object that happens to be listening that something occurred. The idea is that the object raising the event doesn't have to know anything about the objects handling it. That is up to them. The object raising the event simply broadcasts the notification and then come what may.

 

[Fred4Christ]

That helps me visualize it.

Thanks, those word pictures help. Do you think I am looking for the right tool for the job I am trying to perform in my app?

My guess is that I am. But because of the problems I am having, I couldn't help but wonder if I am picking the wrong tool.

Do you think it should work?
Will events do the job for helping me get a public function in a Module, to be able to raise an event. And that I can define a event handler method in a Form Class that can handle that event?
I have a Sub in my Form class that calls the "Function ExportProblem()" in the "Module ProbExport". ExportProblem also calls other functions. I want some of those functions to be able to raise an event "IHaveSomeStatus". And I hope to have a method in my Form class that can handle that event and record the status.

Should this work?

Thanks
Fred

 

[jmcilhinney]

Raising events in a module is not very common. I would suggest that events are the right tool for the job but modules are not. There is very little call for modules in a VB.NET project and most that exist should not. The only reasons to create a module would be to create a Main method from which to start your app, create some properties that truly need to be global to your project, or to group utility functions that don't logically belong to any other class. I'd suggest that the logic that you have placed in your module belongs in a class.