Instantiation gobbly gook

[tedsmith]

Can anybody really explain in simple terms with a simple example the term "instantiation"

I thought I knew what it meant but this definition from another site has me now completely confused:-

"In programming, instantiation is the creation of a real instance or particular realization of an abstraction or template such as a class of objects or a computer process. To instantiate is to create such an instance by, for example, defining one particular variation of object within a class, giving it a name, and locating it in some physical place.

 

[JoeAtWork]

What I am getting at is if there is anything in VB6 that you CANT do without using a "Class Module" , ActiveX or DLL, that can be done otherwise in straighforward code not using these above methods?

What you can't do is write professional and maintainable code. Oh sure, there are many amateur/hobbyist programmers who have turned out procedural code that basically works. But sooner or later this code will become unmaintainable.

Object oriented programming provides a structure for creating maintainable and scaleable code.

What you call "straightforward" is what I would call "spaghetti" code.

 

[strongm]

dilettente has alluded to typical VB-style event binding

I'd go further. All ActiveX-style event handling requires class modules. You can't raise or consume ActiveX events outside a class module. Neither

[tt]Dim WithEvents[/tt]

nor

[tt]RaiseEvent[/tt]

are valid outside a class module. You may not be interested in the latter if you are not writing your own ActiveX components, but you certainly consume them. Ah, says Ted, but I don't. Yes, you do - on Forms. And, as I have already pointed out, a form is a class module. Ah says Ted, but I don't have to do a Dim WithEvents on a form. No, VB does that for you in the background when you drop a control onto the form.

So, if you are saying that you are only interested in code that doesn't involve class modules then I'm afraid you'll have to stop using forms ...

 

[tedsmith]

You got me wrong.
I wasn't arguing that "ordinary code" was better or not nor did I mean that I didn't want to use class modules.
In my never ending search for knowledge, I just wanted to know if there was any situation why a class modules HAD to be used as I have never created anything that made it mandatory (yet).

Regarding structure and maintaining, I would have though that custom ActiveXs could be a problem because it's code is not usually visible at the same time as the main body of the app. One could have an obscure problem in the activeX you didn't know about that makes quick debugging harder.

I though ActiveX s were invented so the same code could be reused in different apps (or multiple times in the same app).

 

[dilettante]

I think VB6 masks a lot of this (in Forms) to make it easier to carry old VB3 code forward. If you stuck with the intrinsic controls as much as possible the old source code is fairly easy to bring into VB4/32, VB5, and VB6.
It isn't as useful today and tends to confuse matters for new programmers who don't carry the old baggage. But since classic VB never evolved further a lot of this old stuff never got phased out.

It leaves us with a transitional language that became a bridge to nowhere. There were only about 5 years between the release of VB3 and VB6, and VB6 has been around for almost 11 years now. People forget about this and often curse the quirks of VB6, but a lot of them are there to make transitioning code easier.

 

[MajP]

Can you run a business without email or the internet?
Yes. I know a couple.

Can you take care of personal hygiene without indoor plumbing?
Yes. People around the world and even still in this country do.

Can you get to school, work, shopping without a car?
Yes.

Can you build a house without power tools?
Yes. Ask the Amish.

Can you bank without and ATM card.
Sure. Do not know many people who do.

Can you live without a cell phone.
Sure. We did it most of our lives. But I bet now a days you panic when you head off to work and you can not find your cell.

Can you write a real program now a days without Object Oriented Programming (specifically custom classes)?
Sure. But just like the rest of the examples. It is not fun and it is not easy and it is getting more and more difficult as OOP becomes the norm with most programming. If you are talking toy programs in VB sure. If you are talking real programs, and you enjoy writing millions of lines of codes, you could probably still do it.

So there are probably not many examples where you have to use custom classes, but I can sure think of a lot where not using them would be extremely painful.

 

[tedsmith]

Well, looks like a gauntlet has been thrown down.

My problem now is to work out how I could be better off if I had used a class module in my last big project that has been in service without errors for the last 6 months.

This was a bus terminal that had 20 bus stops, each with a PC (& another application) feeding 6 monitors, a Database that contained all the timetable and a monitoring terminal that could see and change all departure times if the wrong bus turned up and send advice messages and multimedia presentations to each stop.

