Re: Newbie question

Will,

> [Oh, so now we've moved on from discussing the best way for the OP to
> proceed and have now moved on to mind reading and personal affronts? I can
> play that.]

I am very sorry that you got me this way and I really apologize that
you felt my post being a personal affront. It just wasn't meant this way!

There are some technologies I don't use because I don't like them,
but there are also some that I don't use just because I don't know them,
or I don't know them well.
After all I don't think there is anything to that! I just had the
feeling that there must be some reason why you write against TAPI3:

> I really don't know not having done the research because there is no way
I'd
> ever use version 3 of the API in a real application <g>.

I just guessed that you haven't had much contact with TAPI3 because
you stated something similar in a previos post. But this wasn't meant
to express any doubt in your general expertise and of course this wasn't
meant as a personal affront either!


> > If you have a simple single-threaded and single-connection application
> > without GUI: Yes.
> Well, that would be typical of a VB application, wouldn't it? ;-)

No necessarily. You could also create a COM dll, a COM Server or
a non-GUI exe. (at least we have quite a few of these types of projects)


> No. I don't use version 3 because it is COM based. And I don't use COM for
> the same reason I don't play with Lego blocks. I've moved on and grown up.

Well, I didn't want to start a discussion about COM against .NET. I just
wanted to say that if someone using VB should use TAPI3, because TAPI2
is really a pain with VB. (e.g. VB doesn't do well handling callbacks etc.)
It wouldn't be a helpful suggestion to a VB programmer which is new to
TAPI to suggest to use TAPI2 with VB. And that's what this topic was
about.

> And no matter what one's perspective on COM, here is a clue: It is done,
put
> a fork in it. :-)

This is not true. Large parts of Windows are built on COM. (not the core
components, but a huge amount of stuff). I'd also say that most Windows
applications currently on the market are using COM (at least in some way)
and this won't change that quickly. Do you think we will see MS Office
developed in .NET soon? I don't.
I also wouldn't say that COM is like Lego. There are a lot of people
that are considering .NET as like Lego instead - but I don't.
There are a lot of things that are not very well suited for .NET,
like DirectShow, which is COM based. I'm quite sure we won't see
a .NET version of DirectShow and even using CCWs, you wouldn't
be able to create efficient DirectShow filters with .NET, just as an
example..
On the other hand .NET has it's advantages too and i really enjoy
using it.

Why not use the best technology for each individual purpose? Our
software (TERAVoice) is a mixture of VB COM components and
a C++ service handling threading and several other low-level tasks.
This allows efficient and quick programming of business logic stuff
while having a robust base for critical parts of the application;
our web site on the other hand is built with C#.NET and some of
our internal database frontends are done with MS Access. Even in
retrospective each of the choices was an optimal solution to each
problem - at least for me. I don't think it's wise to follow any kind
of hype statements like "only C++ programmers are real programmers",
"COM is dead, .NET is the only future", "VB is just for script kiddies",
"C is for beginners, I'm programming microcontrollers in assembler",
but rather a neutral assessment of available and suitable technologies.


Best regards,

Matthias Moetje
-------------------------------------
TERASENS GmbH
Ackermannstraße 3
80797 München
-------------------------------------
Fon: +49 89 143370-0
Fax: +49 89 143370-22
e-mail: moetje at terasens dot de
www: www.terasens.de
-------------------------------------

"William DePalo [MVP VC++]" <willd.no.spam@xxxxxxxx> wrote in message
news:%23daqtF0rFHA.2348@xxxxxxxxxxxxxxxxxxxxxxx
> "Matthias Moetje" <moetje@xxxxxxxxxxxxxxxxxxx> wrote in message
> news:%23FQWxmvrFHA.3264@xxxxxxxxxxxxxxxxxxxxxxx
> > If you have a simple single-threaded and single-connection application
> > without GUI: Yes.
>
> Well, that would be typical of a VB application, wouldn't it? ;-)
>
> >> I really don't know not having done the research because there is no
way
> > I'd ever use version 3 of the API in a real application <g>.
> >
> > Why? Probably because you don't know it?
>
> [Oh, so now we've moved on from discussing the best way for the OP to
> proceed and have now moved on to mind reading and personal affronts? I can
> play that.]
>
> No. I don't use version 3 because it is COM based. And I don't use COM for
> the same reason I don't play with Lego blocks. I've moved on and grown up.
>
> And the point is that I know too much rather than too little. I am far too
> well versed in Win32 with its support for thread pools, APCs, critical
> sections, mutexes and with C++'s far more elegant object model than to
> choose the god-awful morass of multi-threaded apartments, single threaded
> apartments, neutral apartments, free threaded marshallers, window message
> pumps in servers where there should be none, dodgy reference counting and
> all the other gunk that is COM. Frankly, it exists largely to make easy
and
> comfortable the lives of the less ambitious and less technically astute.
> I'll pass on it, thank you.
>
> And no matter what one's perspective on COM, here is a clue: It is done,
put
> a fork in it. :-)
>
> Remember COM+? Five years ago, it looked like COM+ was going to be an
> attempt by some to 'save' COM. Thankfully, saner heads prevailed, COM+
gave
> way to the .Net platform, and COM is dieing a slow death. May it rest in
> peace!
>
> In short, I know the difference between easy and good and modern and
legacy.
> That's why I don't use it.
>
> Regards,
> Will
>
>


.

Relevant Pages