The Official VB6 vs VB.NET Thread
The Official VB6 vs VB.NET Thread
The Official VB6 vs VB.NET Thread
The Official VB6 vs VB.NET Thread
The Official VB6 vs VB.NET Thread
The Official VB6 vs VB.NET Thread The Official VB6 vs VB.NET Thread The Official VB6 vs VB.NET Thread The Official VB6 vs VB.NET Thread The Official VB6 vs VB.NET Thread The Official VB6 vs VB.NET Thread The Official VB6 vs VB.NET Thread The Official VB6 vs VB.NET Thread
The Official VB6 vs VB.NET Thread The Official VB6 vs VB.NET Thread
The Official VB6 vs VB.NET Thread
Go Back  Xtreme Visual Basic Talk > > > The Official VB6 vs VB.NET Thread


Reply
 
Thread Tools Display Modes
  #41  
Old 02-08-2005, 10:58 AM
John's Avatar
John John is offline
Bit Flipper
 
Join Date: Feb 2002
Location: The Inner Loop
Posts: 5,550
Default


How long ago was that? It has come a long way since it first started out and it is a great benefit to those who can't afford Visual Studio (self employed, students, etc.). I'd much rather see these people use #develop than pirate VS as they did/do with version 6.

I agree that VS is far and away a better product but #develop is a perfectly viable solution for those without much money and it is a good way to try out .NET without dropping a few hundred bucks.
__________________
Subclassing|Magnetic Forms|Operator Overloading (VB2K5)|QuickSnip.NET

"These Patriot playoff wins are like Ray Charles songs, Nantucket sunsets, and hot fudge sundaes. Each one is better than the last." - Dan Shaughnessy
Reply With Quote
  #42  
Old 02-25-2005, 11:03 AM
JonathanEngr JonathanEngr is offline
Centurion
 
Join Date: Feb 2004
Location: North Carolina, USA
Posts: 117
Default