The server controller had two main subs and about 100 separate subs and functions each with a particular job rather than having it all in continuous code.
Main 1. one Timer that fired every half second & incremented a 10 second counter.
At various seconds in the 10 second cycle the main timer sub fed off to other subs so the main sub was easy to read.
Main 2. one indexed Winsock DataArrival led to Select Case Statements to identify who the server was receiving and the task needed, making it easy to follow.

The Winsock Dataarrival accepted a signal that each bus had arrived and departed and webcam pictures of the buses from network cameras when a bus arrived and info from a GPS system of the approaching bus's location so the time passengers saw would be the actual time the next bus would arrive. This independently continually modified the timetable database.

I separated main functions into 6 separate Modules to make it easier for future programmers to understand.

Getting the timing right was an interesting challenge and not one class module in sight!

Is there any way I could have used the "Add Class modules" to make this more "professional" or easier to write and where would my approach differ to OOP?

The client was a State Government. It took me 3 solid months to do. By the way, how much do you think I should have charged them for this?

 

[strongm]

>Regarding structure and maintaining, I would have though that custom ActiveXs could be a problem because it's code is not usually visible at the same time as the main body of the app

And yet you are happy - as you quite happily state in your later post - to use the Winsock control and ADO (Ok, an assumption there based on the fact that mention a database and on your use of it in other threads), both of which are custom ActiveX objects. In other words, your observation has some validity, but the downside clearly isn't enough to stop you (or thousands of other VB programmers) from using custom ActiveX components ...

(It should also be noted that you can have the source code to your own classes and to your main program open in the IDE at the same time, thus meaning you can debug them)

>if I had used a class module

You did. Your form(s). Without it you couldn't have got your Timer events¹ ... so the use of a class module (albeit one provided by VB rather than one where you specifically have to 'Add Class Module') has already made writing your program easier.

¹Yes, yes, Ok, with the API and callbacks it is possible to write your own non-COM timer events, but it is a lot of work just to avoid using the Timer control

>Is there any way I could have used the "Add Class modules" to make this more "professional" or easier to write and where would my approach differ to OOP?

Erm ... what you don't - generally - do is take a traditional procedural design and simply convert subs and functions into methods and properties in the hope that this will make your program better; that just ends up with a procedural program expressed slightly differently. You have to have a different design philosophy.

 

[MajP]

I could not fathom writing a program as you describe not using OOP with custom classes. Again as you show it can be done. It sounds as if you have multiple "Bus" entities or objects that depend on other events of other "Bus" entities.

In OOP "bus1" could listen to the events of all of the other buses react to their events, and could listen to the "controller" object (timer) and catch timer events.

You are obviously happy with what you do and not afraid of becoming obsolete. I do not think anyone can convince you on a post, you will have to see it for yourself. I am not a professional programmer, but I could not imagine there is enough work out there for anyone not coding OOP. I am also pretty confident without seeing your code that an OOP design would be more scalable, modular, flexible, expandable, easier to maintain, and less code. I assume you will always be a straight VB6 programmer and not work in JAVA, C++, C#, or .Net. For sure I can not imagine programming in those without OOP.

 

[tedsmith]

You both seem to have the wrong idea that I am arguing for not using classes or OOP or whatever!
I am not trying to create an argument and not champion any method nor am I excusing myself for my past sins or inadequacies.
I am simply trying to establish in plain language if and how I could use class modules and OOP in a task such as I describe.

I never said I wouldn't use ActiveXs. I have no problem in general (I hope) in using those that have the Microsoft stamp of approval but have been caught using third part ones before that had obscure bugs and I couldn't see their code.

I am a visual sort of person so I suppose a simple example of the exact same task written the "old way' and then using a class module and or OOP or "custom class" or whatever you call it is really what I need but I can't find one anywhere.

Could you perhaps explain by a simple example <In OOP "bus1" could listen to the events of all of the other buses react to their events, and could listen to the "controller" object (timer) and catch timer events.>

Because all my controls (including the indication boxes on the control screen created at run time) are indexed, I don't ever have any similar code repeated as you seem to suggest.
Eg. Bus Stop 5 uses Winsock(5) and its status indication is Label(5). All bus stops use the same Sub or Function.

