Vb Classic Programming Model

Can you help with these questions?

In order to properly model VisualBasic applications I'm trying to understand the basic principles of the VB programming model.

AbstractModelsAnswerQuestions, but models require that some questions are asked in the first place.

Here are some questions that don't seem clear cut (to me) from the documentation :

If VB relies on implementation of abstract interfaces but not inheritance, how do you obtain code reuse?
(Possibly by containing other objects, and mass event redirection??)
- What is a specific example? There are often GenericLimits to real world situations that textbooks don't seem to get.

Hope this helps:

Forms are simply a specific type of class, with the added ability that they have a visible component. The also have an hWnd assoicated with them, and can hence contain visible (or invisible) controls.

The relationship between a time and its form is simply that there is an implicit declaration of the form:

Dim WithEvents mytimer as Timer

You can use the timer (or any other control) in any class you like. Simply DIM it WithEvents and then handle the one's you're interested in. Of course, the control itself still has to be sited on a Form. But you then just pass a reference to it into your class.

I often use this to customise the way standard controls work. For example, say I have a TextBox? and I want to ensure that whenever it gets the focus it selects the entire contents. I have a helper class call TextSelector? which looks like this:

  ' Class TextSelector?

 Public WithEvents TheControl? As TextBox?

 Private Sub TheControl_GotFocus()
  With TheControl?
   .SelStart? = 0
   .SelLength? = Len(.Text)
  End With
 End Sub

In the form I might have

 Private selector1 as new TextSelector?

 Private Sub Form_Load()
  ' ...
  set selector1.TheControl? = text1
 End Sub

and that's all I have to do. You can use this approach for things like, restricting input to numerics, forcing it to upper case, and so on.

It may seem like work for this simple example, but if you have a *lot* of text boxes in your application ...

this is one of the ways to get code re-use.

I actually have a classwhich contains many of these "decorations" of a text box. Part of the initialisation is selecting which ones I want to apply to a particular text box.

-- KeithDerrick

VisualBasic is a ProceduralLanguage

A lot of programmers know a lot about Object Oriented Programming. Also in this Wiki is a lot of talking about programming from the OOPs point of view. Some people think VisualBasic is some badly implemented OO language, but it is a procedural language.

When you read about unit testing you may think you should structure all your code in a 'neat' way, in Classes but you shouldn't. Classes are just a simple add on, an extended Type definition, nothing more.

I figure, because VisualBasic is a procedural language all testing and structuring of your code should be done in a different way. However, I still have to find out how.

--GerardBuisman

The core of the code should be written in modules (*.Bas).

Why?

There is no should or should not. Place the code where it benefits. Methods which really don't need a context (internal state or a set of properties to work on) will probably benefit more in a sub. If it were in a class, we had to create the class just to use the method, then dispose the class. You can achieve nice, clean and reusable code in VB, but yes, it probably takes a lot of delegation. -- ThomasEyde.
Late update: I have done a ton of VbClassic development since I wrote the above. I have also done a lot of C#/ASP.NET development. Based on those experiences I have concluded that it is all about the mindset. If you try to create a VbClassic application the Java way, or the C# way, you will fail. VbClassic comes with its own set of idioms. Don't fight it, but exploit it. And you should put everything in classes whenever you can. Leave modules for the last resort. -- ThomasEyde

Possibly

VB makes heavy weather of some OO commonplaces; so much so that the VB programmer may often feel discouraged and fall back upon procedural idioms (e.g. case statements branching to function calls) as a way of managing program complexity. The losses and gains vary over the short and long term. Doing what's comfortable in VB is right in the short term. In the medium term, doing things the OO way might well pay off, though it'll cost ya. If you're programming for the long term, use a different language! -- DominicFox?
Some of us are skeptical of OO for the niche that VB targets. See ArgumentsAgainstOop. OO seems better suited to systems software than business applications in my opinion. Polymorphism makes some rather narrow (read unrealistic) assumptions about future change patterns in business. -- top

CategoryVbClassic