Incluir Delphi windows .NET en RAD Studio CodeGear
 

En el nuevo RAD Studio 2007 de CodeGear, se ha eliminado los proyectos Delphi Windows form .NET
Si te interesa que esta opción sea incluida en el nuevo IDE de CodeGear, por favor, vota en el siguiente link de QualityCentral:

http://qc.codegear.com/wc/qcmain.aspx?d=52299

Gracias.

No entiendo, si yo voy por File|New|VCl Forms Application - Delphi for .Net, me supondria que eso es Delphi Windows form .NET ¿O me equivoco?, la verdad es que no se de .NET, por eso pregunto :).

No entiendo mucho tu solicitud, tu creaste la encuesta y además de que solo te registraste para esto, pero.....:rolleyes: ya le diste una leida al roadmap de estos productos.....:confused:

Lee

Delphi "Highlander" y Delphi "Tiburón"

Delphi Winform .NET esta fuera??
 

Eso temía que sucediera..., la empresa en la que trabajo, desarrollo sus aplicaciones en esa plataforma, es decir Delphi WinForm.NET, y lamentablemente ahora fue abandonado por CODEGEAR.

Jamas podremos actualizar nuestros productos a .NET 2.0, me parece algo no muy bueno, ya que tomaron un área y luego lo dejaron flotando. Si prosiguen de este modo no hay garantía de iniciar proyectos a largo plazo con Delphi, ya que no se sabe, en que versión dejarán de actualizar esa línea.

Me parece que en mi empresa tendremos que dar un golpe de TIMÓN, y volcarnos a VS.net.

Hola,

No entiendo. ¿Qué son exactamente los proyectos Delphi WinForm .NET? ¿Los que usan la VCL .NET?

Pues yo estoy igual que tu, crei que era lo que comente en el primer post o eso de la VCL.Net :(, siempre me a confundido este asunto.

Pues lo dicho, leyendo he visto esto.

Salud OS

Caramba¡¡¡, no se si es que mi mente esta muy cerrada ante el tema, pero ¿Eso que significa?, ¿Que si trae lo de WinForms .Net o que no lo trae? :D... es que como les dije, estos terminos siempre me han confundido :confused::D

:confused: Vaya ahora el confundido soy yo, a lo mejor y como decimos aquí en México (me estoy orinando fuera de la bacinica)....

En fin, si estoy equivocado perdón por mi arranque......

Salud OS

¿Podrían explicarnos?
 

¡Quiubo!

Chavos, yo también soy de los que desconocen cómo ha venido evolucionando .NET en Delphi. Siempre me pareció que sería precipitado entrarle a .NET con Delphi cuando éste apenas llevaba un par de versiones soportándolo y con tantas turbulencias de CEOs y demás.

Pero ahora que CodeGear se ve más estable, organizado y fuerte (espero que no sólo sea apariencia), me surge la inquietud de entrarle ahora sí a .NET con la nueva versión.

En varias ocasiones escuché (leí) decir que había dos opciones .NET en el Delphi 2005 y versiones subsecuentes, que me parece eran algo llamado WinForms y VCL.NET, pero la NETa (:D) no tengo ni idea de qué hay en una y otra.

¿Alguien podría explicarnos a detalle cómo está eso de las dos opciones .NET y confirmar en qué versión desapareció una de ellas (que es lo que entiendo por el mensaje inicial de este hilo)?

Gracias.

Al González. :)

Diferencias entre VCL.NET y Winforms .NET
 

Empece a utilizar Winforms.NET desde Delphi 2005 y luego migre sin problemas a DELPHI 2006, y vi cual era la diferencia

VCL.NET es todo lo que siempre conociamos (Clases, Tipos de Datos, Componentes, etc) pero que a la hora de compilar lo hacia hacia .NET, es decir, que existian unas clases de MÁSCARA de modo que programabamos como siempre, solo que el lenguaje internamente lo traducia a .NET. (corrijanme si estoy equivocado, es lo que pude evidenciar).

Winforms .NET son todas las CLASES, TIPOS DE DATOS, COMPONENTES, que vienen directamente en .NET FRAMEWORK, y que al compilarlo tambien lo hacia en .NET.

