VB6 or VB.Net 1

[CPUCurt]

I’m looking for solid references, both Pro and Con, for moving to VB.NET.

Any help or testimonials would be appreciated.

 

[LazyMe]

One of the things COM can't do is inherit functionality; it can only inherit (or rather: implement interfaces), hence the implementation in VB6.....

Greetings,
Rick

 

[bigtimmin]

Here’s some articles you can read to see an overview of some of the changes.

http://doc.advisor.com/doc/13041

http://visualbasic.about.com/od/imhoinmyhumbleopinion/ss/FiveChanges.htm

As a System Admin, I only used VB6 to automate my mundane repetitive tasks. Now my mundane tasks are written in dotNet. Barring the steep learning curve, I’m enjoying dotNet. Even if your bosses are still unable to justify the cost from a business standpoint now, at some time in the future they will. As an IT professional, you can put yourself in a position to maintain older technology or you can prepare yourself for the new. Bottom line, dotNet is here and Microsoft is not going back!

2 Cons: Learning curve and .Net frameworks needs to be on the computers.
Pros: Too many to list.

Maybe this world is another planet’s Hell.
Aldous Huxley

 

[bigtimmin]

Here's another good article

http://www.ondotnet.com/pub/a/dotnet/excerpt/vbnetnut_appa/index.html?page=1

Maybe this world is another planet’s Hell.
Aldous Huxley

 

[BobRodes]

I didn't know that the COM spec per se doesn't support the concept of inheritance. Does this mean that COM implementations created in C++ can't have inherited functionality? I'm not sure I see your point, Rick.

Thanks,

Bob

 

[LazyMe]

Well, the C++ classes you create can inherit everything you want, you can not, however, inherit the functionality of another COM object, nor can your COM implementation be inherited. You can, however, reuse the logic of another COM object inside your own COM object. There are different ways to do this, but none of them allows you to for example overload functions or really override them. To override them you would for example by your interface expose a method and inside the implementation of that method call the correct method on the interface of the reused COM object.

Short and sweet:
Every COM object has his set of interfaces which it implements. You can not change the implementation of a particular method on a particular interface, since your COM object will be called on methods of his own interfaces.

That more or less sounds like the way you would implement "inheritance" in VB6, doesn't it?

Greetings,
Rick

 

[strongm]

My work here is done ...

 

[BobRodes]

You can not change the implementation of a particular method on a particular interface

Maybe we're defining implementation differently? To me, implementation is what the method actually does, and you can change that all you want. Are you saying that you can't alter the definition of the method, i. e. its arguments, return values, name, order, etc? I know you can't do that in COM, and I guess that would make it difficult to overload a method, although I can think of ways that one might. But what is it in the COM spec that says you can't override a method? It's my understanding that the sole immutable requirement of any COM object is that it has to implement the iUnknown interface.

 

[LazyMe]

Maybe we're defining implementation differently? To me, implementation is what the method actually does

Yes and that's exactly what I meam; you can not inherit what the method actually does; you'll have to (re)do that yourself.

Furthermore; you cannot just change the implementation of an existing method on an existing COM object; these methods are not virtual. You'll create your own interface with the same method name and write code on that method. Your client will obtain a reference to that interface and call that method. If your client wants to call the method on some COM object that you embedded, it will first have to obtain a reference to that COM object's interface and call the method (or you would call that method from some method on your own interface).

Greetings,
Rick

 

[BobRodes]

Very funny strongm.

Rick, we seem to be having a semantic problem. To me, "change the implementation" means alter the underlying code in a method. In VB, I can set the binary compatibility flag, compile my dll, and deploy it. I can then go in and change the code, recompile my dll, and redeploy it. The application that was running the old dll will quite happily (well, is supposed to quite happily) work with it. Just to make sure my meaning is clear, if I have a GetMyDB method, and our company switches from SQL Server to Oracle, I can rewrite GetMyDB so that it connects to the latter. In so doing, I do not break my client application's ability to use the method.

