Incluir Delphi windows .NET en RAD Studio CodeGear

[jholgado]

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.

[jhonny]

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 .

[[egostar]]

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

Lee

Delphi "Highlander" y Delphi "Tiburón"

[radaalvaro]

Empezado por jholgado

En el nuevo RAD Studio 2007 de CodeGear, se ha eliminado los proyectos Delphi Windows form .NET

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.

[dec]

Hola,

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

[jhonny]

Empezado por dec

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.

[[egostar]]

Pues lo dicho, leyendo he visto esto.

Empezado por CodeGear

CodeGear RAD Studio ofrece programación en Delphi® for Win32®, C++Builder® y el nuevo Delphi .NET 2.0 en un entorno integrado. Es la única solución para entornos de desarrollo integrados (IDE, por sus siglas en inglés) que es compatible con el desarrollo rápido de aplicaciones (RAD) nativas para Microsoft Windows, .NET, Microsoft Windows 2000, XP y Vista™. Esto permite a los programadores crear aplicaciones Web, cliente/servidor y de escritorio para Windows y liberarlas en cualquiera de las tres plataformas

Salud OS

[jhonny]

Empezado por egostar

Pues lo dicho, leyendo he visto esto.

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? ... es que como les dije, estos terminos siempre me han confundido

[radaalvaro]

Empezado por jhonny

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.

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.

[[Al González]]

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

[jholgado]

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.

[jhonny]

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 .

[mamcx]

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.

[[gluglu]]

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.

[avmm2004]

Empezado por mamcx

...... 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.

.

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 ?

[mamcx]

Empezado por jhonny

1. ¿Cuando uno hace codigo en VCL.NET queda parecido a una aplicación Win32 pero bajo .NET o eso queda en APS.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.

Empezado por jhonny

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

No.

Empezado por jhonny

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?

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

Empezado por jhonny

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?.

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.

[radaalvaro]

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....

Saludos.

[mamcx]

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

http://blogs.msdn.com/tims/archive/2...20/188775.aspx

The good news is that you can take any WinForms 1.x application and use it unchanged in the Whidbey environment using the existing controls. When you open a WinForms 1.x solution in Visual Studio 2005, the Visual Studio Conversion Wizard will kick in and offer to convert the project and solution files across to the new format, but it will leave the code completely intact. The old controls still exist, but are deprecated: for practical purposes, that means that they are not visible from the toolbox, but are available.

The bad news is that if you want to migrate a WinForms 1.x application to utilise 2.0 functionality today, you'll have to do a little work by hand. There are some controls that are fairly easy to upgrade (e.g. StatusBar -> StatusStrip), but others that are much harder (e.g. DataGrid -> GridView). One approach to see the changes between the controls is to compare the output from the designer tools. For example, toolbar separators are treated as a special kind of button in the ToolBar control, but exist in their own right as separate controls in the ToolStrip. These minor changes should be fairly easy to fix with search and replace or a sed-style script, however.

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-

[[maeyanes]]

Empezado por radaalvaro

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

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.

Saludos...

[jhonny]

Por fin, por fin... , 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 .