La ventaja... de Winforms .NET (a mi modo de ver) es que contamos con muchisima información, programas ejemplo, AYUDA, en nuestro IDIOMA, que podemos usar ya que al ser todo .NET FRAMEWORK, podemos usar la ayuda que viene con el Framework en español.

La verdad no estoy seguro si Desaparecio la versión WINFORMS del Developer Studio 2007, pero lo que pude ver en los videos de presentación... no vi por ningun lado esa opción. Tal parece que solo dejaron VCL.net.

Si esto sería así, me parece una mala medida, ya que... si usamos todos los nombres, librerias y etc. para que quedriamos usar VCL.NET?, si seria mas lento, ya que necesitaría un interprete... seria mucho mejor estar con el VCL, normal compilando de manera nativa. Bueno es mi opinion... me imagino que deben haber mas posturas que no considere...

Saludos.

¿Y cuál de las dos es la que según jholgado fue supuestamente eliminada y en qué versión sucedió? :confused:

Según Jholgado fue eliminada la versión Winforms .NET, dejando solo VCL .NET, y eso desde la versión Developer Studio 2007, que acaba de salir hace 1 semana o 2.

Saludos.

Ah, jijos, por un lado suena a "salirse del estándar", pero por otro lado suena a consentir a quienes estamos tan agusto y apegados a la VCL sin obligarnos a aprender demasiado de .NET

No sé, no sé, necesitaría leer más opiniones. Pero de entrada muy interesante lo que comentas radaalvaro. Gracias.

Al.

Si, tienes mucha razón, al parecer no hay muchas personas que probaron Winforms.NET, varias veces hice diversas preguntas con respecto al dema de DELPHI WINFORMS .NET, pero nadie me contesto. Sería interesante poder compartir mas ideas y opiniones con mas personas.

Saludos.

Hola,

Aquí falla algo, o, decididamente, yo no entiendo nada del tema. Comprendería que fueran dejando de lado la VCL .NET, para centrarse en el .NET FrameWork. Por dejar de lado no me refiero tampoco a que la abandonen sin más, sino a que la gente fuera espabilándose con el FrameWork .NET y pensara que la VCL .NET no era sino una especie de transición.

Quiero decir que no comprendo, no tiene sentido, desde ese punto de vista, que quiten WinForms .NET, puesto que esto forma parte del FrameWork .NET, ¿no? A no ser... ¡aquí puede estar el meollo del asunto! A no ser, que pasen a soportar sólo el modelo que sustituya a WinForms .NET... que ahora mismo no recuerdo ni cómo se llamaba... Avalon, Indigo o algo así... ¿no era?

¿No se suponía que .NET iba a servir para unificar APIs y normalizar GUIs, y que eso iba a ser su gran ventaja frente a la JVM (Máquina Virtual de Java)? Pues me parece a mi (y si no entendí mal, porque yo también estoy confundido) que está yendo por la misma vía que las (innumerables) APIs de Java.

Pues yo también debería de expresar mi opinión al respecto.

Efectivamente, a partir de Delphi 8 existen dos opciones de crear aplicaciones que no son nativas Win32. Cuando abres Delphi, puedes crear un proyecto Winforms, o un proyecto VCL.Net.

Cuando empezé con Delphi, empezaba de cero total. Con un nuevo proyecto de bastante envergadura. Así que tenía que decidirme cual de las opciones elegir. O incluso quedarme en Win32.

Como por aquel entonces todo el mundo hablaba de .NET, pensé que ya que se empieza de cero, lo mejor es empezar con lo último que haya en el mercado en ese momento.

Estuve mirando la opción de Winforms y por aquel entonces había poca información al respecto. Además fue cuando comencé en este foro y vi que prácticamente nadie tocaba el tema de los Winforms. Al día de hoy creo que menos del 5% del foro está relacionado con los Winforms.

Así que me decidí por utilizar la opción VCL.Net. Para los que necesiten de aclaración, decir que es al 99.99% igual que programa en VCL para Win32, excepto sobre todo en lo que se refiere al sección de Servers, que no existe en VCL.Net ya que se trata de independizarse de la plataforma Win32 y por tanto de productos tan 'Win32' como el Office de Windows.

