Zbigniew GALUS said:
Hello, (...)
All my codes
are in Modules and I've not used classes in VB Access.
If it's not possible I could buy a book for my two weeks
winter holidays to jump into VB classes programming.
================
Hi,
If we start with a "structure", a collection of related data, like a window
which can be described by its top-left and bottom-right position, we can see
the structure as a new kind of "data type". In general, we have more than
just that, we want, indeed, work with that data, so, there are methods that
somehow "belong" to that data. If we glue that data and the methods (code)
together, in a single package, we have the starting idea of what is a basic
class. There are advantages, indeed. Without classes, assume you have to
describe a window, you would probably say:
Dim PositionTop As Long
Dim PositionLeft As Long
Dim PositionRight As Long
Dim PositionBottom As Long
and that would work fine, as example, you can say:
-------------------------------------
Public Property Get WindowWidth( ) As Long
WindowWidth = PopsitionRight-PositionLeft
Exit Property
-------------------------------------
That works fine as far as you have just one window, but if you want two
windows... you are left to either add:
Dim PositionTop2 As Long
Dim PositionLeft2 As Long
Dim PositionRight2 As Long
Dim PositionBottom2 As Long
or to use array notation, and change all your existing code, like:
Public Property Get WindowWidth(Optional ByVal Who As Long=0) As Long
' without argument, return the width of the first window
' to match, as close as possible, the previous behavior
WindowWidth = PopsitionRight(Who)-PositionLeft(who)
Exit Property
If you use a class concept, you would move your data and your code in a
class (that is the blue print) and use object:
Dim myFirstWindow As classWindow
Dim mySecondWindow As classWindow
Dim arrayOfWindows( ) As classWindow
And your class, classWindow, may got its data AND its code like:
Public PositionTop As Long
Public PositionLeft as Long
Public PositionRight as Long
Public PositionBottom As Long
Public Property Get WindowWidth( ) As Long
WindowWidth = PositionRight-PositionLeft
End Property
With that simple modification, now, each object ( myFirstWindow,
mySecondWindow) has its OWN data, form the class, but also share the code.
Back in the module:
Dim myFirstWindow As classWindow
Dim mySecondWindow As classWindow
Set myFirstWindow = New classWindow
myFirstWindow.PositionTop = ....
...
Set mySecondWindow = New classWindow
mySecondWindow .PositionTop = ....
...
Most of the time, we would NOT expose the data stored in the class, for
practical reasons. As example, if we want to store the PositionTop,
PositionLeft, WindowHeight and WindowWidth, instead of the four previous,
and implement as property the PositionRight ( and PositionBottom), why not?
After all, maybe it is more efficient, for us, to have the Width, and
Height, than the bottom-right position? Doing so, we can use:
Private mTop As Long
Private mLeft As Long
Private mWidth As Long
Private mHeight As Long
Public Property Let Top( ByVal newTopValue As Long )
If newTopValue < 0 then exit property
' won't allow a position outside the screen
' can make other checks, if we want
mTop=newTopValue
End Property
Public Property Get Top( ) As Long
Top=mTop
End Property
....
Public Property Get Bottom( ) as Long
Bottom=mTop+mHeight
End Property
....
So, not only we are free to really make the implementation independent of
the way we use the object, and its methods, but we can also make additional
checks. In fact, an object can "contain" other objects. Some authors call
that "inheritance by containment", or "by delegation" since, say, a car
contains four wheel, and to move the car forward, the car-class would
delegate the order to move forward to each of its powered wheels! :
'from car class
Private FLwheel As wheel ' front left
Private FRwheel As wheel ' front right
Private RLwheel As wheel
Private RRwheel As wheel
....
Public Sub MoveForward( xMeter As Long)
'.. check if there is an obstable
...
'so far so good, delegate the action
FLwheel.MoveForwardLinear x
FRwheel.MoveForwardLinear x
...
' display the end result
Me.Repaint ' Me == me, my code + my data
End Sub
You observe that the dot syntax become involved, and thus, can be cascaded.
Assume the FLwheel is public, rather than private, so, someone outside the
class can call it, through the car object. In a module:
Dim x As car
...
x.FLwheel.MoveForwardLinear xMeter
and thus, you get a notion about where a multiple dot syntax can come from.
Anyhow, having the possibility to "own" an object, we have the possibility
to call (call back, delegate) its method, but if it has events, we can
answer to them when the object internally raised ( events are not necessary
synchronous, callback are synchronous). As example, if the front left wheel
find it has a flat, it may raise an event, telling to the car that something
is wrong. Not all car models necessary handle that "signal", not a problem,
if the car has no "code" about the event, nothing would occur, but if the
our car "model" is fancy enough, we would "dim" the wheel object as being
WITH EVENTS, which, for a short story, allows us to then use the special
syntax
Private Sub ObjectName_EventName ( list_of_arguments )
...
End Sub
if we choose to "do something" in cases the said ObjectName (we own it) ever
"raise" the mentioned event. If we do not supply code, nothing would be done
either. We could use and interface, instead of an event, if we would be
obliged by an answer, or want be synchronized.
That is by no mean complete, but too much may be an overkill. I don't know
if the books are still available, but Peter Wright's "Beginning Visual Basic
6 Objects", at WROX (ISBN 1-861001-72-X) is not bad, neither, but more
oriented about COM, "Visual Basic Object & Component Handbook", by Peter
Vogel ( ISBN 0-13-023073-1 ), and definitively, "Microsoft Visual Basic 6.0
Component Tools Guide", more advanced, Microsoft Press (ISBN 1-57231-864-3),
also available on MSDN Library CDs shipped with (Classical) Visual Studio
6.0 (not with Visual Studio 7.0) . Sure, COM is not rumored to be the
future, so, some dot-Net book could be of your interest, in the future...
but that is not applicable for actual VBA code, and no book about VB.Net...
I have read so far... is good enough in my opinion to deserve my
recommendation (note the exit door I have kept open, I said "none I have
read so far", and "about VB-Net", and I won't tell which book I have read so
far, because, sure, I haven't read ALL of them ...
).
Hoping it may help,
Vanderghast, Access MVP
