Novice iLogic/VBA Discovery: Defining Classes - Dim vs. Set

[cadman777]

OK, here's another little tidbit that makes all the difference in the world for me to understand what the heck is going on in these VBA/iLogic programs. This is hidden info that nobody talks about (or KNOWS!), and everybody seems to ASSume that you DO know it. But UNLESS YOU STUDY VBA you will NEVER know this! Here it is taken from Mueller's book, VBA for Dummies, pages 183-4:

Defining Classes

You might want to think of a class as a substitute for a Function or a Sub, but classes are separate. A Function or Sub always describes a procedure — a list of steps. A class describes a thing. You can visualize a file because it’s a

thing. That’s why VBA uses classes to describe the file system and uses objects to work with individual file system elements, such as a drive. Although you might read that objects are substitutes for procedures, the two kinds of programming have definite places in your programmer’s toolbox. Make sure that you work with both as needed.

To build an object, you tell VBA to instantiate (create an instance of) the object. All the code required to build the object appears in the class. As a VBA user, you create the class and not the object. Here’s a simple example of

the two-step process used to instantiate an object:

‘ Create a reference to the file system.
Dim MyFileSystem As FileSystemObject
‘ Create a reference for the target drive.
Dim MyDrive As Drive
‘ Fill these two objects with data so they show the
‘ available space on drive C.
Set MyFileSystem = New FileSystemObject
Set MyDrive = MyFileSystem.GetDrive(“C”)

VBA creates the object, MyFileSystem, based on the blueprint provided by the FileSystemObject class. Likewise, VBA creates the object, MyDrive, based on the Drive class.

Telling VBA that you want to create these two objects by using the Dim statement is not the same as instantiating them. The Set statement instantiates the object. You Set an object equal to the blueprint contained within a class.

You can instantiate objects by using a number of techniques — the previous example shows two of them. In the first case, MyFileSystem is instantiated by using the New keyword and the name of the class, FileSystemObject.

In the second case, MyDrive is instantiated based on an existing object contained within the MyFileSystem object. The GetDrive method tells VBA which Drive object to use within the MyFileSystem object.

My way of saying it is: DIM DECLARES  A VARIABLE, SET CREATES AN OBJECT.

The VARIABLE is a DATA CONTAINER, the OBJECT is the PROCESS that works on that DATA.

BIG difference between the two.

So now, when you see DIM and SET in VBA/iLogic macros, you know what they're doing, instead of just pretending to know, while using someone else's code to hack your way through your project AND HOPE IT WORKS!

Cheers

[Owner2229]

"Set" (in this case/usage) is VBA specific, not used in iLogic. In iLogic you can do something like this instead:

‘ Create a reference to the file system.
Dim MyFileSystem As New FileSystemObject
‘ Create a reference for the target drive.
Dim MyDrive As Drive = MyFileSystem.GetDrive(“C”)

Also, classes aren't substitutes for Functions and Subs, but objects used to store, work with and limit procedures and variables. You can toss them around and pass them to other procedures, which defines VBA/VB/iLogic as object-oriented programming.

The VARIABLE is a DATA CONTAINER, the OBJECT is the PROCESS that works on that DATA.

The Variable is a reference pointer pointing to the Object. You can have multiple Variables pointing to the same Object.
The Object is the data container (Class), which gives you access to it's procedures and variables.

[cadman777]

Thanx for the input Mike.

In iLogic you can do something like this instead ...

Thanx for the iLogic 'tip'. If I can learn enough of this 'language', I may eventually get to the place where that tip means something to me and becomes useful. I can only hope, considering the massive amount of work I've already put into learning how to write macros, but haven't yet been able to write even one!

Set" (in this case/usage) is VBA specific, not used in iLogic ...

After a month of wasting time trying to figure this stuff out, I learned the hard way (contrary to Autodesk propaganda LIES) that learning iLogic to do anything of import REQUIRES learning VBA, and there's a VERY STEEP learning curve involved.

Also, classes aren't substitutes for Functions and Subs ...

Yeah, that's what Mueller says. I can't relate to it yet, b/c I haven't learned how to write any programs. But once I do, eventually the distinctions will become evident. It's a simple matter of not knowing what you don't yet know.

The Variable is a reference pointer pointing to the Object ...

That's not what I got out of Mueller's book. What I got out of his book was what I said. Far as I'm concerned, the variable IS the data container in my 'program', b/c when I create a variable and equate it to a piece of data, it's that variable that's holding the data throughout the procedure that the 'code' is processing for me. The impression I got out of reading Mueller's book is, an OBJECT is a hunk of code that's been encapsulated into a fixed container, and the CLASS is the 'blueprint' for producing that OBJECT. It's like DNA vs. the living organism. DNA is the 'blueprint' of that organism. Cloning is a perfect example of this (even though it's morally corrupt). Your comment sounds like what Mueller says about some people: This differentiation between classes and objects is important to remember because many information sources confuse the two concepts. You need to keep them separate to better understand how objects work.

Cheers 

[bshbsh]

---

My way of saying it is: DIM DECLARES  A VARIABLE, SET CREATES AN OBJECT.

---

Sorry, but this is not correct.

Dim just declares an object type (that must not be a variable) and allocates memory for it.

Set does not create an object (unless you are in implicit mode), it just sets the reference of an object (which in explicit mode has to be already declared by Dim) to an instance (which may be an already existing or a new instance which then gets initialized).

[cadman777]

OK, bshbsh, I stand corrected.

Now go back and read what you said and ask yourself:

Does that sound like the federal tax code?

I mean really!

It sounds like GOBULDYGOOK for cryin' out loud!

Anyways, now that I know the proper way to say that, let me tell you from a novice perspective that NONE OF IT HELPS ME WRITE CODE.

What a clusterf**k this world of computer programming is!

What does that tell you about how EASY it is to learn how to write macros for Inventor?