Al día de hoy, todas mis preguntas son respondidas por cualquiera que programa en Win32, así como yo puedo ayudar a cualquiera que porgrama en Win32, ya que como indico es idéntico. Si acaso algunas veces he tenido 'problemas' inexplicables con los componentes en VCL.Net a diferencia de Win32.

Que CodeGear haya abandonado por completo los Winforms en su nuevo RAD 2007 me parece bastante fuerte, ya que si en su momento apostó por .NET y una tecnología nueva, me parece un abandono muy grande de todos aquellos que decidieron optar por dicha opción de Winforms.

No puedo seguir opinando más alla ya que todavía no he tenido oportunidad de probar el RAD 2007.

Que sigan apostando por VCL.Net, a mi me viene de maravilla claro está. Pero suerte la mía de haberme decidido por esta opción en vez de por Winforms, ya que si no podría estar pensando en tirar más de 2 años de trabajo por la borda, ya que denotaría que mi proyecto no tendría soporte en un futuro inmediato.

Es lo que pasa con la informática, todo se mueve demasiado deprisa, y muchas veces uno no se atreve por apostar por una tecnología nueva por ejemplo en el caso de Winforms.

Qué pasaría si por ejemplo ahora lanzan a bombo y platillo BalckFishSQL y dentro de 2-3 años deciden dejarlo ? Pues que todo aquel que haya optado por dicha BD se sentirá absolutamente traicionado.