Ouch... this forum really doesn't answer the question very well. I'm someone who uses programming from time-to-time to make certain tasks easier, but who knows? Maybe one day I will create a program that could be worth marketing. Should I change to VB.NET now? Ever? Would there be a BETTER language than either out there to learn? Should we all just go back to learning machine language (isn't that what it was called?) back in the day when all the programming was done in 1's and 0's?
Reply With Quote
  #43  
Old 02-25-2005, 11:39 AM
Mike Rosenblum's Avatar
Mike Rosenblum Mike Rosenblum is offline
Microsoft Excel MVP

Forum Leader
* Guru *
 
Join Date: Jul 2003
Location: New York, NY, USA
Posts: 7,848
Default

We struggle handling this issue...

The problem is that this question is incredibly broad. I personally feel that the answer depends strongly on 3 factors:

(1) What types of programs do you wish to produce?

If Games, then probably stick to C/C++. For large-scale Office Apps, then VB6, VB.Net or C# is likely your best bet. If Automating MS Office Applications, then VB.Net will be harder than VB6/VBA but cleaner/easier than using C#. (Actually, I think that VBA guys should stick to VBA for now…)

(2) What is your programming level? What languages do you know previously?

My guess is that a Java programmer would prefer to move into C#. The syntax is similar and the OOP concepts largely borrowed or at least parallel. But a VB6 programmer would find VB.Net more comfortable.

However, "programming level" does come into play. If one knows VB6 very well, but is not very OOP oriented (say, you don't use Classes much, don't know how to use the 'Implements' keyword, etc.), then the move to VB.Net could be very time consuming. The .Net language is vast and OOP is hard. OOP is very hard if you have not used it much before.

(3) Money.

If you have a working version of VS 6.0 and don't wish to drop US$500 on VS.Net that's a hurdle! VB.Net Standard is only about US$100, so that's a pretty good way in, and the 2005 Beta versions are free, although I don't think that one is licensed to distribute with the Beta version.



My overall opinion is that a programmer must move forward with his/her art. If one's "art" is ASM and C then there are no major changes going on... They should probably continue learning new algorithms and techniques within one's field.

But I personally think that a VB programmer really has to see "the writing on the wall" and move forward. It is a very difficult move forward, mind you; you cannot just "jump right in" to VB.Net at all. I've now finished my 3rd straight month of solid learning/studying/programming in VB.Net and I still can't quite do what I used to do in VB6.

My advice would be to continue with VB6 for now. Get a good book and read it on the side. Keep it with you on the train, by your bedside, whatever... As you read it, it will start to sink in. There is a listing of books that this forum's experts have recommended here: Visual Basic.Net Books.

I would also download the VB.Net 2005 Beta Express, just to tinker with as you learn new concepts by reading the book.

Eventually you'll learn some cool things in .Net and will want to do it in .Net. But it will take a long while before one feels more comfortable in VB.Net than they were in VB 6.0.

This is just my advice! Good luck...

,
Mike
__________________
My Articles:
| Excel from .NET | Excel RibbonX using VBA | Excel from VB6 | CVErr in .NET | MVP |
Avatar by Lebb

Last edited by Mike Rosenblum; 02-26-2005 at 12:19 AM.
Reply With Quote
  #44  
Old 02-25-2005, 11:46 AM
Mike Rosenblum's Avatar
Mike Rosenblum Mike Rosenblum is offline
Microsoft Excel MVP

Forum Leader
* Guru *
 
Join Date: Jul 2003
Location: New York, NY, USA
Posts: 7,848
Default

Oh and, Jonathan, more specifically to you...

Quote:
Originally Posted by JonathanEngr
I'm someone who uses programming from time-to-time to make certain tasks easier, but who knows? Maybe one day I will create a program that could be worth marketing.
If you are a VB6 programmer currently "programming from time-to-time to make certain tasks easier" then I think you can stick with VB6 for a very long time. VB6 is not going away, and the advantages of VB.Net is basically full OOP capabilities that make large-scale programming easier to manage. For small scale projects, it's hard to think of advantages, and, as I said, learning .Net is a fairly large hurdle.

But I don't know your skill level and desire to move up... If your skill-set is pretty high -- even if you don't program all that often -- then I think that there is still a good chance that you'd like learning .Net. In other words, I'd still get a book.

You didn't state what language(s) you currently program in, but if it's not VB6, then you might consider C#. But if your only previous language was VB6, I would strongly recommend learning VB.Net first. Once you've become fairly competent in VB.Net, you could then easily learn C# or other .Net languages, but jumping straight from VB6 to C# in one jump would give you a major headache, I think.
__________________
My Articles:
| Excel from .NET | Excel RibbonX using VBA | Excel from VB6 | CVErr in .NET | MVP |
Avatar by Lebb

Last edited by Mike Rosenblum; 02-25-2005 at 12:35 PM.
Reply With Quote
  #45  
Old 02-25-2005, 03:20 PM
JonathanEngr JonathanEngr is offline
Centurion
 
Join Date: Feb 2004
Location: North Carolina, USA
Posts: 117
Default

Mike--

Wow... thank you so much for taking the time to reply at length. I apologize it has taken *me* so long to reply--it's been a busy day.

My programming experience before VB6 was QBasic and Pascal, and my skill level was very limited in both languages. I'm an engineer by trade, and thus have never had any formal training in programming other than the required one semester of fortran/pascal in engineering school. When I was younger I was quite the computer nerd, MS-DOS and PC-DOS were the operating systems (well, after my Apple IIc was bookshelved), and I used to tinker for long hours on the Basic language packaged with DOS. It was, of course, very limited, and the lack of documentation made for some pretty cryptic programs. I was surprised, however, how similar VB was to these languages when I began studying it.

The main reason I even began studying VB was to automate many of the tasks we do here at my firm. There are many iterative equations that don't work too well with Excel, and I also write stand-alone programs to do simple repetitive tasks and equations. Thus, I don't need vast programming experience despite the fact it would be a very nice feather in my cap. Also, I don't have much time to learn programming languages, so I need to make the most of the time I do have. I was reading that VB 6.0 might be incompatible with future OS's, and that's a bit scary to me. Do I need to focus my energies now on VB Net to make the most of my time? It sounds like moving to VB net is much more than just a new language, but an entirely new concept to someone like myself. What is OOP? I almost feel like a burden on boards such as these due to my limited programming knowledge, but I'm not sure where else to turn.

To close out, I have been through John Smiley's Learn to Program in VB 6.0 and have a firm grasp on everything in the book. I just purchased two more of his books--VB Examples and VB Objects, and am zipping through them pretty handily. Thus-far, with these books and this forum I've been able to do most everything I've wanted to do. As I learn more I'm simply going back and "simplifying" my programs by making the code more complex! Hmmm... that sounds odd, doesn't it? Anyway, I went to Smiley's website today thinking he'd have the VB 6 vs VB net answer, and to be quite honest I was horrified. His site was very outdated in the VB sections making it seem like he might be ready to bail. Even his comment on VB net were from back in 2002.

So... this is where I am with my skills and what I try to do with the skills I have. Thanks in advance for any futher input!
Reply With Quote
  #46  
Old 02-25-2005, 03:42 PM
HardCode's Avatar
HardCodeThe Official VB6 vs VB.NET Thread HardCode is offline
Ultimate Contributor

Forum Leader
* Expert *
 
Join Date: Feb 2004
Location: New Jersey
Posts: 3,339
Default

Quote:
Originally Posted by Mike_R
VB6 is not going away, ...
Until Microsoft pulls COM out of their OS But then you could always keep on 98/2000/XP/Longhorn, until Microsoft pulls security patch support for those ...

It's up to the Computer Gods in Redmond really. But this is something that will have to be considered in the choice to upgrade or not, and probably sooner than later (i.e. 5 years out.)
__________________
DON'T CLICK HERE

Useful forum tags: [VB][/VB], [CODE][/CODE], [HTML][/HTML]
Reply With Quote
  #47  
Old 02-25-2005, 05:24 PM
Mike Rosenblum's Avatar
Mike Rosenblum Mike Rosenblum is offline
Microsoft Excel MVP

Forum Leader
* Guru *
 
Join Date: Jul 2003
Location: New York, NY, USA
Posts: 7,848
Default

Hey Jonathan,

Ok, HardCode is right... VB6 may go away with the next version of Windows, which is to be on the .Net Platform... But with backwards compatibility/legacy issues, I dunno, I would still think that legacy programs (aka COM) would have to be viable on the next OS release? But maybe not... Eventually it won't though, this is for certain!

Ok, "OOP" simply means Object-Oriented Programming, which really just means that you use Classes and Objects (where Objects are just Instances of Classes) instead of procedural code. If you use Modules only, then you are not using OOP. If you use Classes then you are. It really is that simple. For what it's worth, Forms are a Class, technically, but since they are automatically instantiated by VB6, they don't "feel" very OO when you use them.

So what's an "Object"? An Object contains both procedures and data. This is unusual if you think about it... Procedural code has Functions & Subs that return results according to the inputs given. But with a Sub or Function in a Class, that routine can act on the (1) Inputs given, but also (2) Data held in the class itself. The data held by the Object can be viewed as a sort of "hidden argument" that does not need to be explicitly passed.

This is OOP. Classes & Objects. That's it. Or at least, that's where it starts... From there it goes into Interfaces/Implements as well as Inheritance and Casting. The top of this heap is Generics, which isn't even in the current versions of .Net, but will be in the next. (Don't worry about these terms...)


