[STAThread]

[Willy Denoyette [MVP]]

| Willy Denoyette [MVP] wrote:
| > | And that's where we seem to be a far cry from a comment from your
| > | original post:
| > | "but it works, that's the beauty of COM."
|
| > No it's not, it works, but you need to respect some simple rules of COM,
| > just like you need to respect many rules when using .NET components or
Java
| > components whatever.
|
| And that's okay - I guess I just don't think it's *quite* as
| straightforward as you made it out to be.
|

Agreed, it isn't that straightforward, I was using COM even before it was
released to the public, it was part of my job at DEC, I know it's rather
complex, but once you understand the basics it's quite simple to use COM,
again, I don't mean to "author objects" which is a different matter as you
certainly know.


| Of course, it could well be that I've been using misbehaving COM
| components. Given how foul the interface was, I wouldn't be at all
| surprised.
|
| > Yep, but it's not that difficult to remember the basic rules, if you
care,
| > but I guess that's your problem, you don't care (or should I say don't
like)
| > about COM.
|
| The details are slightly hazy at the moment, but when I was trying to
| use COM from C++, I remember reading about such rules and what would
| supposedly happen automatically for a long time, and finding the whole
| thing immensely frustrating. Things which *should* have worked just
| didn't. .NET made the whole thing a lot easier, I'll readily admit that
| - but there were still issues.
|

I understand, but IMO it's a matter of tools, VB6 is (was) great (be it not
perfect) to author simple COM objects and controls, C++ is the only tool to
build great COM components and Automation servers (one of the reasons why
most (serious) products that leave Redmond remains tied to C++!), but here
the learning curve is steep, frameworks like ATL and MFC may help you a lot,
however, they have their own price. And here we can blame MSFT for not
providing us a similar development environment as VB6 for C++, instead they
took the managed route, they lost quite some years in their Sun/Java battle,
finally they had to come up with their own managed environment, C#/VB.NET
and .NET was born as an alternative for VB and Java at the user level, COM
was moved to the system level (using C++ as language).



| If I ever need to work with COM (knowingly) again, I'll dig a bit
| deeper (you know I like understanding what I'm doing)

Yes, I think I know you a bit without knowing you personally, and that's why
it surprises me to hear "- I hope to have very little to so with it!" from
someone like you.
Anyway, if you are using .NET on Windows, you better understand the basics
of COM, whether you like it or not, COM is part of the CLR and the
Framework, one day the aquired knowledge will pay off, it always does .

Willy.

 

[Alvin Bruney]

most (serious) products that leave Redmond remains tied to C++!), but here
jumping the gun here? The MS office COM libraries aren't C++ are they? I've
never seen the code so I cant confirm but I can deduce that because of
things like optional parameters etc. If you've seen the code feel free to
correct me.

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006

 

[Willy Denoyette [MVP]]

I saw some (not all) of the source code years ago when we ported Excel and
Word to Alpha (RIP), and be sure all of it was C++ (with some embedded
assembly), I don't think things have changed a lot since then (other than
re-writes). The COM interfaces for the automation servers, were (are)
defined in MIDL and ATL is used as the framework for the implementation.
What makes you think it's written in an other language, MIDL and C++ support
optional and default value arguments.
If you think they are written in VB because of the default and optional
arguments, convince yourself by running depends on them, if one of the
Office applications (automation servers) depend on MSVBVM60.DLL, I'll pay
you a "Château Lafite Rothschild - Magnum" ;-)

Willy.



|> most (serious) products that leave Redmond remains tied to C++!), but
here
| jumping the gun here? The MS office COM libraries aren't C++ are they?
I've
| never seen the code so I cant confirm but I can deduce that because of
| things like optional parameters etc. If you've seen the code feel free to
| correct me.
|
| --
| Regards,
| Alvin Bruney [MVP ASP.NET]
|
| [Shameless Author plug]
| The Microsoft Office Web Components Black Book with .NET
| Now Available @ www.lulu.com/owc
| Forth-coming VSTO.NET - Wrox/Wiley 2006
| -------------------------------------------------------
|
| | >
| > | > | Willy Denoyette [MVP] wrote:
| > | > | And that's where we seem to be a far cry from a comment from your
| > | > | original post:
| > | > | "but it works, that's the beauty of COM."
| > |
| > | > No it's not, it works, but you need to respect some simple rules of
| > COM,
| > | > just like you need to respect many rules when using .NET components
or
| > Java
| > | > components whatever.
| > |
| > | And that's okay - I guess I just don't think it's *quite* as
| > | straightforward as you made it out to be.
| > |
| >
| > Agreed, it isn't that straightforward, I was using COM even before it
was
| > released to the public, it was part of my job at DEC, I know it's rather
| > complex, but once you understand the basics it's quite simple to use
COM,
| > again, I don't mean to "author objects" which is a different matter as
you
| > certainly know.
| >
| >
| > | Of course, it could well be that I've been using misbehaving COM
| > | components. Given how foul the interface was, I wouldn't be at all
| > | surprised.
| > |
| > | > Yep, but it's not that difficult to remember the basic rules, if you
| > care,
| > | > but I guess that's your problem, you don't care (or should I say
don't
| > like)
| > | > about COM.
| > |
| > | The details are slightly hazy at the moment, but when I was trying to
| > | use COM from C++, I remember reading about such rules and what would
| > | supposedly happen automatically for a long time, and finding the whole
| > | thing immensely frustrating. Things which *should* have worked just
| > | didn't. .NET made the whole thing a lot easier, I'll readily admit
that
| > | - but there were still issues.
| > |
| >
| > I understand, but IMO it's a matter of tools, VB6 is (was) great (be it
| > not
| > perfect) to author simple COM objects and controls, C++ is the only tool
| > to
| > build great COM components and Automation servers (one of the reasons
why
| > most (serious) products that leave Redmond remains tied to C++!), but
here
| > the learning curve is steep, frameworks like ATL and MFC may help you a
| > lot,
| > however, they have their own price. And here we can blame MSFT for not
| > providing us a similar development environment as VB6 for C++, instead
| > they
| > took the managed route, they lost quite some years in their Sun/Java
| > battle,
| > finally they had to come up with their own managed environment,
C#/VB.NET
| > and .NET was born as an alternative for VB and Java at the user level,
COM
| > was moved to the system level (using C++ as language).
| >
| >
| >
| > | If I ever need to work with COM (knowingly) again, I'll dig a bit
| > | deeper (you know I like understanding what I'm doing)
| >
| > Yes, I think I know you a bit without knowing you personally, and that's
| > why
| > it surprises me to hear "- I hope to have very little to so with it!"
from
| > someone like you.
| > Anyway, if you are using .NET on Windows, you better understand the
basics
| > of COM, whether you like it or not, COM is part of the CLR and the
| > Framework, one day the aquired knowledge will pay off, it always does
.
| >
| > Willy.
| >
| >
| >
|
|