... mala política esta de CodeGear :(

Nosotros llevamos desarrollando desde Delphi 8, proyectos Windows form .NET, en ese momento valoramos la opción de VCL.NET, pero nos pareció mas standar utilizar las librerías del propio Framework .NET 1.1. Hasta ahora, nos ha funcionado correctamente.

El el nuevo ID llamado RAD Studio CodeGear, solo aparecen dentro de Delphi .NET proyectos VCL.NET y ASP.NET.

Los proyectos Windows Form .NET realizados con Delphi 2006, se pueden compilar con el nuevo ID, pero el diseñador de pantallas ha desaparecido. NO hay manera de modificar de forma fácil el código de las mismas.

La faena es que con Delphi 2006, las aplicaciones solo corren en .NET 1.1. No hay manera fácil de continuar esos proyectos en .NET 2.0 ó 3.0

Abrí un incidente sobre este tema mediante nuestro mantenimiento con CodeGear. Ellos me han confirmado lo que os cuento. La única esperanza que nos dan, a los que estemos en esta situación, es que votemos para que esto se siga incluyendo en los nuevos ID de Delphi.

Gracias por vuestras respuestas.

Ahhh, ahora si me quedo un poco mas claro que es VCL.NET y Winforms for .NET... pero desafortunadamente sigo sin entneder varias cosas :(.

1. ¿Cuando uno hace codigo en VCL.NET queda parecido a una aplicación Win32 pero bajo .NET o eso queda en APS.NET?

2. ¿Una aplicacion creada en VCL.NET puede correr en un navegador de internet?

3. Si ya quitaron Winforms, ¿Entonces que es esa opcion que yo veo en el RAD Studio que esta en File|New|Vcl Forms Application - Delphi for .NET?

4. Si al hacer aplicaciones en VCL.NET no compila a .NET puro, entonces ¿Como puedo hacer aplicaciones para .NET puro usando DELPHI for .Net?.

Bueno, esas son algunas dudas que tengo y sería genial si alguien nos explicara, ya que ahora siento que es interesante esta tecnologia, pero tantos terminos de este tipo (Que parecen que todos llevan a lo mismo, pero al final no) me desaniman un poco, muchas gracias amigos :).

Varias cosas:

- Con todo respeto al usuario que arranco el hilo, fue una terrible apuesta darle a Winforms. Primero, hace *años* que se sabia que MS lo hiba a anular -o en una expresion politicamente mas correcta, lo hiba poner "deprecated" o seria un api inferior y sin mucho futuro- en favor de avalon/wpf. Segundo, Winforms es super-lento. Lento con lentitud abismal. Es un API que carece cualquier optimizacion via hardware - lease mi tarjeta grafica nvidia quadro fx 1500 con sus 256 de ram, una profesional que renderea del carajo y soporta resoluciones brutales, sirve para 3 cosas con winforms: Nada, nada y adorno. Para .net 1.1 y cuasi-2.0 solo habian 2 rutas para una gui con desempeño: La manged direct x api y tirar puro pinvoke .... y la vcl.net. Por eso, nada, nadita, en vista fue con winforms - y si lo recuerdan lo que se estaba haciendo en winforms de cliente se cancelo en las primeras alphas, y no fue por el asunto de la memoria, fue desempeño visual-

El asunto es que era *totalmente* claro desde el principio que era una ruta sin futuro. Y de principio me acuerdo que fue cuando arranque con este rollo del .NET - beta 1, algo asi-. Eso es como 3 años ya?

Ahora, desde la version 3.0 - perdon, la mismita 2.0 con librerias adicionales - todo es http://www.microsoft.com/spanish/msd...ducingwpf.mspx.

- CodeGear anulo el soporte a Winforms porque:

1. Como aclare, era un api sin futuro. Desde hace ya 2 años MS habia especificado que el soporte que daria era poder embeer winforms en avalon. O sea, parecido a los activex. Les suena una idea agradable?

2. MS, perdon, el equipo de VS.NET tiene *adueñado* el asunto de los designers graficos, primero de la Compact framework (desde VS 2002) y luego de Winforms (a partir de VS 2005), lo raro es que el equipo de .NET - entiendase, MS tiene varis paises bajo su confederacion que tienen actitudes diferentes - detesta esa actitud y por eso tienen todo el API del sdk lo mas completo posible, pero por politica se decidio que los designer era de VS.

Eso quiere decir que NADIE QUE CREE UN IDE COMPETIDOR puede usar esos designers porque el sdk de .net no los tiene. Ante la disyuntiva y luego que fue claro con el asunto del CF que el equipo de VS.NET lo hiba a soltar -por eso es que ni SharDevelop ni CodeGear ni nadie, ni siquiera RemObjects tienen designers para CF- codegear vio dos caminos:

- O replica los designers, de los cuales el unico con futuro seria el del CF
- O los tira al olvido, y sigue de frente con la vcl.net y le da mas fuerza a que sea portable entre los distintos ambientes, que es lo que estan haciendo (que seria una cosa analoga con respecto a la MFC)

Con respecto a WPF, que si le dan una mirada veran que *si* es algo revolucionario, ya que es un lenguaje XML no hay riesgo de quedar con burro amarrado. CodeGear ya aclaro que hara que la VCL.NET tenga la opcion de correr sobre WPF en el futuro para salvar otra vez al mundo de otro cambio de API sin necesidad., y lo digo, porque desde las betas de .NET 1.0 ya se sabia como seria el asunto de la WPF.

En total:

- Winforms estaba muerto antes de nacer
- VCL.NET sera la misma VCL, es mas rapida, esta mas probada
- Avalon/WPF es el futuro en .NET, y tiene menos riesgo de volverse obsoleto en los siguientes 2-3 años. Por lo menos el lenguaje es mas portable
- Si es hacer aplicaciones GUI, a menos que sean internas, es bobada hacerlas en Winforms. Y de hacerlas en WPF, hay que tener en cuenta que es un API que sirve si hay aceleradora grafica porque esta basado en DirectX. Afortunadamente, DirectX es una cosa bien hecha. Desafortunadamente, tiene que ser directX muy nuevo - no recuerdo si es la 10 o con la 9????-

Esa es la razon mis señores, por las que todo el mundo que tiraba a .NET lo hacia hacia ASP.NET o servicios web, y se dejaba los proyectos con GUI para aplicaciones internas. Hay que meterse en la cabeza y a palazos que .NET es un Java, y al igual que fue una perdida de tiempo darle a Java/Gui al incio, igual fue con .NET.

Queda parecida, mejor dicho, igual a Win32. Porque la VCL se saltea el GDI+ -que es la vaina relenta que les habia contado- y lo tira por el api nativo de windfows.

No.

Pues, mira que dice VCL. Si es vcl, no es winforms.

Sin usar la vcl ni niguna libreria de CodeGear. Totalmente lograble y para nada complicado. Pero es como : es posible hacer una app. win32 pura? Si, pero es mas dificil y para eso se hizo la vcl. El punto que hay que recordar es que NO EXISTEN APP :NET PURAS. Tarde o temprano -muy temprano a veces- hay un pinvoque por alli haciendo sus cosas para que sea mas rapido. .NET corre sobre Win32/64.

Toma ya !!

Si esta misma explicación me la hubieras dado hace tres años, te lo hubiera agradecido, ya que entonces yo mismo andaba perdido sin saber cual de las opciones elegir.

Veo que ya han respondido a Jhonny, si no lo hubiera hecho yo en la medida de mis posiblidades.

no hay winforms
 

Gracias mamcx, tus comentarios como siempre, son con mucho contenido.

Lamento mucho que sucediera lo que sucedió... lamentablemente, en el trabajo que realizo, estabamos esperando Delphi 2007, para migrar nuestras aplicaciones a .NET 2.0, y utilizar sus nuevas características, pero bueno... Me imagino que algo ya tendremos que hacer para no morir, junto con esa versión de DELPHI.

Me parece que se pone algo inestable y un poco riesgoso apostar por delphi en proyectos a largo plazo. (desde mi punto de vista)

[gluglu], estoy en tu misma posición... si esa explicación la hubiese tenido hace años.... :D

Saludos.

Por fin, por fin... :D, mamcx, muchas gracias por aclararme esas dudas... ahora si que se me a aclarado el panorama, ya entiendo porque alguna vez citaste a Joe para conlcuir que la VCL.Net es la misma VCL pero para .NET, ya entiendo porque esta tan relacionado el hecho de que la gente que programa para .NET este muy metido en el cuento de ASP.Net, Ya entiendo porque el CF no lo tiene CodeGear, y como ya habia leido algo del WPF pues acabas de complementar dicha lectura que por ahora la tenia en Stand By :).