So, what do you mean by "the implementation of an existing method" if that's not what you mean?

Bob

 

[BobRodes]

Ok, I reread your response. My question regarding your use of "change the implementation" still stands.

As for my original question, it has not been my understanding that the limitations you describe are COM limitations, but VB limitations. I've made my understanding of COM quite clear, feel free to correct it if you desire.

Thanks,

Bob

 

[strongm]

>we seem to be having a semantic problem.

Blame Microsoft. They use the word implement when talking about the COM interfaces. Generally they say that a COM object implements one or more interfaces. When they say 'implement' here they are not talking about actual code, but instead are simply referring to how the set of functions that make up the interface are exposed to the consumer.

For example, when we say that every COM object implements IUnknown what we are really saying is that when you obtain the IUnknown interface for the object you will be able to call (via pointers in a table) three functions: AddRef, Release, and QueryInterface. Those functions will always take the same parameters and return the same values, they will always appear in the same order in the interface's declaration and they will always perform exactly the same operations.

What COM doesn't specify is the actual code necessary to perform the functions, i.e. the code implementation

Basically, an interface is simply (but importantly) a contract - and the COM interface contract specifies:

Unique interface GUID
Order of functions in the interface
Parameters to each function
Return values of each function
Operation function performs

Change any one of the above, even just a bit, and you have a new, different interface.

An implementation of a COM interface (our contract) is simply an array of pointers to the functions (and, to reiterate, the actual implementation of the functions is not dictated or controlled by COM at all)

 

[chelseatech]

I've come in late to this discussion and it looks like you folks have got bogged down in comparing bugs in VB6 v VB.NET and haven't answered the original question.

I'm using both and have been for a while now.

I keep my original code in VB6 and use that with the other tools I work with that like COM. I like VB6 as a language.

VB.NET is a lot richer. I needed that because I decided it would be the easiest way to migrate one of my VB6 applications and run it as a Windows Service. Things like that, Web Services and Windows API stuff are a lot easier to develop in VB.NET

It is a steep learning curve. I've got over a dozen .NET books and for each new feature, I look through them for an hour or so and then write a couple of lines of code to invoke some prebuild class.

On the negative side is that older versions of Windows have problems with the .NET framework. If your users are still wondering if they should replace their Win 95 machines, then stay with VB6. If you are into Windows 2003 server then you already have the .NET framework waiting to help you.

Editor and Publisher of Crystal Clear

http://www.chelseatech.co.nz/pubs.htm

 

[fischadler]

Hello folks,
Most of the "bugs" that I thought VB6 had often ended up being due to the fact that I simply was not programing properly. But in a recent thread I started (thread222-1077839 answer dated 19 Jul 05 18:23) CubeE101 pointed out a problem where Refresh and Refresh2 methods of the WebBrowser control don't seem to work. Is it a bug or is just me mixing things up as usual?


-Fischadler

 

[LazyMe]

It's just mixing things up (dont' know if that's usual though....).

You see, you already stated yourself that it's a bug in the webbrowser control (haven't read the thread though...). If it is indeed a bug in the webbrowser control, then all program languages using that COM control would suffer the same problem; not just VB, so I wouldn't call this a VB related bug then, would you?

Greetings,
Rick

 

[BobRodes]

> and, to reiterate, the actual implementation of the functions is not dictated or controlled by COM at all.

Strongm, that's my understanding of COM as well. So, back to my original question in a different form: if COM doesn't dictate or control the implementation of the functions, what mechanism does it use to place limits on the OOP paradigm? It has been my understanding that white box reuse is transparent to the COM specification.

Ok, I did a little reading after I asked the above. Perhaps when you say that VB being based on COM represents a limitation to its OO capabilities it is because COM doesn't specifically support some of the OO concepts (while not disallowing them either), and that since VB was designed to support COM, it doesn't include the OO concepts that COM ignores.

For those who are interested, this paper is a comparison of CORBA and DCOM:

http://research.microsoft.com/~ymwang/papers/HTML/DCOMnCORBA/S.html

Bob

 

[strongm]

Yes, that's more-or-less it (although I'd point out, somewhat tongue-in-cheek, that 6502 assembler does not specifically disallow OO concepts ...)

 

[LazyMe]

BobRodes

it is because COM doesn't specifically support some of the OO concepts (while not disallowing them either)

The last section of that is not quite true:
Although it is not "disallowed", there's just no way (for example) that you can derive a class from a COM object; the best you can do is "inherit" its interfaces and rewrite the implementation code in your own class. And this is not inheritance, since you get nothing to inherit (apart from the contract that strongm explained earlier).


This is inheritance:

class Vehicle {
 protected:
    long m_lngColor;

 public:
    void Color(char* pszColor)
    {
        return m_lngColor;
    }

   virtual long NumberOfWheels()
   {
      return 4;
   }
};

class Car : public Class Vehicle {

};

class Truck : public class Vehicle
 public:
   long NumberOfWheels()
   {
      return 8;
   }
};

Not tested in anyway and as close to useless as it gets, but it does implement eactly what VB (and COM) cannot:

I can now instantiate an object of type Car and Truck and get the implementation of Color and, in the case f Car, NumberOfWheels for free.

Now; there's no way that you can do that in VB, nor can you do this in COM. You would write an empty class (in VB) which must be implemented entirely (copy-pasted if you will...) in a class of type Car and Tuck. In COM you would write an interface in a typelibrary file and have that implemented entirely in your COM object, still having to write the implementation of all metods yourself; you get nothing for free.....

... and that since VB was designed to support COM, it doesn't include the OO concepts that COM ignores.

That one I don't quite understand (or is mis-interpreted by me...); there are other languages that support COM yet do include the OO concepts that COM does not support.

I think that what strongm said in his post related to VB being COM is not that it supports COM, but rather that it is implemented as COM. I really don't know the implementation of a standard private class in VB, but I can imagine that it is so; since if you go from private to public, you already have a COM object (without having done any work actually.....) and the implementation of the VB classes are COM-alike.

Greetings,
Rick

 

[strongm]

Yep, that's a better summary. VB classes are basically just COM Automation classes (so they implement IDispatch) in a user-friendly wrapper

 

[BobRodes]

Yeah, I meant to say that VB was designed only to support the COM spec, rather than to support the OO paradigm. Our favorite word "implement" is a better word here, I do agree!

AS for your car and truck analogy, my point was that COM didn't have any sort of restriction about allowing you to compile your Car and Truck objects as COM objects that I was aware of, just because they derived from Vehicle via a non-COM-related process. I do agree that you can't compile Vehicle as a COM object and then inherit the object in Car and Truck in any sort of COM context.

As for reuse, and getting nothing for free, some pundits argue that black box reuse via aggregation (as supported by VB) is actually more useful than white box reuse via inheritance, since it dispenses with the fragile base class problem.

strongm>VB classes are basically just COM Automation classes (so they implement IDispatch) in a user-friendly wrapper
Um, not that you meant otherwise, strongm, but for clarity's sake: VB classes use Automation when a client doesn't support vTable binding. In other words, they don't use their implementation of iDispatch unless they have to.

Bob

 

[LazyMe]

my point was that COM didn't have any sort of restriction about allowing you to compile your Car and Truck objects as COM objects that I was aware of, just because they derived from Vehicle via a non-COM-related process.

Absolutely true.....

some pundits argue that black box reuse via aggregation (as supported by VB) is actually more useful than white box reuse via inheritance, since it dispenses with the fragile base class problem.

Black box reuse can be very useful. White box reuse however, is my favorite; saves typing.... So I guess I'm just not one of them pundits.

The beauty of VB.NET (since that is what actually started this thread....) is that both is possible there (with the limitation that one can only inherit from one class at a time at each level of inheritance)....

Greetings,
Rick