Re: Error message about my user defined type

From: Ulrich Korndoerfer (ulrich_wants_nospam_at_prosource.de)
Date: 09/15/04 

Date: Wed, 15 Sep 2004 22:47:08 +0200

Hi Hanna-Barbera,

Hanna-Barbera wrote:
 
> the name comes from the makers of Scooby Doo actually.

I am afraid I do not understand this. What is Scoopy Doo? A television
series? I am missing the sharing of your cultural surrounding ;-)

> The thing is, I prefer to design my program by defining things like UDT and
> classes each in their own files, and then
> I would like the ability to declare and use one in the other.

That's ok.

> It's the kind of programming I do in C++ and that involved header files and
> implementation files and the #include directive.
>
> In VB, it has to make everything available automatically, but if I
> understand you correctly, VB6 has some issue with COM?

I will try to explain in a nutshell:

COM is a convention, defining how binary (compiled) objects have to
behave to be able to be accessed (instantiated and used). This
convention does not say, how to and in which language the object has to
be implemented. COM objects can be implemented using many languages,
among them VB and C++.

C++ has its own vision of objects. A plain C++ object is not a COM
object. But one can add additional C++ code, to turn a C++ object into a
COM object. So in C++ one has simple plain C++ objects and COM objects.

If a C++ programmer wants to use objects, which he will never share with
others programs in compiled binary form, he writes common simple C++
objects. If he wants to use them in its own projects, he uses header
files and the source code of the object and instantiates them and
accesses their methods with the given C++ mechanisms.

If he wants to share his *compiled* objects (in binary form) with
others, he has to write extra code to turn them to COM objects. Then,
when he or others wants to use those COM objects, they must use COM
mechanisms (that is mechanisms obeying the COM conventions but
programmed with C++), not C++ mechanisms (like new and dispose).

For this to work there must be a way to give the user of a COM object
the same information like he needed when using a simple object in
direct, that is kind of a header file defining the type of the object
(including its methods and variable types it uses).

This is where type libraries come into play. COM objects are gathered in
a Dll along with a type lib (embedded as resource in this dll). The type
lib is sort of a compiled header file. When one wants to use a COM
object, the type lib delivers to the compiler all necessary information
like a header file would do.

The inventors of VB decided to make their objects being always COM
objects. So each object (that are classes, forms, user controls,
basically anything that is not residing in a .bas module) also has to
have a typelib accompanying it, which publishes the necessary
informations. And when a VB programmer uses an object, it is always done
by using COM mechanisms.

So VB is a first class member of those programming environments, which
can *make* and *consume* (not only its own ones) COM objects. And it
does the necessary plumbing almost automatically behind the scenes,
making it very easy to create and use COM objects. In fact so easy and
so hidden, that most VB programmers do not even know that they are doing
COM programming all day long. And if they put their code exclusively
into .bas modules, they even do not use COM.

Now, as COM mechanisms have been invented to provide a means for others,
to use your objects, all type informations along with the objects have
to be made public available. This is the intention of COM.

But that is not necessarily always wanted, when you are a VB programmer.
If you are doing a so called standard exe, all what you want is to make
and use objects, but not to publish them to the outside.

There you have a contradiction. VB is based on COM. When you are doing
objects, it uses COM. COM is for making and using objects from all of
the public outside a project, but in this case you do not want
publicity.

The solution VB took is to make two kinds of projects available
(basically because of compatibility reasons to former VB versions, which
did not use COM):

- standard exes: they use internally COM, but do not publish to the
outside
- COM servers (ActiveX dlls and ActiveX components (.ocx)): use COM and
publish

This is, where the scope of objects come into play. VB objects can have
private scope (their type is not published) or public scope (their type
is published). As standard exes do not allow public scope, there also is
no choice for the programmer to choose between them in the classes
property window.

To make things a little bit more complicated, the VB team decided (for
various reasons, among them performance), to implement its own COM
mechanism handler.

There are then two COM mechanism handlers, which help in using COM
objects:

- the "official" ones (as implemented in OLExxx.dlls). They are system
wide available to any programming language who wants to use them. They
are full fledged and implement all aspects of COM.

- the VB one. This one is a little bit sloppier and implements (residing
in the VB runtime dll) just enough functionality for doing basic COM,
such being not compatible to the "official" ones. In special it does not
use or make typelibs.

So, if a VB project is of kind "standard exe", where all COM objects are
hidden to the outside, VB can use exclusively its own build in COM
handler, and does so.