Quote:
Originally Posted by JonathanEngr
As I learn more I'm simply going back and "simplifying" my programs by making the code more complex!
LOL, in a nutshell, this is OOP. My god, .Net is complicated, I mean it is completely overwrought... And yet it makes things so much nicer. It's hard to explain. Let's just say that once you are hooked, there is no going back...

You are actually in very good shape to move forward. I don't know John Smiley's books, but if you are just "zipping through it" then you are in very good shape. I would just make sure that you master Interfaces and the Implements keyword before moving on. The Objects book you are reading almost certainly must have a chapter on Interface-based Callbacks. (Look it up in the Ch. summaries in the front or in the glossery in the back.) Learn this inside out and backwards. It sounds like you might understand this already, but if not make sure you've got it down. And once you've got this learned, you've really hit the "end" as far as VB 6.0's OOP capability.

When you move to .Net, you'll find the OOP stuff fascinating. Interfaces and Implements comes alive with Inheritance, which can be thought of as an Interface plus a default implementation. That is, an Interface always needs the Class to provide an implementation, or it doesn't really do anything. But a Class Inheriting another Class gains an Interface that is already implemented! You can override parts that you want to, or leave the default functionality, it's up to you...

What makes .Net difficult is that the .Net Framework is vast. There is a ton to learn. All the basics that you know how to do with VB6 like File I/O, or converting Integers to Strings (or vice versa) will all have to be re-learned. All the simple stuff. It all has to be re-learned. It's pretty intensive, bordering on overwhelming.

Honestly, I think you're about done with VB6. I would skip right to the chapter(s) on Interfaces, the Implements keyword and Callbacks. (Post in the General forum if you have Q's.) Once you've got that behind you, give the VB6 books a rest. You're done.

On the other hand you'll have no need for VB.Net for a very long time, really. It sounds like you are a VBA/VB6 guy. VBA in particular is pretty tough with .Net. But the future is coming, so, I would get a good VB.Net book and read it over time... Download that 2005 Beta if you want to kick around some experimental code... The good news is you'll have all the time in the world before you'll "need" it, but I think after about 100 pages of your .Net book, you'll suddenly start to "want it".

Then you can come back here and yell at me for having given you a new addiction!

-- Mike
__________________
My Articles:
| Excel from .NET | Excel RibbonX using VBA | Excel from VB6 | CVErr in .NET | MVP |
Avatar by Lebb

Last edited by Mike Rosenblum; 02-25-2005 at 08:45 PM.
Reply With Quote
  #48  
Old 02-28-2005, 07:54 AM
JonathanEngr JonathanEngr is offline
Centurion
 
Join Date: Feb 2004
Location: North Carolina, USA
Posts: 117
Default

LOL! Thanks, Mike! And thanks again for such a detailed response. It's comforting to know I haven't spent the past several months learning an obsolete language, and even more comforting to know I'm not as pressed for time to switch over to .NET as I had imagined. I'm definitely going to take your advice, however, and purchase a good VB.NET book ASAP--any suggestions?

As for the VB6 books, I just started the one on "Objects"--it's third in the series. Right off the bat it defined OOP (if I had only waited to ask the question!), although the definition still hasn't quite "clicked" yet. There's one last book--Databases--from the VB6 series. Do you think it's even worth buying?

Lastly, I hope you aren't misunderstanding my skill level. I've read two books on VB and have written two small programs and a comprehensive spreadsheet incorporating VB6 code for the calcs, and that's about it. I've done the basic things such as numerous if...then, select case...end case, file i/o (single-line input from a text file), for...next, yada, yada, yada. I've done very little error handling (although it seems pretty straight-forward), and STILL have no clue why databases are all the rage. I mean--are they really different from what can be done in excel (let me guess--that's a pretty dumb question--right?).

As for a new addiction, I'm looking forward to it! However, it'll probably be my wife--not me--that blasts you for it! LOL!
Reply With Quote
  #49  
Old 02-28-2005, 09:41 AM
HardCode's Avatar
HardCodeThe Official VB6 vs VB.NET Thread HardCode is offline
Ultimate Contributor

Forum Leader
* Expert *
 
Join Date: Feb 2004
Location: New Jersey
Posts: 3,339
Default

Surprisingly, it seems that we have missed one of the most important reasons to make the switch to a .NET project, if the choice is yours ... skillset.

In today's day and age, it is not uncommon to be "downsized" on a Friday at 4:00 pm with zero notice. Pack it up and goodbye, and an escort out the building. That said, what are employers asking for? If you search some of the popular jobsites, there seems to be more .NET offerings than VB6 offerings, and most want a combination of both. While VB6 may suffice for a project, if you can make the decision to go with .NET for your own benefit, I would greatly recommend it. Companies aren't looking out for you, so you have to look out for yourself
__________________
DON'T CLICK HERE

Useful forum tags: [VB][/VB], [CODE][/CODE], [HTML][/HTML]
Reply With Quote
  #50  
