to create and rate content, and to follow, bookmark, and share content with other members.
vrf Object Orientation for Everyone - was ActiveX Spreadsheet object in VXL
Question asked by
on Nov 16, 2005
Show 0 Likes
Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
No one else has this question
Mark as assumed answered
This content has been marked as final.
Show 1 comment
(Required, will not be published)
Nov 16, 2005 1:04 AM
Object Oriented Programming: An Orientation.
Object Orientation is a method of programming that lends itself well to
modular composition, code reuse and organization. The principals of Object
Orientation have been around for a very, very long time. One can accomplish
Object Oriented Programming in just about any language, but some languages
are designed with these principals in mind. Most widely known of these is
C++ by Bjorn Stroustrup.
Toward the goal of code reuse Component Technology was thrown. The most
widely known Component Technology is Microsoft's COM - Component Object
Model. Until recently, we VEE programmers were only interested in it's
ActiveX aspects. Last year VEE gained the ability to work with raw COM
through the COM Interop facility of a framework library for another
component technology birthed by Microsoft .Net
ActiveX is a catch-all phrase that describes a wide range of strategies by
Microsoft, all more or less targeted at modularity and interchangeability.
There is Active Scripting as well as Active Documents and a host of other
terms that each describe their own little world. In the end though, Active
Anything is always built on COM.
Microsoft .NET is another term like ActiveX: it's kind of a catch all that
describes a whole bunch of stuff which generally has to do with their dotNET
concept. We as VEE programmers however are basically only concerned with
it's component technology and the omni-present .NET Framework Class Library.
And, as far as I know, that aspect of .NET (it's component technology)
doesn't have any specific name.
VEE itself is not particularly Object Oriented, though of course you can use
OOP techniques if you wish. Oh, I know there are things called "objects" and
you can group together many objects into a "user object", but calling a
thing an "object" does not automatically make it an object as OOP would
define the term.
Object Oriented Programming is characterized by certain qualities. Now, I'm
not going to try to provide a complete and detailed description of OOP.
There are plenty of great articles available for free that do a much better
job of that than I could, but all I want to do is give some generalizations
and define some terms that will help VEE programmers orient themselves.
First of all, OOP is characterized by a conceptual hierarchy. Take a book
for example. A book is a collection of pages bound by two covers & a spine.
A page is a collection of paragraphs. A paragraph is a collection of
sentences. A sentence is a collection of words delimited by punctuation. A
word is a collection of letters delimited by spaces. This conceptual
hierarchy can be expressed as follows:
Kinda weak but you get the idea. This hierarchy is more or less based on
English. A more global "object model" of a book would likely change names or
omit stuff. For ideographic languages, a "character" would be a more
appropriate name for a final unit than a "letter". Ideographic languages
that are specifically pictographic don't have letters or ideographic
characters, they have picts.
And of course this isn't even complete. There's no Chapter object, and yet
most books have chapters. Different types of books might use entirely
different terms. A Bible object for instance would most likely consist of a
collection of Books that are divided into Chapter and Verse collections.
...And so on...
Some Objects don't have much of a hierarchy at all. One example is a
Rectangle. It has four "members": left, top, right, bottom, each a number
that corresponds to a screen pixel. This Rectangle Object illustrates
another characterization of Objects: member data.
An Object usually consists of some data. This whole idea of making an Object
contain data is called "encapsulation". Another characteristic of an Object
is that it usually has "members" that operate on its data, and these members
are called "member functions". For instance, the Book Object would probably
have a member function called Read that would render the contents of the
Book as audible words. Another might be Print. A Rectangle might have member
functions called Draw or Rotate.
These member functions will usually take "parameters" that control how the
operation is performed, Read(female) to speak in a female voice, or the
Rectangle might have Rotate(x, y) to rotate the rectangle about a specific
point, or Draw(to_printer) to draw on a printer instead of on the screen.
Very often, these parameters are optional - the Object provides some default
behavior that is only modified if parameters are passed.
These are some of the most basic qualities of OOP: Objects are expressed in
a hierarchical form. An Object encapsulates its data, and contains member
functions that operate on that data. The behavior of these functions can be
controlled by passing parameters to the function. Another quality of OOP is
called "function overloading". Though this is more typically language
dependent than an actual quality of OOP, it's important to VEE for .NET.
Overloaded functions take parameters of different types. For instance, the
Rectangle's Rotate function. Let's say there's another Object called a Point
that has two members: x and y. It's purpose is to define one pixel on the
screen. Well, Rotate can accept an x and y parameter, but it should also be
able to accept a Point parameter as well. That's an example of function
overloading. One function definition might look like: Rotate(int x, int y)
and another might look like: Rotate(Point pt).
One more quality of OOP is called "inheritance". An Object can inherit all
its progenitors' attributes - it's member data and functions. Let's say that
the author of the Rectangle forgot to include a color. You can include this
most important of attributes by creating a new object from the existing one
that inherits all it's attributes - myRectangle - and giving it a single
attribute: Color. myRectangle still has all of Rectangle's properties: top,
right, left and bottom as well as Draw and Rotate.
These then are the qualities of OOP with which we as VEE programmers (who
delve into ActiveX or .NET anyway) should be familiar with:
1. Objects are expressed in hierarchies.
2. They encapsulate data and functions that operate on that data.
3. Their functions can be overloaded to accept different parameters.
4. Child objects can inherit their parent(s') attributes.
There is one quirk of language that's important and that's a member's
"storage class". It's a bit difficult to explain, but what it boils down to
for us is that if something is marked "static" then that means it's always
there and it's shared between all Object "instances".
This is the hard bit! An Object is a virtual thing that exists. A "Class" is
a conceptual thing that can potentially exist. An instance of a Class is
called an Object, and is assigned to some variable.
Usually, all Objects share the code that is member functions, but they don't
share data. Each instance contains its own data. The exception to this rule
for data is when that data is "static". Let's say that the author of
Rectangle kind of sort of prepared for a Color attribute, but didn't quite
get it done. Let's say that he included three static members that are equal
to the numbers that are interpreted by video cards as red, green and blue.
These members are called colorRed, colorGreen and colorBlue.
In fact, if this were an actual example then Rectangle.colorRed would be
0x000000ff, Rectangle.colorGreen is 0x0000ff00 and Rectangle.colorBlue is
0x00ff0000. It's also worth mentioning that these would be the *initial*
values. Static doesn't necessarily mean "read only", but it *does* mean
"shared". If one instance of Rectangle changed the value for colorRed then
that value would change for *all* instances. Of course, this would make
things *very* confusing so static practically always means "read only" also,
but just bear in mind that the two do not need to go hand in hand.
For example, in VEE 7.x, select System->Environment->Machine Name and look
at the code it generates: System.Environment.MachineName. The dots represent
hierarchy levels in the dotNET Function Class Library. Now, open the object
browser and browse to: Category: .NET/CLR Objects, Assembly: mscorlib,
Namespace: System, Type: Environment. Look in the Members list for
MachineName and hilite it. You'll see down below that it says "STATIC
PROPERTY MachineName As Text". Below that you'll also see "read-only", which
means that this particular static property can not be changed.
The rule for functions is far less confusing: static means it's always
available, *even without creating an instance*. For example, in the same
Members list, look down to Exit and hilight it. Down below you'll see
"STATIC METHOD System.Void Exit(Int32 exitCode)". Because this function is
static, you can execute it at any time without creating an instance of
Try it! Click "Create Call" and drop the call on your workspace. Delete the
input terminal and change the parameter "exitCode" to "0". Click outside the
call, hit Ctrl+G and VEE goes away. Wow man! *NOW* you know how to shut down
a VEE program without stopping it first.
When you're mucking about with ActiveX, you won't see any overloading and
you won't notice any inheritance. This is because ActiveX sort of
deliberately excluded those kinds of things from happening. That's not
entirely true really, but from the our point of view it's true enough. Now
.NET on the other hand is a different story. This is a more mature component
technology and you see these kinds of things all the time.
Take the function ToString for example. Every object in the FCL has a
ToString function, and it's because they're all inherited from a base
Object. You also see a lot of overloading going on. Just for fun, open VEE
again and drop the same formula (System->Environment->Machine Name) on a
workspace. Open the F&OB and navigate to mscorlib.System.Enum. Take a look
at the member list, and notice how many ToObject methods there are! Hilite
the first one and read "STATIC METHOD System.Object ToObject(System.Type
enumType, System.Object value)".
Now press the down arrow and watch how the function text changes. The second
parameter's type changes to System.SByte, Int16, Int32, UInt8,
System.UInt16, System.UInt32, System.Int64 and System.UInt64. ToObject is an
overloaded function. They're all named ToObject, but the type of one of the
The icons you see next to these things always mean something, and
fortunately that something is very consistent. Unfortunately I have to
switch to HTML in order to paste pictures in... and then I have to make
dinner. And then South Park is on. And tomorrow I have to go wrestle with a
computer. And .. well, I'll try to get an icon reference together by Friday.
You are currently subscribed to vrf as:
To subscribe send a blank email to "email@example.com".
To unsubscribe send a blank email to "firstname.lastname@example.org".
To send messages to this mailing list, email "email@example.com".
If you need help with the mailing list send a message to "firstname.lastname@example.org".
Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
Show 0 Likes
Retrieving data ...
Firmware rev 1.14 released
Converting an 8753ES to 75 ohm operation
PCIE Gen3 Template
Help with Class-E power amplifier design