Gracias Cesar, tu explicación ha sido muy completa y clara. Yo sabia más o
menos que tenia que ser por algo de eso. Lo que me despisto fue que desde
Visual Studio .NET 2003, puedo poner instancias de botones, TextBox,
ListView o cualquier componente de la pestaña Widnows Forms, ¿a que se debe
esto? ¿que utilidad tiene?
Gracias por tu preciado tiempo.
"CESAR DE LA TORRE [Microsoft MVP]" <cdltll@hotmail.com> escribió en el
mensaje news:#fQudIMbEHA.3664@TK2MSFTNGP12.phx.gbl...
David, un control OCX es un componentes COM pero para utilizarlo en
formularios Windows visuales (tanto formularios VB 6.0 como también
podrías
utilizarlo en caso de ser compatible en formularios WinForms de .NET). En
el
caso de utilizarlo desde .NET, internamente .NET utiliza un sistema de
comunicación/compatibilidad entre los Assemblies .NET y los componentes
COM,
llamado COMInterop. Desde el entorno .NET visual con formularios,
realmente
lo normal es utilizar WinControls (nativos .NET) en lugar de controles OCX
(tecnología antigua COM).
En cuanto al WebService, es normal que no puedas utilizar un control OCX
dentro de un WebService porque un XML-WebService es un programa que se
ejecuta en el servidor y no tiene ningún interfaz gráfico. En .NET un
XML-WebServices es simplemente es una .DLL que implementa los interfaces
necesarios de WebService y tiene métodos que pueden ser invocados
remotamente devolviendo XML sobre protocolo HTTP y SOAP para poder
utilizarlo como un objeto remoto, pero no tiene ningún interfaz gráfico,
por
lo que logicamente no puedes utilizar un OCX desde un XML-WebService. Lo
que
si podrías utilizar desde un XML-WebService es invocar objetos de
Assemblies
de librerías de clases .NET, o incluso una .DLL de librerías de clases COM
(utilizando COMInterop transparentemente), pero no puedes utilizar
componentes que tengan interfaz gráfico o que necesiten como dices un
contenedor gráfico.
Si el .OCX lo que hace es representar cosas graficamente, debería
ejecutarse
en la aplicación cliente (.EXE WinForms), y esta aplicación cliente
llamaría
remotamente al XML-WebService pero simplemente para obtener DATOS (XML,
datos simples, DataSets, etc.).
La aplicación cliente (.EXE) la puedes desarrollar en .NET (es lo mas
comodo
para consumir un WebService), pero también podría ser un .EXE hecho en VB
6.0 que utilizando SOAP-Tool-Kit 'consuma' el XML-WebService del Servidor.
En caso de que la aplicación cliente sea una aplicación Web, también
probablemente (si es compatible para ejecutarse dentro de IE) puedes
utilizar el .OCX embebido dentro del HTML (como <OBJECT...etc.) que genere
una aplicación Web ASP.NET. Y esta aplicación Web ASP.NET 'consumiría' o
invocaría los objetos del WebService, que al igual que antes, solamente
devuelve datos (XML, datos simples, DataSets, etc.).
César de la Torre
[Microsoft MVP - .NET XML WebServices]
[MCSE] [MCT]
Renacimiento
Microsoft GOLD Certified Partner
www.renacimiento.com
"David" <davix_NOALSPAM@hotmail.com> wrote in message
news:eZKlBF2aEHA.3512@TK2MSFTNGP12.phx.gbl...
> Hola
>
> Tengo un control ocx, el cual puedo usar en mis aplicaciones en Visual
Basic
> 6(Menu referencias). Mi idea es crear un Servicio Web, que ofrecza una
serie
> de métodos públicos, los cuales usan internamente el control OCX, y
> devuelven un resultado al cliente del servicio web. El problema está que
al
> agregar el componente en el toolbox de Visual Studio .NET, el componente
> aparece deshabilitado (en gris). El control OCX en una aplicación de
> formulario normal, lo que hace es manipular imágenes. Imagino que visual
> studio no me deja instanciar el objeto porque el OCX necesita estar
dentro
> un componete contenedor (una ventana windows, un frame etc..) y claro un
> servicio web no tiene control contenedor. ¿estoy en lo cierto, en mi
> conjetura? ¿Sabeis algo del tema?
>
> Un saludo.
>
>
Leer las respuestas