Old 02-28-2005, 11:02 AM
Mike Rosenblum's Avatar
Mike Rosenblum Mike Rosenblum is offline
Microsoft Excel MVP

Forum Leader
* Guru *
 
Join Date: Jul 2003
Location: New York, NY, USA
Posts: 7,848
Default

Ok, I see... It sounds like you've almost mastered Procedural code at this point. You next need to learn about creating Classes & Objects.

Master Classes & Objects first before moving on... but the next step past Classes & Objects is to learn about Interfaces and how to use the 'Implements' keyword. The proof that you have mastered this "final frontier" in VB6 OOP would be to be able to effect an Interfaced-based Callback. (However, don't even think about doing this yet, you must first understand basic Classes & Objects first.)


Quote:
As for the VB6 books, I just started the one on "Objects"--it's third in the series. Right off the bat it defined OOP (if I had only waited to ask the question!), although the definition still hasn't quite "clicked" yet.
An Object is Data and Procedures held in the same place. That's it. Nothing more, nothing less. In VB6:
Code:
'Class Module Called 'ClassA': Private m_NumCalls As Long Public Function SumIt(Arg1 As Double, Arg2 As Double) As Double m_NumCalls = m_NumCalls + 1 ' <-- Used by the NumCalls() Function SumIt = Arg1 + Arg2 End Function Public Function NumCalls() As Long ' Reports the number of times that the SumIt() Function was called: NumCalls = m_NumCalls End Function
Ok, this is a silly little class... But what it does is that the SumIt() function returns the Sum of two variables. But this Class also holds data. Very little data in this case, but it does contain a private variable called 'm_NumCalls'. This variable holds the number of times the SumIt() function was called. And this value is returned via the NumCalls() Function. So let's now run the following code:
Code:
Dim oClassA As ClassA Set oClassA = New ClassA MsgBox oClassA.SumIt(1, 2) ' <-- Returns "3" MsgBox oClassA.SumIt(5, 5) ' <-- Returns "10" MsgBox oClassA.NumCalls ' <-- Returns "2"
What is "remarkable" here, if you think about it, is that the NumCalls Function can return a value without being passed any arguments at all. It has its own data, behind-the-scenes, within the Object itself.

By the way, for Functions that return (or set) a simple value, a Property is usually used, not a Function. That is, the NumCalls() Function above could be re-written as a Property as follows:
Code:
Public Property Get NumCalls() As Long NumCalls = m_NumCalls End Property
But you need to read your Objects Book regarding Classes, Objects, Properties, Methods. Then you'll move onto Events.


Quote:
There's one last book--Databases--from the VB6 series. Do you think it's even worth buying?... and STILL have no clue why databases are all the rage. I mean--are they really different from what can be done in excel (let me guess--that's a pretty dumb question--right?)
Probably not. Mostly I think that you are not quite ready for it. I'm a pretty hard-core Excel guy and I have yet to ever need Databasing. Databasing has huge value, but you really can go very far without it if Excel is your platform.

In as much as you do get into Databasing, I would just make sure that any book you buy is based on ADO and not on DAO, which is obsolete. But I really wouldn't buy a book at this stage. If you want a toe-hold into Databasing, then take a look at Excel's Query Tables and Pivot Tables. They both can/do use ADO to pull in their values.

[Edit: Learning Access, would be another "way in the door" to understanding basic databasing as well...]


Quote:
As for a new addiction, I'm looking forward to it! However, it'll probably be my wife--not me--that blasts you for it! LOL!
LOL, my condolences.
__________________
My Articles:
| Excel from .NET | Excel RibbonX using VBA | Excel from VB6 | CVErr in .NET | MVP |
Avatar by Lebb

Last edited by Mike Rosenblum; 02-28-2005 at 12:15 PM.
Reply With Quote
  #51  
Old 02-28-2005, 12:18 PM
JonathanEngr JonathanEngr is offline
Centurion
 
Join Date: Feb 2004
Location: North Carolina, USA
Posts: 117
Default

HardCode--you bring up a very good point, and something that most (if not all) programmers should take to heart. Fortunately for me I'm in somewhat of a slowly developing profession (Civil Engineering). Many of the calculations I perform haven't changed all that much in the past 50 or 100 years, with the exception, of course, of the methods used to determine these values (from slide rule to calculator to computer, etc). I guess I could always leave the programming to others--there are numerous software packages that do exactly what I want to do already on the market. But what fun would that be--especially when I just love to program (and as I said before, perhaps one days I'll aspire to create a Civil package of my own!). Thus, I'm not totally dependant on programming, but as I mentioned before, with my limited time to "educate" myself on a language I want to make sure I choose one that will serve me for years to come. If the whole idea of "Visual Basic" was going to be trashed by 2010, then I'd probably just need to shift to C++, etc.

Regarding Mike's post, the code really made a lot of sense. Essentially, the procedure has a sort-of duality to it... it does more than receive an input and deliver a single output--it's part of a "bigger picture", if you will, capable of holding data independant of the function that is called via the procedure. I'm very much lost in the lingo (Set oClassA = New ClassA), etc., but that seems to be more of an experienced-based problem than conceptual. I'm roughly 1/10th of the way through the book on VB6 Objects, so we're still covering definitions. I'm hoping the idea of OOP will become clearer and clearer as I move thorugh the book, but from what I've seen this is definitely a new concept to me. From the above code, it still seems procedural--just crafty and "optimized", if you will. Oh--one last thought. I saw somewhere that .NET integration in Office is somewhat difficult. Will this change in the future? I have Office 2003 and it still seems to be VB6 based.

I have to admit--just the discussion of .NET has got me going just a bit. I didn't see any suggestions on books, so if anyone would like to volunteer a good "beginner" text, feel free to pass it along.
Reply With Quote
  #52  
Old 02-28-2005, 04:02 PM
Mike Rosenblum's Avatar
Mike Rosenblum Mike Rosenblum is offline
Microsoft Excel MVP

Forum Leader
* Guru *
 
Join Date: Jul 2003
Location: New York, NY, USA
Posts: 7,848
Default

Quote:
Originally Posted by JonathanEngr
If the whole idea of "Visual Basic" was going to be trashed by 2010, then I'd probably just need to shift to C++, etc.
Your best bet would be to still learn VB6 as fully as possible before moving on. Once mastered you'd move to VB.Net. Since Office 2003 programming seems to be your "platform", using anything but VBA/VB6/VB.Net would not make any sense. You can use C++ to make COM applications for MS Office and you could use C# to use .Net with it, but they really don't work "as well" with MS Office as does VBA/VB6/VB.Net.

The truth is that VBA is still MS Office's native platform and it remains the easiest mechanism to control it. However, learning VB6 skills, esp. as far as OOP is concerned ,is still 100% usable within VBA. (That is, VB6 and VBA are, in fact, the same language.) VB.Net, to be honest, just makes things a little harder for controlling MS Office, but, like I said, once you're hooked there is no going back...

If you're interested, here are two tutorials on controlling MS Excel from VB6 and from VB.Net, respectively:

(1) Automating Excel from VB 6.0 Tutorial
(2) Automating Office Programs with VB.Net / COM Interop


Quote:
I saw somewhere that .NET integration in Office is somewhat difficult. Will this change in the future? I have Office 2003 and it still seems to be VB6 based.
Yes, .Net and MS Office don't work so great together to be honest. But it's not so bad with Office 2003, but still VBA is still easier here, I'd have to admit. .Net is harder with Office 2002 -- but doable. For 2000 and below it's not really recommended, although still doable if one is really determined.

I like .Net so much that I'm willing to work with it even though the truth is that using VBA is actually easier. I also only use Office 2003, so using .Net is less of a problem. Visual Studio Tools 2005 (which is not yet released) should hopefully really change this, however. If it comes out as well "as advertised" then you could really think of it as "VBA.Net". It looks way-cool. But we're not quite there yet...


Quote:
Regarding Mike's post, the code really made a lot of sense. Essentially, the procedure has a sort-of duality to it... it does more than receive an input and deliver a single output--it's part of a "bigger picture", if you will, capable of holding data independant of the function that is called via the procedure.
Yes, that is exactly the point.



Quote:
From the above code, it still seems procedural--just crafty and "optimized", if you will.
Fair enough. I could have put that code in a Standard Module as well, and then it would not have been "OOP" at all. But we didn't. We put it within a Class Module, and that makes all the difference.

The key resides within the call to the 'New' keyword. This is where all the magic happens, which we'll discuss next...


Quote:
I'm very much lost in the lingo (Set oClassA = New ClassA), etc., but that seems to be more of an experienced-based problem than conceptual.
Yes, you'er instincts are correct, it's not a big deal. You're also more familiar with this than you might think... For example, let's take something like the following in Excel:
Code:
Dim rng As Excel.Range MsgBox TypeName(rng) ' <-- Returns "Nothing" Set rng = ActiveSheet.Range("A1") MsgBox TypeName(rng) ' <-- Returns "Range" rng.Value = 100 MsgBox rng.Value ' <-- Returns 100
Don't look now, but that's OOP. Using this Dot-methodology, ActiveSheet.Range ("ActiveSheet Dot Range") type thing is what this is all about. If you make your own classes then you can do the same thing.

Let's swing back to that 'Class ClassA' example again. Now we'll call it a little differently and maybe now you'll see that this is no longer "just procedural":
Code:
Dim obj1 As ClassA Dim obj2 As ClassA MsgBox TypeName(obj1) ' <-- Returns "Nothing" MsgBox TypeName(obj2) ' <-- Returns "Nothing" Set obj1 = New ClassA Set obj2 = New ClassA MsgBox TypeName(obj1) ' <-- Returns "ClassA" MsgBox TypeName(obj2) ' <-- Returns "ClassA" MsgBox obj1.SumIt(1, 2) ' <-- Obj 1 MsgBox obj1.SumIt(5, 5) ' <-- Obj 1 MsgBox obj2.SumIt(10,20) ' <-- Note: Obj 2 here. MsgBox obj1.NumCalls ' <-- Returns "2" MsgBox obj2.NamCalls ' <-- Returns "1"
So 'obj1' was called twice and 'obj2' was called only once. And each object knows that. They each hold their own data -- it's no longer globally held for the entire Project to see. (Lingo: this is called "Encapsulation".) Each Object holds it's own private data that only it can see. It then chooses to expose what values it wishes via Functions and Properties.

The magic happens here:
Code:
Set obj1 = New ClassA
At this point a New ClassA Object has been allocated in memory and a reference to it (a pointer) has been placed in the 'obj1' variable. This Object only holds one value ('m_NumCalls As Long'), but it could potentially hold a whole suite of data. To reference this data, one theoretically could call obj1.m_NumCalls directly... However, we intentionally declared this variable's Scope as 'Private'. (See Post #50, above.) This way the Caller cannot access this variable directly. Instead the Caller would have to utilize oObj1.NumCalls(), which we exposed with a 'Public' scope.

But the important point is not whether m_NumCalls is Private or not... but that it exists at all. The key is that these two different values:
Code:
obj1.m_NumCalls obj2.m_NumCalls
reside in two different places in memory. Therefore, each object is maintaining it's own count. That's the magic.



Quote:
I'm roughly 1/10th of the way through the book on VB6 Objects, so we're still covering definitions. I'm hoping the idea of OOP will become clearer and clearer as I move through the book, but from what I've seen this is definitely a new concept to me.
After about five chapters you'll be humming...



Quote:
I have to admit--just the discussion of .NET has got me going just a bit. I didn't see any suggestions on books, so if anyone would like to volunteer a good "beginner" text, feel free to pass it along.
You're not ready yet, honest. Finish learning in VB6: Classes & Objects, Properties & Methods, Events and then, finally, Interfaces and the 'Implements' keyword. Once you've mastered an Interface-based Callback you are ready to move on. (And if you have not, then you are not...)

I shudder to even advise a book because I think you really, really, really need to finish the VB6 OOP skills first... But "The Visual Basic .NET Programming Language" by Paul Vick is probably a good book for your level.
__________________
My Articles:
| Excel from .NET | Excel RibbonX using VBA | Excel from VB6 | CVErr in .NET | MVP |
Avatar by Lebb

Last edited by Mike Rosenblum; 02-28-2005 at 07:43 PM.
Reply With Quote
  #53  
Old 02-28-2005, 07:38 PM
Mike Rosenblum's Avatar
Mike Rosenblum Mike Rosenblum is offline
Microsoft Excel MVP

Forum Leader
* Guru *
 
Join Date: Jul 2003
Location: New York, NY, USA
Posts: 7,848
Default

Addendum:

Ok, you know what... I just had a flip through Paul Vick's book again. I think it really is excellent for someone with no OOP experience. He does a great job for someone at your level. I would get the book.

I still think you'd want to read at least 4-5 chapters of your "Objects" book, but you should be able to pick up Paul Vick's book and read it straight-away as well. Download the free VB.Net 2005 Express Beta if you want to be able to kick around some code...

,
Mike
__________________
My Articles:
| Excel from .NET | Excel RibbonX using VBA | Excel from VB6 | CVErr in .NET | MVP |
Avatar by Lebb
Reply With Quote
  #54  
Old 03-01-2005, 10:11 AM
JonathanEngr JonathanEngr is offline
Centurion
 
Join Date: Feb 2004
Location: North Carolina, USA
Posts: 117
Default

Yup--the "Class" objects in your code are a bit unfamiliar since I'm not quite there in the Objects book. However, this stuff is *amazing* from what I've seen thus-far. The ability to interact with the "behind the scenes" code in VB has already opened a whole new work to me. I had no idea I could do the things that now can simply be done in a couple of lines of code. I know people blast MS fairly often, but hats off to those guys who actually create VB. OOP is beginning to come to light for me, and the advantages are tremendous. I'm into the section where they descibe "classes" as the cookie dough and "objects" as the cookies created from them (and later on where the "cookies" can be virtually any type all lumped together). This just sets the stage for creating classes of objects from which you can declare an object as a variable (from specific like "msgbox", to more general like "object" to the unlimited "variant"). Oh my how this will enable so many things I didn't think possible--at least without tons and tons of messy code. You've also got me really, really curious about this "implement" command. I'm wanting to cheat and check the index to see if this text even covers it since it's a book for beginners. I'm trying to keep it slow, however, since I've really not done any coding with the newer topics covered in the book (I just don't have time at work to fire up VB to play with it, and with a 16-mo old daughter and son on the way at the end of this month I'm just a *little* busy at home! LOL!). It's all I can do to sneak away and read a few chapters, and you're right--I'm getting hooked. It's like discovering the Galapagos Islands.

I do hate that VB.Net isn't quite as compatible with Office, etc., but it sounds like the direction they took with VB.Net it was sort-of an inevitable result. I'm still trying to piece together functionality of VB with Excel. All I've done at this point was write custom functions to perform iterative calculations where the function calls on cells for the input data. This has already opened up a whole new functionality to me as far as excel goes, and I think this is what's causing me to get excited about OOP. It just blows my mind that *I* can actually write programs with this type of functionality... it's just something I had "accepted" was impossible for all but the savviest of programmers with a formal software engineering degree and years of experience. It's a bit scary to think of what someone with those qualifications could do....

Thanks for all the examples you list on this page, and I think it really, really explains the real reason for switching to VB.Net very well, as well as the best approach to get there based on previous experience. Also, thank you for the book recommendation. That's a tough call to make--so few books are "well-rounded", and inevitably a book that seems complete and thorough to one person will be lacking in many fundamentals to someone else. I just needed a good place to start, and I'll pick it up ASAP and jump into right after I complete the objects book.

I'm going to jet and download the beta of VB.Net interface. Ahhhh... that throws another cog in the wheel. When searching for an answer to the VB6 vs VB.Net I saw many, many posts about VB,Net being free--it's the interface that costs $$. There are supposedly some free interfaces out there as well as betas, I assume, but most people said VS (Visual Studio) was just the way to go--any other interface was just too difficult. If the basic code is the same regardless, why the difference? Does Visual Studio come with a large complement of objects, etc.? Complete online help manuals? When I bought Visual Basic it was just what it said--Visual Basic 6.0. Was there a Visual Studio for VB6, or was that included in the VB6 package? And what exactly *is* the difference between the $100 "standard" VS package versus the (I think it;s called) $500 Enterprise Edition? Again--just more pre-designed objects?
Reply With Quote
  #55  
Old 03-01-2005, 11:30 AM
Mike Rosenblum's Avatar
Mike Rosenblum Mike Rosenblum is offline
Microsoft Excel MVP

Forum Leader
* Guru *
 
Join Date: Jul 2003
Location: New York, NY, USA
Posts: 7,848
Default

Quote:
Originally Posted by JonathanEngr
However, this stuff is *amazing* from what I've seen thus-far. The ability to interact with the "behind the scenes" code in VB has already opened a whole new work to me.
Yes, this was my first impression as well. As a VBA guy I didn't realize we could make our own classes and do all this "Object Dot Method" stuff for our own code. It's incredibly cool when you realize that you can.


Quote:
I had no idea I could do the things that now can simply be done in a couple of lines of code. I know people blast MS fairly often, but hats off to those guys who actually create VB.
I'm a huge MSFT fan. I think it's hard to be a VBA guy and not be.


Quote:
I'm into the section where they describe "classes" as the cookie dough and "objects" as the cookies created from them (and later on where the "cookies" can be virtually any type all lumped together).
Hmmm.... You'd be better off thinking of a Class as a "Cookie Cutter", that is a blueprint or design. The cookies are the objects made from them. Ah, heck, you're a civil engineer, right? Classes are blueprints, period. Objects (houses, bridges, whatever) are made based on the Class ("blueprint") design. So you could make an entire row of houses from the same blueprint. But different people will be living in each house.

In my example above, I made two different objects called 'ob1' and 'obj2' both made from the same 'ClassA' "blueprint". But the data ("people") residing in each are still different, unique.

Ok, that's enough analogies!


Quote:
This just sets the stage for creating classes of objects from which you can declare an object as a variable (from specific like "msgbox", to more general like "object" to the unlimited "variant").
An Object Type is a generic container for all Reference Types. A Reference Type is something that is created from a Class "blueprint" using the 'New' keyword. A Value Type (a non-Reference Type) would be a built-in data type like Integer, Long, etc, or a Structure/UserDefinedType.

A Variant, on the other-hand, is a VBA/VB6 invention that is quite "useful" but it ultimately an ugly beast and creates bad coding practices. Learn a bit about it, it's hard to avoid completely, but in your own code, avoid it like the plague. I don't think I ever use Variants anywhere in my code. You may be forced occasionally to use them when dealing with Arrays in Excel, but that's it. Stay way.

This concept was abolished in .Net as well.


Quote:
OOP is beginning to come to light for me, and the advantages are tremendous...Oh my how this will enable so many things I didn't think possible--at least without tons and tons of messy code.
Yes, it is definitely exciting stuff, and it really expands your mind... However, be warned: in the near term (and I mean for up to a year) it will slow you down, and make programming harder, not easier. I cannot tell you how much effort I have put into learning OOP and then .Net and I still don't *quite* have the ability to do what can be done easily in VBA. This is not because ".Net doesn’t work well with MS Office" but really more a statement that "OOP is hard". But it’s way cool, don’t hold back.

Some of the mistakes I've made in OOP (and still make) is creating over-wrought object models that ultimately become difficult for the User (me!) to even understand, let alone maintain. I have built, torn-down, re-built, re-torn-down, etc. the same things over and over so many times I cannot even tell you. (Clearly I need to be put on meds or something! ) LOL. Just be warned, it will take a while to master this stuff and actually be able to *use* it effectively in a work setting.

In particular, I'm a VBA Worksheet Function kind-of-guy (just like you are). And there is just very little use for OOP in all that. The Worksheet Function is passed a set of Arguments, and the WSF produces a result. Period.

I wouldn't let it hold you back... but, well, just be aware! And you sound very busy with your new family.


Quote:
You've also got me really, really curious about this "implement" command. I'm wanting to cheat and check the index to see if this text even covers it since it's a book for beginners.
If it doesn't, no worries... just learn about Objects, Classes, Properties, Methods and Events. That's enough. Once you've got that, then you can PM me or post here, or post a Q on the General Forum about Interfaces and the Implements keyword.


Quote:
I do hate that VB.Net isn't quite as compatible with Office, etc., but it sounds like the direction they took with VB.Net it was sort-of an inevitable result.
Once you really understand .Net, you realize that it's really "not their fault". And MS Office will eventually be ported 100% to .Net. And if you stick to Office 2003, then it really is pretty ok. Still, there's nothing like good ol' VBA to get stuff done efficiently!


Quote:
Also, thank you for the book recommendation. That's a tough call to make--so few books are "well-rounded", and inevitably a book that seems complete and thorough to one person will be lacking in many fundamentals to someone else. I just needed a good place to start, and I'll pick it up ASAP and jump into right after I complete the objects book.
Yes the Paul Vic book is a little "light" for a lot of programmers I think. But skimming through it today, I see that it really is an excellent book for your level. I think you'll like it a lot.


Quote:
I'm going to jet and download the beta of VB.Net interface. Ahhhh... that throws another cog in the wheel. When searching for an answer to the VB6 vs VB.Net I saw many, many posts about VB,Net being free--it's the interface that costs $$.
To me this is like arguing that "the highways are free... all you need is a car!" LOL.

You can program on a simple Notepad.exe if you want to... but I think that that is just insane. You need an IDE, period. Actually, the VB.Net IDE is the single biggest reason that I love .Net so much. The language is very nice too... but the IDE is just phenomenal.

Get the free 2005 Beta and don't spend a dime on the 2003 version, honest. And the difference between the $100 2003 Standard and the $500 2003 Professional version -- for your purposes -- is essentially zero. There are a few templates lacking in the cheaper package (and in the Beta). If you need to create a certain type of library not natively provided, you can get around this easily. Just post in the .Net General Forum if you have a Q on this or send me a PM...


Quote:
When I bought Visual Basic it was just what it said--Visual Basic 6.0. Was there a Visual Studio for VB6, or was that included in the VB6 package?
This dichotomy always existed. There was VB 6.0 and then Visual Studio 6.0 (for like $1,000 originally) that included VB 6.0, C++, J++, etc. all in one package. I have the full Visual Studio 6.0 suite and have never used anything but the VB 6.0 part. But I got it on eBay and the price was the same as the VB 6.0 stand-alone so I said "what the heck". But I never used any of it.

Just kick around the VB.Net 2005 Beta. By the time you get past this level (and that will be a long time) this beta would be in full release by then and you can think about plunking down $100 or so for a "real" copy.
__________________
My Articles:
| Excel from .NET | Excel RibbonX using VBA | Excel from VB6 | CVErr in .NET | MVP |
Avatar by Lebb

Last edited by Mike Rosenblum; 03-01-2005 at 01:37 PM.
Reply With Quote
  #56  
Old 03-17-2005, 06:14 PM
Gamost Gamost is offline
Privileges Suspended
 
Join Date: Feb 2005
Posts: 62
Default

I heard that you do NOT have to declare API's in .net...is this true?
Reply With Quote
  #57  
Old 03-17-2005, 06:53 PM
reboot's Avatar
rebootThe Official VB6 vs VB.NET Thread reboot is offline
Keeper of foo

Retired Moderator
* Guru *
 
Join Date: Nov 2001
Location: Graceland
Posts: 15,614
Default

No... you don't have to use them as much though.
__________________
~ Quod non mortiferum, fortiorem me facit ~

Avatar by lebb
Reply With Quote
  #58  
Old 03-17-2005, 07:13 PM
MikeJ's Avatar
MikeJThe Official VB6 vs VB.NET Thread MikeJ is offline
Retread

Retired Moderator
* Expert *
 
Join Date: Sep 2002
Location: Austin, Texas
Posts: 6,747
Default

To clarify, .NET put a lot of the more 'popular' API's in namespaces, which means that you don't need to use their Win32 counterparts. (Such as GDI32 v. System.Drawing, Sockets API v. System.Net.Sockets, etc.)
__________________
{ Lex Fori } { Locus Classicus } { Rutilus Scrinium }
Osculare pultem meam!
Reply With Quote
  #59  
Old 03-27-2005, 03:00 AM
brandnew's Avatar
brandnew brandnew is offline
Centurion
 
Join Date: Jun 2004
Location: Phnom Penh, Cambodia.
Posts: 181
Default

VB6 vs VB.net? I got two equations.

VB6 = Visual Basic Syntax + APIs
VB.net = Visual Basic Syntax + .Net Framework

Explanation: If you use VB6, do take as many as advantages from APIs, but if you use VB.net, do take as many as advantages from .Net Framework.
__________________
Very useful and free stuffs for VB programmers.
API-Guide - Wonderful API viewer with examples and full explanation.
APIViewer - More APIs; replacement for default api viewer in VB.
Reply With Quote
  #60  
Old 03-27-2005, 09:48 AM
John's Avatar
John John is offline
Bit Flipper
 
Join Date: Feb 2002
Location: The Inner Loop
Posts: 5,550
Default

VB.net = Visual Basic Syntax + full object orientation + .Net Framework + asp.net support + you can still use APIs ++++++
__________________
Subclassing|Magnetic Forms|Operator Overloading (VB2K5)|QuickSnip.NET

"These Patriot playoff wins are like Ray Charles songs, Nantucket sunsets, and hot fudge sundaes. Each one is better than the last." - Dan Shaughnessy
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

Advertisement:





Free Publications
The ASP.NET 2.0 Anthology
101 Essential Tips, Tricks & Hacks - Free 156 Page Preview. Learn the most practical features and best approaches for ASP.NET.
subscribe
Programmers Heaven C# School Book -Free 338 Page eBook
The Programmers Heaven C# School book covers the .NET framework and the C# language.
subscribe
Build Your Own ASP.NET 3.5 Web Site Using C# & VB, 3rd Edition - Free 219 Page Preview!
This comprehensive step-by-step guide will help get your database-driven ASP.NET web site up and running in no time..
subscribe
The Official VB6 vs VB.NET Thread
The Official VB6 vs VB.NET Thread
The Official VB6 vs VB.NET Thread The Official VB6 vs VB.NET Thread
The Official VB6 vs VB.NET Thread
The Official VB6 vs VB.NET Thread
The Official VB6 vs VB.NET Thread The Official VB6 vs VB.NET Thread The Official VB6 vs VB.NET Thread The Official VB6 vs VB.NET Thread The Official VB6 vs VB.NET Thread The Official VB6 vs VB.NET Thread The Official VB6 vs VB.NET Thread
The Official VB6 vs VB.NET Thread
The Official VB6 vs VB.NET Thread
 
The Official VB6 vs VB.NET Thread
The Official VB6 vs VB.NET Thread
 
-->