Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
VB6 or VB.Net 1
- Thread starter CPUCurt
- Start date
Call it what you want, finding that DataGrid1.Refresh exists but doesn't do anything then having to write this...
Private Sub RefreshCombo()
Dim DEInstance1 As AllDataDesigner
Set DEInstance1 = New AllDataDesigner
DEInstance1.Commands("cmdDR").Execute
Set DataGrid1.DataSource = DEInstance1
DataGrid1.Refresh
End Sub
...to fix it, is an issue/bug/pain in backside/whatever!
Private Sub RefreshCombo()
Dim DEInstance1 As AllDataDesigner
Set DEInstance1 = New AllDataDesigner
DEInstance1.Commands("cmdDR").Execute
Set DataGrid1.DataSource = DEInstance1
DataGrid1.Refresh
End Sub
...to fix it, is an issue/bug/pain in backside/whatever!
Hey, I got co-workers next door to me that program in .Net and they scream just as loudly as I and I only program in VB6. Actually sometimes they're louder. But thanks for the tip about the book, I am suppose to be advancing toward the .Net world.
- Thread starter
- #28
Well, again. You could try reading around in this book:
The reason I suggested it in the first place is because it gives you exactly what you are asking for.
HTH
Bob
The reason I suggested it in the first place is because it gives you exactly what you are asking for.
HTH
Bob
Hmm... someone wants a list of bugs, huh? Well, I suppose that depends on what your definition of a bug is.
If you define a bug as being something that, according to the documentation and specification, the product ought to do, but it does not, then none of these are really bugs.
However, what they are is major shortcomings that seriously handicap VB as a programming language. Many (though not all) of these are fixed by VB.Net.
No support for pointers. Pointers are used "under the hood", but the developer has no control over them at all.
Lack of short-circuting in boolean evaluations. This makes for often ugly code.
An imitation of object orientation, without support for many important elements. For example, there is no inheritance or polymorphism, nor is there support for static members.
Use of non-COM DLLs (most standard DLLs) is severely handicapped. VB does not support function pointers which are often integral to many DLLs, and VB cannot load a DLL dynamically. It must be linked at compile-time. This means that a non-COM based plug-in architecture is completely unavailable to VB.
Strings can only be manipulated through functions like Mid and Left. One cannot iterate thorugh a string's characters and operate on them.
No character data type. A character is considered a string of length 1.
I could go on, but my fingers are getting tired.
If you define a bug as being something that, according to the documentation and specification, the product ought to do, but it does not, then none of these are really bugs.
However, what they are is major shortcomings that seriously handicap VB as a programming language. Many (though not all) of these are fixed by VB.Net.
No support for pointers. Pointers are used "under the hood", but the developer has no control over them at all.
Lack of short-circuting in boolean evaluations. This makes for often ugly code.
An imitation of object orientation, without support for many important elements. For example, there is no inheritance or polymorphism, nor is there support for static members.
Use of non-COM DLLs (most standard DLLs) is severely handicapped. VB does not support function pointers which are often integral to many DLLs, and VB cannot load a DLL dynamically. It must be linked at compile-time. This means that a non-COM based plug-in architecture is completely unavailable to VB.
Strings can only be manipulated through functions like Mid and Left. One cannot iterate thorugh a string's characters and operate on them.
No character data type. A character is considered a string of length 1.
I could go on, but my fingers are getting tired.
Ah, a troll ...
Almost all of those 'shortcomings' sound exactly the same as the criticisms aimed at VB by C programmers in the old "my programming language is better than your programming language" wars that I thought we'd got way beyond. Most are not shortcomings, just differences.
VB was originally designed to hide many of the complexities of older langauages such as see from the programmer, leading to rapid application development. One wouldn't select VB if one wanted screaming speed, or to get closer to the hardware.
But, just for fun, let's look at some of that list
No support for pointers: Oh yes it does - although not as flexibly at C/C++; objptr, strptr and varptr for a start ...
VB does not support function pointers : oh yes it does.
VB cannot load a DLL dynamically: VB can work quite happily with LoadLibrary
Strings can only be manipulated: only partially true. VB strings are really arrays, and we can iterate through arrays if we really need to
No character data type: er, so?
Almost all of those 'shortcomings' sound exactly the same as the criticisms aimed at VB by C programmers in the old "my programming language is better than your programming language" wars that I thought we'd got way beyond. Most are not shortcomings, just differences.
VB was originally designed to hide many of the complexities of older langauages such as see from the programmer, leading to rapid application development. One wouldn't select VB if one wanted screaming speed, or to get closer to the hardware.
But, just for fun, let's look at some of that list
No support for pointers: Oh yes it does - although not as flexibly at C/C++; objptr, strptr and varptr for a start ...
VB does not support function pointers : oh yes it does.
VB cannot load a DLL dynamically: VB can work quite happily with LoadLibrary
Strings can only be manipulated: only partially true. VB strings are really arrays, and we can iterate through arrays if we really need to
No character data type: er, so?
You sound like another java lover. 
So, handicapped, huh? Well, I suppose that depends on your definition of "handicap." Assumption: there exists a set of applications, meaning potential uses of the set of programming languages. A handicap I would define as a feature or lack of a feature that reduces the set of applications in the set of all the applications that can be created by any programming language. As such, one could easily argue that the flatter learning curve and slower development time of more "feature rich" "lower level" languages is a handicap, too.
There is inheritance, sort of. Microsoft says that VB supports "interface inheritance" but not "implementation inheritance". Yes, that's pretty much spin doctoring.
However, the case for polymorphism is much stronger. The following code creates a Flea and a TRex implementation of and iAnimal interface, and they will behave differently when their methods are called. This is polymorphism, Q. E. D.
The one limitation is that a given class instance cannot access more than one interface, even though the class itself may implement multiple interfaces. In the above code, note that the variable is declared as the interface, not as its implementation. As such, if TRex implemented iAnimal2, its methods wouldn't be available to the y variable above.
Finally, one can get most of the functionality of a static member by declaring a global variable and accessing it through a property.
So, I would say that VB has fairly significant OO support. Calling it an "imitation of OO", as if dot notation were the only aspect of OO that VB supports, is a bit harsh.
So, I don't agree with your second statement as written.
So worlebird, as far as I'm concerned, you haven't backed up your point of view that these limitations represent handicaps. There are plenty of times when VB makes perfect sense as a development tool, especially in medium performance/fast development time scenarios. Whatever lack of features it may have aren't needed anyway, so why is lacking them a handicap?
I could go on, but I need one hand for my cup of coffee.
Friendlily yours,
Bob
So, handicapped, huh? Well, I suppose that depends on your definition of "handicap." Assumption: there exists a set of applications, meaning potential uses of the set of programming languages. A handicap I would define as a feature or lack of a feature that reduces the set of applications in the set of all the applications that can be created by any programming language. As such, one could easily argue that the flatter learning curve and slower development time of more "feature rich" "lower level" languages is a handicap, too.
And this is a handicap precisely why? Why isn't like saying that an automatic shift is a handicap, because it doesn't allow the driver to switch gears directly? That's probably true at 200 kph in the left lane of the Autobahn, but it's probably an actual benefit in stop/go traffic on i405 or the Dan Ryan.
And ugliness is a handicap? My mother always said it wasn't...
There is inheritance, sort of. Microsoft says that VB supports "interface inheritance" but not "implementation inheritance". Yes, that's pretty much spin doctoring.
However, the case for polymorphism is much stronger. The following code creates a Flea and a TRex implementation of and iAnimal interface, and they will behave differently when their methods are called. This is polymorphism, Q. E. D.
Code:
'a Public class called iAnimal
Public Sub Move()
End Sub
Public Sub Bite()
End Sub
'Now, a class called Flea, set to PublicNotCreateable
Implements iAnimal
Private Sub iAnimal_Move
msgbox "boing boing"
End sub
Private Sub iAnimal_Bite
msgbox "nip"
End Sub
'And a class called TRex, also PublicNotCreateable
Implements iAnimal
Private Sub iAnimal_Move
msgbox "KABOOOMMMM....KABOOOMMMM...."
End sub
Private Sub iAnimal_Bite
msgbox "CRRRUUNNNNCCCHHHH"
End Sub
'Now, a client
Public Sub cmdAnimal_Click()
dim x as iAnimal
dim y as iAnimal
set x = new Flea
set y = new TRex
x.move
x.bite
y.move
y.bite
End SubFinally, one can get most of the functionality of a static member by declaring a global variable and accessing it through a property.
So, I would say that VB has fairly significant OO support. Calling it an "imitation of OO", as if dot notation were the only aspect of OO that VB supports, is a bit harsh.
All the same, maybe all the DLL functionality needed for the great majority of applications is available to VB. So, again, it's hard for me to accept that this is a handicap.
Well, as the following code demonstrates, one can use Mid to iterate through a string's characters, and can operate on them any way one wants:
Code:
dim x as string
dim i as integer
x = "abcdefgh"
for i = 1 to len(x)
'Happily iterating away, character by character
msgbox "Currently on character " & i & " whose value is " & mid(x, i, 1)
NextAnd again, this is a handicap (a severe one even) precisely why?
So worlebird, as far as I'm concerned, you haven't backed up your point of view that these limitations represent handicaps. There are plenty of times when VB makes perfect sense as a development tool, especially in medium performance/fast development time scenarios. Whatever lack of features it may have aren't needed anyway, so why is lacking them a handicap?
I could go on, but I need one hand for my cup of coffee.
Friendlily yours,
Bob
worlebird,
If you want to go pointers in .NET you'll have to go unmanaged C# or C++, VB.NET won't help you there either...
This is only partly solved in VB.NET; statements like IIF, Switch etc. still can get you into trouble.
Although VB.NET does more than VB6 in this area, imo, it still lacks a couple of things to be considered a truly OO language, like for example operator overloading and multiple inheritance.
Have you actually ever programmed in VB6? Because if you had; you would have noticed not having problems accessing exported functions in a non-COM dll....
See BobRode's comment on this. And this is exactly the way you would do this in VB.NET, unless you first convert the string to an array of characters.
Wrong: a character in VB.NET can not be considered a string of length 1; you can't even assign a single string cahracter to a char data value if you've got option strict on:
Dim c As Char
c = "d"
Although "d" could be considered a string of length 1, you can not assign this single character string to a character.
The same way you can't directly assign a char to a string type variable....
Greetings,
Rick
If you want to go pointers in .NET you'll have to go unmanaged C# or C++, VB.NET won't help you there either...
This is only partly solved in VB.NET; statements like IIF, Switch etc. still can get you into trouble.
Although VB.NET does more than VB6 in this area, imo, it still lacks a couple of things to be considered a truly OO language, like for example operator overloading and multiple inheritance.
Have you actually ever programmed in VB6? Because if you had; you would have noticed not having problems accessing exported functions in a non-COM dll....
See BobRode's comment on this. And this is exactly the way you would do this in VB.NET, unless you first convert the string to an array of characters.
Wrong: a character in VB.NET can not be considered a string of length 1; you can't even assign a single string cahracter to a char data value if you've got option strict on:
Dim c As Char
c = "d"
Although "d" could be considered a string of length 1, you can not assign this single character string to a character.
The same way you can't directly assign a char to a string type variable....
Greetings,
Rick
I'm not sure if I agree with your definition of "truly" OO, Rick. If multiple inheritance and operator overloading are requirements of same, then so be it. However, I don't see that operator overloading really makes for more concise code, in that you have to accompany it with many more lines of documentation to explain what you're doing to everyone than you save in doing it. Furthermore, the difficulties with multiple inheritance are well documented. Not that it should never be done, but it's hard to find a situation where it's absolutely necessary.
So, it seems reasonable to me to disallow these in a language without considering that a revocation of the full OO status of the language. Grey areas, in other words.
After all, one also could argue that C++ isn't truly OO because it doesn't require the use of the OO paradigm, couldn't one?
Bob
Well, the fact that a language does not require the oo paradigm, does not mean that it is not capable of doing oo.
You're right that multiple inheritance comes along with some difficulties. However, sometimes it can come quite handy if you can do multiple inheritance. It is never absolutely necessary, but then again... what is?
The operator overloading stuff is more regurarly used however, and I don't understand why they did put it into C# but they left it out in VB.NET??
Maybe my statement was a bit misformed; maybe it should have read that features are missing that are regularly used in other OO languages?
Greetings,
Rick
You're right that multiple inheritance comes along with some difficulties. However, sometimes it can come quite handy if you can do multiple inheritance. It is never absolutely necessary, but then again... what is?
The operator overloading stuff is more regurarly used however, and I don't understand why they did put it into C# but they left it out in VB.NET??
Maybe my statement was a bit misformed; maybe it should have read that features are missing that are regularly used in other OO languages?
Greetings,
Rick
It's not clear to me that multiple inheritance and operator overloading are "regularly" used anywhere. However, I'm sure that they do have their uses. I guess my point is that it's reasonable to disallow them in a fully OO language, and still consider it a fully OO language. That's not to say that it's unreasonable not to consider it as such, either. So, the question is largely academic.
Bob
Bob
Well, if it were, then it wouldn't be heretical to say that it wasn't.
Strongm, are you saying that the COM spec in and of itself causes inherent limits in any sort of OO implementation based on it? If so, you've made me curious. What part of COM creates what kind of limits? My understanding of the COM spec is that an object is COM compliant if 1) it can keep track of references to itself, and destroy itself when none exist and 2) it can provide a list of all the interfaces that it supports. In practical terms, it must implement the iUnknown interface. So, how do those requirements translate into OO limitations, or is my understanding of COM incomplete?
Bob
Strongm, are you saying that the COM spec in and of itself causes inherent limits in any sort of OO implementation based on it? If so, you've made me curious. What part of COM creates what kind of limits? My understanding of the COM spec is that an object is COM compliant if 1) it can keep track of references to itself, and destroy itself when none exist and 2) it can provide a list of all the interfaces that it supports. In practical terms, it must implement the iUnknown interface. So, how do those requirements translate into OO limitations, or is my understanding of COM incomplete?
Bob
- Status
Similar threads
- Locked
- Question
