Re: Control OCX en un servidor web. Pregunta dificil aviso!! ;-)

25/07/2004 - 21:43 por David | Informe spam
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

#1 CESAR DE LA TORRE [Microsoft MVP]
26/07/2004 - 00:24 | Informe spam
Pues realmente no vale para nada el poder añadir un botón o un TextBox a un
Web Service XML porque este no tiene ningún interfaz gráfico. Todo lo que
devuelven los WebServices son datos como 'producto' de haber ejecutado un
WebMethod de un WebService. Los XML-WebServices son completamente
transparentes desde el punto de vista de 'Interfaz Gráfico' (Capa de
Presentación).
El hecho de que te permita hacerlo VS.NET es simplemente que no lo han
restringido en el propio interfaz gráfico de VS.NET, pero no le veo utilidad
alguna. Quizás hubiera sido bueno que lo hubieran deshabilitado para no dar
lugar a aquívocos.

César de la Torre
[Microsoft MVP - .NET XML WebServices]
[MCSE] [MCT]

Renacimiento
Microsoft GOLD Certified Partner
www.renacimiento.com




"David" wrote in message
news:usTwZ%
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]" escribió en el
mensaje news:#
> 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" wrote in message
> news:
> > 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.
> >
> >
>
>



Preguntas similares