Could you explain perhaps how the following example code would be done in OOP or custom classes?
Each one of the Subroutines below currently contain a number of other Sub-sub routines that could be in a different module. All data to the Winsocks() uses Propertybags

Dim Counter as Integer
Sub Clocktimer_Timer() '500ms 
'Every half second send data to only the latest needed indexed bus stop
For A=1 to 20
    If SendMyData(A, SendFlag(A))=True then 
       'This is a function that Sends Data to Bus Stop A 
       'if its Flag has been set and returns true 
       'if Winsock(A) is connected
       SendFlag(a)=False
       Exit For 'Send only once
    else
       IndicateAProblem A
    End if
Next

Counter=Counter+1
if Counter>5 then Counter=0
'at every 5 seconds do something different
Select case Counter
Case 1
  'Sub that checks & reports all winsocks for connection
  'resets to listen if temporarily disconnected

Case 2
  'Sub that Checks database for due buses

Case 3
  'Sub that gets new data and sets SendFlag(a) to change sign if bus arrives at a stop

Case 4
  'Sub that Indicates status of everything on Monitor

Case 5
  'Sub that updates timetable database from a GPS system if a bus is running late

End Select

End Sub

Function SendMyData (Index as integer, SFlag as Boolean)
If SFlag=True then
  PutTheDataIntoAPropertyBag Index '(subroutine)
  If Winsock(Index).State = sckConnected then
     Winsock(Index).SendData  InfoBag.Contents
     SendMyData=true
  End if
End If
End Function

 

[strongm]

>You both seem to have the wrong idea that I am arguing for not using classes or OOP or whatever!

No, no, not really. I'm simply arguing against your assertion that you haven't found a need to use a class module as yet. But you have. If a form was not a class module you could not use your somewhat important [tt]Clocktimer_Timer[/tt] event ...

 

[MajP]

strongm,
I beleive the OP is specifically talking about creating and using custom classes, not about using vb provided objects.

 

[strongm]

Forms are custom classes.

 

[dilettante]

I'd tend to lump UserControls in with VB6 Classes. It is often useful to apply either of these to subclass some existing system provided class. When the class you want to extend is a control you can use the UserControl, in many cases with InvisibleAtRuntime True.

Look at the example of the Winsock control.

These are basically worthless unless you add several data items and a certain amount of code to them. Quite commonly people use TCP with message framing which requires things like a stream assembly buffer, message framing and parsing logic, etc. You can wrap all of this up with a Winsock control in a new UserControl that exposes neat SendMsg and GetMsg methods and a MessageArrival event, etc.

You can choose to reuse this as source code or compile it into an OCX. Either way you now have a component operating at a higher level than the raw Winsock control. By implementing some versatile messaging protocol on top of TCP you have a new control you can use in your server and clients, perhaps for many different applications.

Debug once, reuse many times. What a time saver! By making it an external OCX it is also easy to deploy updates without recompiling all of your monolithic programs.

For special needs you might even subclass it yet again (or use the source as a baseline to start from on a new Winsock subclass). For example you might want to define a number of fields within the messages, perhaps even raising different events when different kinds of messages (based on a Type field) arrive.


Such an approach dispenses with the need for a raft of parallel Public arrays (or many passed array parameters) used by bits of code scattered all over. Everything is neatly wrapped in a bundle, and you'll only need a single control array to hold everything. For something like a Winsock server scenario it can encapsulate an "in use" property you can use to allocate connection requests (reusing instead of reloading controls). Just use a separate naked Winsock control as your listener.

This kind of thing is extremely helpful in reducing the complexity of large programs. The same thing applies to any other objects, blobs of data, and snippets of logic related to them.

 

[MajP]

Strongm,
I think we are splitting hairs. Granted A form's associated module is a class module, like any other class module albeit a very a special one. I just do not think I have seen the form's module referred to as custom class module. Because it is so unique and provided by the creation of the form, I have only seen it discussed explictly as the Form's class module. Clearly the OP was referring to adding a class module " Is there any way I could have used the 'Add Class modules.

 

[strongm]

>I just do not think I have seen the form's module referred to as custom class module

Nevertheless, that's what they are ...

 

[dilettante]