De nuevo gracias mamcx, realmente he aprendido mucho de tus comentarios :).

radalvaro, es importante notar que IGUAL es un camello migrar a winforms 2.0:

http://blogs.msdn.com/tims/archive/2...20/188775.aspx
No hay un paso simple. Se movieron muchas cosas. En un proyecto de gran tamaño que hice en asp.net 1.1 la migracion a 2.0 requeria tocar casi la mitad de las lineas de codigo, todos los designers, el wizard -si hay un wizard de migracion ya es malo- obvio no sirvio para nada. Eran como 5.000 errores y warnings que limpiar, la mayoria en los controles y aspx pero muchos tambien en la logica de negocios. Se llego a la conclusion que de ser asi arrancabamos de nuevo y se copy-paste lo que se pudiera.

No creas que por tener winforms 2.0 la cosa te sale asi de facil.

Mi recomendacion? Sigan con lo que tienen, si igual les da resultado. Espero que para estas alturas tengas separada la GUI del resto, de ser asi, se puede meter los formularios en DLL e invocar desde alli: no es dificil. Pasar la logica a ensamblados de 2.0 e ir dando pasito a pasito. Si no se quiere vcl.net ir mirando la WPF.

Pero tirarse a VS.NET seria mas suicida en mi opinion. Y creo que la historia ha probado que Delphi es una apuesta segura en cuanto a la estabilidad general del lenguaje y del framework. O mejor dicho, que MS no es una apuesta segura porque cambia de parecer cada 2-3 años - o nadie se acuerda que ADO seria el fin de las librerias de acceso a datos y que integraria en un solo API todo eso? pues miren que es ADO.NET : TODO lo opuesto. Y miren lo que es linq: Aun mas distinto que ADO.NET.

Con base en eso, cuando este año arranque mi segunda empresa http://www.elmalabarista.com decidi irme por python y delphi. Y .NET, si lo piden -mas biuen para hacer aplicaciones para pocket pc, y la verdad que me gustaria otra cosa... sueño cuando lazarous sea maduro para eso-

mmm... yo no opino lo mismo...

Lo riesgoso fue apostar por WinForms, no por Delphi, y más si ya se sabía que estaba destinado a desaparecer...

