Objectos COM con ATL

Hola Angel,

Que yo sepa si puedes hacer componentes COM con ATL sin IDispatch, en el
wizard lo deseleccionas y punto.
Que no usen typelibrary, creo que eso tienes que putearlo ( valga la
expresion ), yo creo que por defecto el compilador usando ATL te empotra la
type library en el componente, realmente si vas a trabajar sin usar
IDispatch y sabes los CLSID y los IID no necesitas la typelibrary. Teniendo
el .tlb o los .c y .h generados no necesitas conocer la typelibrary.

¿ alguien puede confirmar si en ATL la typelibrary va siempre empotrado en
el fichero, y para quitarla hay que luego retocar el fichero ?

Saludos
Isidro.


"Angel Traversi" escribió en el
mensaje news:

Hola a todos

Tengo intenciones de desarrollar objetos COM con ATL y nunca lo hice.

Hasta

ahora los he desarrollado con herramientas de Borland y la idea es pasarme

a

Visual C++.
Uno de los requerimientos a cumplir es que los objetos no implementen
IDispatch y que no tengan typelibrary. Los motivos:
- se usan siempre Inproc. No hay necesidaad ni interes en usarlos

outofproc

o remotos.
- el código que usa los objetos esta escrito también C++ y nunca se

usarán

desde VB o java
- IDispatch hace que la interface sea pública y se conozcan los métodos,
interfaces, etc y esto atenta contra el secreto industrial de la empresa
donde trabajo.

La pregunta es: puedo crear objetos usando ATL que no implementen

IDispatch

ni usen typelibrary ?
Conocen ejemplos o links referidos a este tema ?

El tlb se añade como recurso a la dll. El tema es evitar eso.

Busca un texto similar al siguiente en el archivo .rc de tu solución y
comentalo. Esto evitara que se incluya el tlb como recurso.
3 TEXTINCLUDE
BEGIN
"1 TYPELIB ""tudll.tlb"""
"\0"
END

Otro tema es que no entiendo muy bien por que quieres hacer esto. ¿Si sabes
que las clases solo se van a usar desde C++ para que usar COM? Crea una dll
normal y corriente que exporte clases, asi evitas el precio en rendimiento
de usar COM, que es pequeño peor ahi esta.

COM solo tiene sentido si hablamos de crear componetes que vayan a ser
usados por diferentes programadores o/y desde diferente lenguajes.

Lo de proteger la propiedad intelectual no lo entiendo muy bien. Si alguien
va a usar tus objetos tiene que conocer sus interfaces, sea a través de un
tlb o sea a traves de unas cabeceras que tu le proporciones, luego no creo
que por quitar el tlb estes ocultando información trascendente.

Un saludo
Rodrigo Corral González [MVP]

FAQ de microsoft.public.es.vc++
http://rcorral.mvps.org

Muchas gracias Isidro y Rodrigo por sus datos.

El por qué de usar COM: el servidor está escrito en C++ y los clientes estan
en C++ y Delphi. Y hay programadores de distinto teem interviniendo. COM es
muy cómodo en este escenario. Incluso con poco esfuerzo cliente y servidor
pueden tener compiadores de C++ distintas marcas.
Y es necesario que los componentes sean conocidos por ciertos clientes y
nadie mas. No hacemos componetes para que los use todo el mundo, sino
determinados clientes a los que solo le damos un .h.

"Rodrigo Corral [MVP]" escribió:

El tlb se añade como recurso a la dll. El tema es evitar eso.

Busca un texto similar al siguiente en el archivo .rc de tu solución y
comentalo. Esto evitara que se incluya el tlb como recurso.
3 TEXTINCLUDE
BEGIN
"1 TYPELIB ""tudll.tlb"""
"\0"
END

Otro tema es que no entiendo muy bien por que quieres hacer esto. ¿Si sabes
que las clases solo se van a usar desde C++ para que usar COM? Crea una dll
normal y corriente que exporte clases, asi evitas el precio en rendimiento
de usar COM, que es pequeño peor ahi esta.

COM solo tiene sentido si hablamos de crear componetes que vayan a ser
usados por diferentes programadores o/y desde diferente lenguajes.

Lo de proteger la propiedad intelectual no lo entiendo muy bien. Si alguien
va a usar tus objetos tiene que conocer sus interfaces, sea a través de un
tlb o sea a traves de unas cabeceras que tu le proporciones, luego no creo
que por quitar el tlb estes ocultando información trascendente.

Un saludo
Rodrigo Corral González [MVP]

FAQ de microsoft.public.es.vc++
http://rcorral.mvps.org