That is what they are of course. Just a kind of class that is created to provide a default instance named the same as the class.

You can do this with a regular Class module too, though you have to edit the text of the module to get at the necessary attribute ([tt]Attribute VB_PredeclaredId = True[/tt]).

 

[tedsmith]

Ahem
The "Class module" that I was originally referring to was the item in the Project drop down menu named "Add Class Module" and why I had never need to use this IDE facility.

I have never needed to create a class that didn't also have something that needed a form to be visible. Others such as a higher speed timer that used withevents for Jumbo text scrolling, I put them in a code of the form that showed the text anyway.

I was not implying that forms weren't 'classes' or that I hadn't used one without knowing.

>You can wrap all of this up with a Winsock control in a new UserControl that exposes neat SendMsg and GetMsg methods and a MessageArrival event, etc
This encapsulates what I was asking about home made ActiveX controls etc. and the question was - does it really work any better or is it just a matter of style?
It might make your code look neater but if you keep the extra stuff hidden from future programmers how can he know if there isn't an obscure bug ?

 

[dilettante]

The idea is that bugs are less obscure when the code isn't in scattered snippets all over the place. Modularizing the logic makes it easier to create small "testbed" projects for debugging suspected problems too.

 

[JoeAtWork]

Ted,

First of all, congratulations on writing a rather complex application that has been bug free for six months. That is commendable no matter what design paradigm you use. After all, if I had a choice between inheriting well-written procedural code versus badly written OOP code, I'll choose the good code over the bad every time.

Now, to try to answer your question, one way I see that OOP could improve the design is in later code maintenance. Let's say somebody had to later take over your code, how quickly could they get up to speed? How quickly could they find the exact spot of a particular error?

Granted, you may have organized your subroutines into various modules, but in the end it still basically amounts to one large collection of hundreds of subs and functions. The new programmer will have to trace through the code, following it's logic, to slowly discover the different parts of the system. Let's say the bug the programmer is trying to find happens near the end of the application's "life" (like the end of the day). To discover which subroutine is causing the error, and to understand how it got to that state, the programmer pretty much has to step through the code, procedure call after procedure call, until he finally gets to the spot where the error is.

If everything is an object, it tends to be much quicker to find what you are looking. If the bug has something to do with one of the buses, you can be pretty confident that you should concentrate on you BUS class.

To argue from the opposite end of software development, I find it much easier to translate requirements into OOP design rather than procedural. Procedural programming forces you think sequentially, which is usually not how things happen in real life. With OOP programming, you can usually translate your Use Case statements directly into OO code, because you simply take the nouns in your Use Case and translate them into objects. For example, to take a snippet from your own Use Case:

This was a bus terminal that had 20 BUS STOPS, each with a PC (& another application) feeding 6 MONITORS, a DATABASE that contained all the TIMETABLES and a MONITORING TERMINAL that could see and change all departure times if the wrong BUS turned up and send advice messages and multimedia presentations to each stop.

Everything I've capitalized are candidates to become objects, everything I've italicized are likely methods that the object contains to do its work. For example, the class MONITORING_TERMINAL would have a method SendAdviceMessage. See how using OOP techniques, you can build code that mirrors the real life situation. It is a far more intuitive organization of code, because it is based on real life. Also, you do not have to think as abstractly as you would if you had to implement this procedurally (i.e. you don't have to constantly check in a loop if it's time to SendAdviceMessage, instead there would be some event that would trigger it, probably by some collaborative object).

I hope I've made the OOP concepts somewhat clearer. I have only really touched on the bare bones of OOP, there are other usefull concepts such as inheritance, design patterns, etc.

 

[dilettante]

This is probably just something one has to work out oneself to understand its benefits.

I know people who never made the jump from QB to VB even in the simple days of VB3 because they fight the paradigm so hard. Most of them either went to something like PowerBASIC (blech) or later FreeBASIC (eww) or started hacking around in C. As a result they either dropped out or never were serious programmers, and many became vociferous anti-VB mouthpieces on Usenet and forums over the years.

I can understand some of the attitude because things went too far the other way in VB.Net for my tastes. For me even that wold have been more forgiveable if not for the .Net part of VB.Net (slow and bulky garbage-collected runtime and framework).

We all carry our biases.