Incluir Delphi windows .NET en RAD Studio CodeGear

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

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

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

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

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

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

[[egostar]]

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

Salud OS

[jhonny]

Empezado por egostar

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

Salud OS

Tranquilo egostar, no eres el unico

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

[[Al González]]

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

[jhonny]

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

[[Andreano]]

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

[jhonny]

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.

[jhonny]

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?

[[Al González]]

¿Qué es WPF?

[jhonny]

Empezado por Al González

¿Qué es WPF?

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

[[Andreano]]

Empezado por jhonny

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.

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.

[[Andreano]]

Empezado por jhonny

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?

Estamos estudiando la posibilidad de desarrollo nativo para PDA

[dec]

Hola,

Empezado por Andreano

(...) Delphi tiene como principio integrar tecnologías y no quedar preso a una.

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.