Hasta ahora Borland/CodeGear a dado buen soporte hacía atrás en lo que se refiere al lenguaje Delphi... ;)


Saludos...

Por mi parte reitero mi ofrecimiento de disculpa, siempre pense que era lo mismo.:(

Salud OS

Tranquilo egostar, no eres el unico :D

Me has aclarado bastantes cosas.
Gracias.

Abusando un poco mas de tus ideas ¿ que harías si tuvieras delphi 2006 y estuvieras pensando en hacer / rehacer un desarrollo de win32 para un presente / futuro mas o menos cercano ?

Actualizar a Delphi 2007 (rad studio) ?
Pasarte a una opción como chrome (Joyride)?
Seguir programando para win32 ?
Pasarte a vcl.net e ir mirando wpf ?
¿ pasarte a vs 2005 /vs 2008 ?

Por cierto, que opción has escogido tu / tu empresa ?
¿ les va bien ?

¡Hola!

Bueno, entonces queda claro que el de mayor responsabilidad en esto es Microsoft y no CodeGear. También yo discrepo de lo dicho por radaalvaro, lo riesgoso es apostar por tecnologías que no están maduras, en este caso fueron las primeras versiones de .NET. Creo que hice bien en esperar para interesarme por esta tecnología.

Ya llegó mi momento de echarle un vistazo a una versión Delphi 2005+, en este caso el nuevo RAD Studio 2007. Lo primero que buscaré es si todavía tiene la función _CopyObject en System.pas. Espero que haya algún enlace para descargar una versión de prueba.

Un abrazo maduro.

Al González. :)

Las versiones de prueba estan en http://www.codegear.com/downloads/free ;)

Hola a todos,

vamos aclarar este tema.

Si, RAD Studio 2007 no va soportar mas C# y no va mas soportar Winforms en el lado de Delphi .NET

Porque hicimos esto, vamos a tener 100% foco en la lenguaje Delphi e en la VCL.

Winforms es una tecnología para desarrollo para escritorio en .NET, la VCL.NET hace la misma cosa y mucho mejor, entonces fuerzas en la VCL.NET

CodeGear va soportar o que considera mejor en .NET, así si necesitas desarrollo para escritório en .NET y VCL.NET es la mejor opción y si necesitas desarrollo para WEB en .NET ASP.NET es la mejor opción.

La prioridad en las proximas versiones es soporte Unico, mejorías en Win32 y portabilidad de la VCL para Win64, así la prioridad es Native Development.

Si quedo alguno duda, estoy por aquí.

Saludos a todos,

Andreano Lanusse
CodeGear Product Line Manager & Evangelist Leader Latin America
Blog: http://blogs.codegear.com/andreanolanusse
Ejemplos: http://cc.codegear.com/Author/38483

Bueno, solo quiero decir que menos mal tome la misma decisión que Al González, aunque al parecer ahora tengo que ponerme al tanto del asunto del .NET, debo estar agradecido de que nunca use los WinForms, de lo contrario estaria llorando en este momento.

Una pregunta, ¿CodeGear tiene pensado en hacer algo parecido o incorporar alguna tecnica para usar el WPF?, me parece muy interesante trabajar de la mano con un verdadero diseñador grafico, eso es estupendo.

Otra pregunta, asi sea que Microsoft no suelte el CF (Compact framework), ¿CodeGear piensa hacer algo para los PDAs, asi no sea con el CF?

¿Qué es WPF? :confused:

WPF es Windows Presentation Foundation, te recomiendo leer ese articulo para que comprendas el asunto, se ve divertido :).

WPF es parte del .NET 3, donde RAD Studio soporta, todavía hacer algo con WPF es estar mui amarado a Microsoft, Delphi tiene como principio integrar tecnologías y no quedar preso a una.

Estamos estudiando la posibilidad de desarrollo nativo para PDA

Hola,

Pero todas dentro de un mismo sistema operativo. Por cierto, Andreano, ¿sabes algo de Kylix? ¿Sería posible su recuperación? ¿Es un proyecto definitivamente abandonado? ¿Prepara CodeGear otro asalto al escritorio de Linux? Je, je, je... Gracias de antemano por tus respuestas. :)