This all works quite fine. But sometimes the COM base shines through the
mist. That is then when a VB programmer gets being startled because
suddenly things seem to become quite complex, as he was not aware that
he is using COM.

> What about VB .NET?

.NET does not use COM anymore (so some say: COM is dead as it is not
pushed further by MS).

The intention of COM was to unify access and use of compiled objects, no
matter what programming language was used to declare and compile the
object. It was an attempt to make code reuse working, despite the fact
that each programming language (and their accompanying runtimes) have
their own ideas of what an object is and how it is build and accessed.
COM lays an additional, separate, programming language or runtime
inspecific layer over language specific objects to establish
unification.

.NET goes the other way round to establish code reuse. It uses *one*
runtime (the CLR) and *one* language (the MSIL) for declaring and using
objects. Objects are expressed and used only and only again by using the
CLR and the MSIL. There is no way to declare objects and use objects
other than using the CLR and the MSIL. So all the differences arising
from using different programming languages and environments has gone. No
more different languages to use for creating objects. There is only one
way to create and handle objects: by using the CLR and the MSIL. Period.

But what is with the former used languages like C++, VB and so on (all
languages which are able to create objects)? Are they broken now? Do we
have to program using MSIL (btw, Microsoft Intermediate Language, if you
don't know) exclusively?

Indeed, you can *all* do what has to be done and can be done in .NET by
using Notepad and writing some MSIL code, compiling it with the MSIL
assembler. MSIL is a low level, assembler like, but much much more
expressive and also object oriented (right, object oriented assembler
:-) ) language. There is some room left for traditional assembler, but
only little.

But fortunately as .NET programmer you don't have to use MSIL in direct
;-). Some guys at MS decided to rewrite their C++ and VB compilers so
that they spit out MSIL assembler (in case of C++ at least if you use it
in managed mode, otherwise it behaves as a traditional C++ compiler)
instead of machine assembler code. They also created a complete new
language, called C#, for those who like Java-like programming. And many
other companies decided to rewrite their compilers too. So actually you
also can use Fortran, Cobol, Perl (!), Python (I think), Eiffel, Delphi
(I think available now) and more languages. MSIL is mighty enough
(indeed MSIL and the CLR are the shining diamonds in .NET) to allow
these languages to express themselves with mostly all of their
pecularities.

And on top of this they build a completely new, MSIL based, vast
framework. As it is build using MSIL and the CLR (and a little bit
traditional assembler, aka unmanaged code), it can be used from all
languages that are able to deal with MSIL and the CLR.

This eliminates another annoying aspect, when it comes to code reuse
(from the programmers viewpoint, it is rather knowledge reuse): you have
to learn only *one* framework, no matter which programming language you
use (as long as you do MS Windows programming, of course).

So say goodbye to C runtimes, STL, MFC, ATL, WTL, VB runtimes and all
other frameworks doing like jobs in different ways.

Looks like I am a .NET afficionado. In a sense, I am. *Technically*, to
my oppinion, it is brilliant. Not that there are not other like
brilliant things out there (need to say Java?). But there are
differences and that ugly real world breaks into when one has to decide
what to use :-) 

-- 
Ulrich Korndoerfer
VB tips, helpers, solutions -> http://www.proSource.de/Downloads/

Relevant Pages

  • Re: [EGN] Numerical Accuracy
    ... The advice worked because in fact the Microsoft compiler had a bug. ... The capabilities of the optimizer are not so ... The language standard itself says ... of "programming" as a nonprofession. ...
    (comp.programming)
  • Re: Learning C++?
    ... >> abide such rules or there are people who don't know the rules. ... > programming is excellent, and its object-oriented support is quite ... code, like Java or Ada or what else, but no language can prevent the ... This is also something the compiler should be ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Beyond CL?
    ... around in the internals of the language. ... as the programmable programming language; ... Eventually a bank of many users' optimizations could be ... approach the fabled "sufficiently smart compiler". ...
    (comp.lang.lisp)
  • Re: Error message about my user defined type
    ... write a compiler that allow a true VB7 to run on the .Net platform ... > COM programming all day long. ... > wide available to any programming language who wants to use them. ... > other than using the CLR and the MSIL. ...
    (microsoft.public.vb.general.discussion)
  • Re: Can you write code directly in CIL ???
    ... >> Cab you write code directly in the Common Intermediate language? ... >> optimize a critical real-time function. ... compiler translate this into assembly language. ... > 2- C# compiler is as clever in generating msil as anyone can possibly get. ...
    (microsoft.public.dotnet.languages.csharp)