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.....:rolleyes: ya le diste una leida al roadmap de estos productos.....:confused:

Lee

Delphi "Highlander" y Delphi "Tiburón" (http://dn.codegear.com/article/36620)

[radaalvaro]

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]

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.


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]

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

[egostar]

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

[Al González]

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

[radaalvaro]

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ó? :confused:

[radaalvaro]

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

[Al González]

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.

[radaalvaro]

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.

[dec]

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?

[Ñuño Martínez]

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

[gluglu]

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 :(

[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/msdn/articulos/archivo/231006/voices/introducingwpf.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]

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.


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


No.


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.


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

Saludos.

[jhonny]

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

[mamcx]

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

http://blogs.msdn.com/tims/archive/2004/07/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]

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]

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

Salud OS

Tranquilo egostar, no eres el unico :D

[avmm2004]

...... 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 (http://blogs.codegear.com/andreanolanusse)
Ejemplos: http://cc.codegear.com/Author/38483 (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? :confused:

[jhonny]

¿Qué es WPF? :confused:

WPF es Windows Presentation Foundation (http://www.microsoft.com/spanish/msdn/articulos/archivo/231006/voices/introducingwpf.mspx), te recomiendo leer ese articulo para que comprendas el asunto, se ve divertido :).

[Andreano]

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]

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,


(...) 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. :)

[Andreano]

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

Si, porque hoy Windows es el sistema operativo mas utilizado y 99% de los desarrolladores Delphi desarrollan para Windows.

Podemos retomar Kylix si, estamos esperando el crecimiento de Linux en Desktop.

[dec]

Hola,


Si, porque hoy Windows es el sistema operativo mas utilizado y 99% de los desarrolladores Delphi desarrollan para Windows.


¿Pero cómo se entiende esa frase con la que has dicho antes de que Delphi no quiere atarse a una tecnología? Habría que precisar ninguna tecnología, siempre dentro de Windows...


Podemos retomar Kylix si, estamos esperando el crecimiento de Linux en Desktop.


Eso podría verse de otro modo: "vamos a apoyar a Kylix, queremos que el escritorio de Linux avance". Son dos formas distintas de verlo, supongo. Aunque también supongo que si alguna vez hay mercado suficiente... como otras empresas, CodeGear también le entraría a Linux, vamos, digo yo...

Una cosa Andreano... no te pido que me respondas, pero, tampoco quiero dejar de preguntar, ¿qué hubiera sido de Kylix si hubiera pasado a ser un proyecto de código abierto? ¿Se han hecho estimaciones a este respecto? ¿No hubiera podido por ahí CodeGear sacarle algún rendimiento? Sobre todo, lo digo, porque ahora mismo parece que no le está sacando ninguno en absoluto...

[Andreano]

Hola,



¿Pero cómo se entiende esa frase con la que has dicho antes de que Delphi no quiere atarse a una tecnología? Habría que precisar ninguna tecnología, siempre dentro de Windows...



Eso podría verse de otro modo: "vamos a apoyar a Kylix, queremos que el escritorio de Linux avance". Son dos formas distintas de verlo, supongo. Aunque también supongo que si alguna vez hay mercado suficiente... como otras empresas, CodeGear también le entraría a Linux, vamos, digo yo...

Una cosa Andreano... no te pido que me respondas, pero, tampoco quiero dejar de preguntar, ¿qué hubiera sido de Kylix si hubiera pasado a ser un proyecto de código abierto? ¿Se han hecho estimaciones a este respecto? ¿No hubiera podido por ahí CodeGear sacarle algún rendimiento? Sobre todo, lo digo, porque ahora mismo parece que no le está sacando ninguno en absoluto...

Hola,

solamiente CodeGear no es suficiente para cambiar el mercado de Desktop, seria necesario un cambio de mercado en general, de muchas empresas que tienen poder de influencia en el mercado, juntas para que esto pase.

Sobre su pregunta se Kylix como un proyecto abierto, en mi opinión no tañeríamos excito, Eclipse hoy es un standard de IDE para otras plataformas, nosotros utilizamos Eclipse para JBuilder y ahora para 3rd Rail.

[jhonny]

Estamos estudiando la posibilidad de desarrollo nativo para PDA

Gracias por tu respuesta... Yo trabajo en una empresa donde la mayoria de los clientes son ganaderos, por lo cual, los vendedores deben ir muy lejos a realizar sus pedidos, seguramente un desarrollo nativo para PDAs sería una gran solución para mejorar el tiempo de respuesta a nuestros clientes, ya que no tendran que esperar para llegar a sus respectivas oficinas a digitar dichos pedidos previamente tomados en papel, ademas supongo que tendrian mas tiempo para ir a buscar nuevos clientes :).

[radaalvaro]

Bueno, ya me quedo claro... DELPHI WINFORMS.NET, no va mas.

Adreano... Hay una duda que me invade.

Que ventaja yo tengo al USAR VCL.NET, con respecto a la VCL normal??? (obviamente VCL.net va sobre el framework, es decir, necesita un intererprete, de modo que tiene una ligera desventaja contra el VCL nativo. entonces.

¿Que factores podrían hacer que yo elija VCL.NET, sobre VCL???

Saludos.

[dec]

Hola,


¿Que factores podrían hacer que yo elija VCL.NET, sobre VCL???


La VCL .NET se pensó (si no me equivoco, y según recuerdo de lo que leí hace tiempo) como una especie de transición al ".NET puro". Era una forma de envolver el .NET Framework en una especie de VCL, de modo que fuera, supuestamente, más sencillo migrar a .NET.

Ahora bien, si vas a utilizar .NET... si quieres desarrollar para esa plataforma, puedes usar Delphi .NET (entre otros lenguajes), directamente, contra el .NET Framework, no tienes porqué usar la VCL .NET, incluso tal vez no sea ni aconsejable.

¿Ventajas de la VCL frente a la VCL .NET? Bueno. La VCL también es una especie de envoltorio... del API de Win32. Pero la VCL produce código nativo, no código que tenga que interpretar ninguna máquina virtual (el Common Lenguage Runtime de .NET).

Ahora bien, se supone que el API de Win32 está condenado a desaparecer... y con él la VCL, si bien esto no va a pasar mañana ni pasado. Windows Vista, por ejemplo, parece que soporta sin problemas el API de Win32. ¿Y qué pasará en el futuro? ¿Habrá un Windows .NET? Eso leí alguna vez...

Si bien yo pienso que sería un suicidio por parte de Microsoft dejar de soportar el API de Win32 en uno de sus sistemas operativos, lo cierto es que una cosa no quita la otra: quizás todas las innovaciones no vayan a Win32. Quizás los tiros vayan por .NET (de algún modo es la apuesta de futuro), quizás...

[radaalvaro]

La VCL .NET se pensó (si no me equivoco, y según recuerdo de lo que leí hace tiempo) como una especie de transición al ".NET puro". Era una forma de envolver el .NET Framework en una especie de VCL, de modo que fuera, supuestamente, más sencillo migrar a .NET.


Hasta ahi, vamos bien, eso si lo sabia... eso lo tengo claro.


Ahora bien, si vas a utilizar .NET... si quieres desarrollar para esa plataforma, puedes usar Delphi .NET (entre otros lenguajes), directamente, contra el .NET Framework, no tienes porqué usar la VCL .NET, incluso tal vez no sea ni aconsejable.


Usé el mismo razonamiento que tu, al iniciar el proyecto que emprendimos en mi empresa... pero ahora, existe un problema... RAD STUDIO 2007 no trae .NET de forma nativa, si no solo con VCL.NET... de modo que jamas podremos llevar nuestro desarrollo a .NET 2.0 nativo. sin VCL.NET.

Por eso preguntaba... (PREGUNTA PARA TODOS) si solo nos dejaron esas opciones... en que casos yo preferiria usar VCL.NET a usar VCL nativa. o por que razones posibles una persona preferiria usar VCL.NET a VCL (queda como sobreentendido que uno esta sobre el .NET framework) ???


Ahora bien, se supone que el API de Win32 está condenado a desaparecer... y con él la VCL, si bien esto no va a pasar mañana ni pasado. Windows Vista, por ejemplo, parece que soporta sin problemas el API de Win32. ¿Y qué pasará en el futuro? ¿Habrá un Windows .NET? Eso leí alguna vez...


Eso si que no lo sabia.. voy a leer un poco mas al respecto.

Gracias DEC, por contestar.

[Al González]

¡Hola a todos!

...en que casos yo preferiria usar VCL.NET a usar VCL nativa. o por que razones posibles una persona preferiria usar VCL.NET a VCL (queda como sobreentendido que uno esta sobre el .NET framework) ???...
Básicamente, creo que las dos principales razones serían:

1. Integración (compatibilidad / conectividad) con otros sistemas o tecnologías basadas en .NET.

2. Asegurar más tiempo de vida, soporte y mejoras al software desarrollado, bajo el entendido de que .NET seguirá más que vigente cuando la API Win32 comience a ser etiquetada como obsoleta.

Y es que hay algo aquí que muchos no saben o ignoran a medias, y es que la VCL tradicional, al igual que muchas bibliotecas de clases y funciones "nativas" de las herramientas de programación de los últimos 10 o 20 años, encapsulan a las funciones de la API de Windows (Win32). Muchas de las maravillas que amamos de la VCL se deben a esos miles de funciones que Microsoft creó cuando la POO estaba en pañales. Y algunos de sus respectivos compiladores generan código máquina, caracterizado a veces con el término "ensamblador", el cual es ejecutado tal cual por un chip procesador.

Ahora, muchas de esas bibliotecas, en sus más recientes versiones, en lugar de encapsular llamadas a la API Win32, encapsulan a las clases de la "nueva API", conocida como .NET, y sus compiladores generan código de máquina virtual caracterizado con el término "ensamblados", los cuales quedan justo a un paso de ser código máquina-hardware. Por lo cual requieren un intérprete (término políticamente incorrecto por la mala fama de lentas que se ganaron aquellas herramientas que no generaban ejecutables auténticos, como Quick Basic, FoxPro y casi todos los lenguajes baratos de Microsoft de hace 15 años).

Como ya el hardware es muy rápido, la prioridad de conectividad / compatibilidad / integración pasa a tomar el primer lugar por encima de la antigua prioridad #1 que era la velocidad y ahorro de espacio. Antes los programadores se preocupaban por ahorrar hasta el último byte de memoria, porque 640 KB de RAM era como una cubeta de agua en las Dunas de Samalayuca (http://www.tarahumara.com.mx/asp/ms_lugares.asp?lugar=22), y 16 MHz de velocidad ameritaban resucitar a Albert Einstein para hacer de aquella función de búsqueda un endemoniado comparador de bits sin desperdicio de una sola instrucción de CPU.

Era obligado que algún día la hasta entonces eterna prioridad #2: facilidad para hacer e integrar software, se convertiría en lo más importante. Y es cuando surgen propuestas que antes hubieran parecido descabelladas o utópicas, como hacer programas independientes del sistema operativo (Java, .NET*) o ensamblables con programas hechos en otros lenguajes (.NET), o mejores APIs totalmente orientadas a objetos (Java, .NET).

Así pues, estos son los tiempos en que las tecnologías comienzan ese juego de coqueteo llamado "me conecto contigo, entiendo tu idioma". Después de todo, ¿quién quiere quedarse fuera de una fiesta, donde todos parecen estar pasándolo bastante bien? No se trata de alabar a Microsoft, no será gracias a esa empresa que algún día pueda tomar un teléfono celular y enviar un mensaje escrito a Japón sin problemas y con traducción automática. Falta más apertura* para llegar a ese punto. Pero el camino está iniciado. Java lo viene intentando, pero tiene una enorme desventaja en comparación a .NET: te obliga a usar un sólo lenguaje.

Muchos no simpatizan con .NET por llevar el desangelado estigma MS, pero ¿qué tal si .NET fuera de la compañía que más nos simpatiza (CodeGear, Google, Sun, Sistemas GH...)? .NET está irremediablemente destinado a abrirse, como sucede con toda tecnología útil que alcanza cierto nivel de aceptación, considerando que será el reemplazo lógico de la popular y aprovechada hasta la médula API Win32. Yo no pongo las manos en el fuego por él (ese puesto lo tiene Delphi) pero al día de hoy comienzo a interesarme en clavarle una bandera.

Un abrazo ensamblado.

Al González. :)

*.- La apertura tecnológica estandarizada de la que siempre he hablado. El futuro es el consenso, sin marcas, sin propiedad, sin imposiciones de mercado. Lo correcto antes que las ventas. Una nueva ISO que sustituya al manipulado organismo actual.

[radaalvaro]

Muchas Gracias Al Gonzáles...

Me parece muy buena justificación de VCL.NET sobre VCL.

gracias nuevamente.

Saludos.

[mamcx]

Una aclaracion:

Delphi.NET trae .NET nativo. La VCL.NET es un "wrapper" alrededor de la Win32 (para pintar controles rapidos, sin GDI+/Winforms) y las funciones normales que lo acompañan. Pero nada impide usar .NET de forma directa y es algo que se por experiencia propia en mi esfuerzo por desarrollar http://sourceforge.net/projects/mutis/

[jhonny]

Que bien todo me a quedado muy claro, de hecho la pregunta que planteo radaalvaro tambien y por consecuencia las respuestas, tambien me ayudaron bastante a entender el "porque" de elegir .NET por encima de Win32... pero ahora tengo otra duda, si yo instalo mono en mi Linux, ¿Puedo correr aplicaciones creadas en Windows bajo la plataforma .NET?, bueno, gracias por vuestro interes en el asunto ;) :).

[axesys]

Con la VCL.NET puedes desarrollar aplicaciones dirigidas por modelos usando el framework ECO aquí unos videos de como hacerlo

ECO VCL.NET development with CodeGear RAD Studio
http://video.codegear.com/RADStudio/ECOIVIntro/ECOIVIntro.html
ECO IV development
http://video.codegear.com/RADStudioDevDaysSep2007/ECO/ECODemo.html

[Ñuño Martínez]

pero ahora tengo otra duda, si yo instalo mono en mi Linux, ¿Puedo correr aplicaciones creadas en Windows bajo la plataforma .NET?Por lo que sé, si una aplicación funciona en Mono también funciona en .NET, pero lo contrario no siempre es cierto. :(

[rruz]

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


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 con el mismo look and feel de Win32 pero es una app tipo .net

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

Si usas los componentes Intraweb o la exportas como activex si puedes ejecutarla en un navegador.

sin embargo lo ideal es que uses file->New->ASP.Net web application.

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?

Es para crear una aplicacion DELPHI VCL NET , no Winforms.

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?

Las aplicaciones VCL.NET si son .NET "puro".


Saludos, espero haber clarificado en algo tus dudas

[rruz]

Lo siento Jhonny no me habia dado cuenta que te habian respondido.

Saludos

[Andreano]

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 con el mismo look and feel de Win32 pero es una app tipo .net

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

Si usas los componentes Intraweb o la exportas como activex si puedes ejecutarla en un navegador.

sin embargo lo ideal es que uses file->New->ASP.Net web application.

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?

Es para crear una aplicacion DELPHI VCL NET , no Winforms.

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?

Las aplicaciones VCL.NET si son .NET "puro".


Saludos, espero haber clarificado en algo tus dudas

1. Una aplicacion VCL.NET tiene la misma interfase que una aplicación Win32, mas abajo esta corriendo sobre .NET

ASP.NET es para generar solamente aplicación WEB.

2. No
RAD STudio trae la version de IntraWeb para .NET, que tu puedes ejecutar una aplicacion IntraWeb sobre .NET


3. Esta opción es para crear aplicaciones VCL.NET

WinForms no es productivo para el desarrollo Delphi, la VCL.NET es mucho mejor.

4. Aplicaciones VCL.NET son .NET puro, asi como las aplicaciones WinForms en Delphi.NET, VB.NET o C# son .NET puro, WinForms y VCL.NET tiene o que llamamos pinvoke que son llamadas directo a las apis Win32

Las aplicaciones VCL.NET corren sobre .NET, el grande diferencial de .NET está en ASP.NET, que es fácil desarrollar aplicaciones para WEB, RAD Studio 2007 trae total soporte a ASP.NET 2.0 que tiene muy buenos recursos.

Este mes vamos a tener "Delphi Revolutions Day en Mexico y Guadalajara - 16 y 18 de Octubre" donde vamos hacer el lanzamiento de RAD Studio 2007.

Le invito a participar e conozer todas las novedades de RAD Studio.

El registro está disponible en http://dn.codegear.com/es

Saludos,

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

[jhonny]

Lo siento Jhonny no me habia dado cuenta que te habian respondido.

Saludos

Gracias rruz ;).

[Andreano]

Bueno, ya me quedo claro... DELPHI WINFORMS.NET, no va mas.

Adreano... Hay una duda que me invade.

Que ventaja yo tengo al USAR VCL.NET, con respecto a la VCL normal??? (obviamente VCL.net va sobre el framework, es decir, necesita un intererprete, de modo que tiene una ligera desventaja contra el VCL nativo. entonces.

¿Que factores podrían hacer que yo elija VCL.NET, sobre VCL???

Saludos.

Podría ser la lenguaje, mas no, porque los nuevos recursos que creamos para Delphi .NET también hacemos para Delphi Win32.

En mi opinión desarrollo para escritorio recomiendo Win32, no recomiendo .NET.

La ventaja de tener la VCL es que su cliente exige que su aplicación sea .NET , tu tienes como compilar en .NET facilmente un proyecto VCL Win32.

[SMTZ]

RAD Studio parece que es una herramienta fantástica, pero sólo sirve para Windows. A ver si en "beyond commodore" sacan una versión de Delphi multiplataforma porque la mayoría de los grandes servidores no se basan en Windows, sino en HP-UX, Solaris, AIX, aunque esto no quiera decir que no hayan AS/400, Windows o Linux, por ejemplo. Esto quiere decir, que el número de desarrolladores de JAVA continuará por delante de Delphi (entre otras razones).

[radaalvaro]

RAD Studio parece que es una herramienta fantástica, pero sólo sirve para Windows. A ver si en "beyond commodore" sacan una versión de Delphi multiplataforma porque la mayoría de los grandes servidores no se basan en Windows, sino en HP-UX, Solaris, AIX, aunque esto no quiera decir que no hayan AS/400, Windows o Linux, por ejemplo. Esto quiere decir, que el número de desarrolladores de JAVA continuará por delante de Delphi (entre otras razones).

SMTZ, Java y Delphi, tienen sus áreas de acción. Si bien Java, es multiplataforma y esta es su mas grande ventaja, pero cuando alguien quiere desarrollar algo complejo, resulta que uno pasa la vida programando muchisimas líneas de código. Para hacer algo, que con Delphi se haria en menos tiempo, por que Delphi es un RAD, obviamente, como una gran mayor parte de los lenguajes de programación. Delphi esta avocada a desarrollar sobre la plataforma más difundida hasta ahora (Windows).Por otro lado, la versión de Delphi para LINUX (Kylix), empezo a volverse inviable por diferentes factores... imaginate hacer que el lenguaje pueda generar aplicaciones para AS/400, le iria peor que con KYLIX.Saludos.

[Al González]

¡Hola de nuevo!

...sacan una versión de Delphi multiplataforma porque la mayoría de los grandes servidores no se basan en Windows...el número de desarrolladores de JAVA continuará por delante de Delphi...

Sólo que Windows se usa en la mayoría de las computadoras de escritorio y Delphi nació como un lenguaje para crear aplicaciones "cliente", las cuales corren en ordenadores de ese tipo. Por ello decidieron que fuera para Windows, es una cuestión de lógica muy simple. Y, para ese propósito, sí que me convence a mí usar algo tan poderoso como Delphi, ámbito en el cual Java queda algo corto. Cuando veo una interfaz cliente hecha en Java, siento que se va a desarmar en cualquier momento, sin mencionar lo lentas que son.

La verdadera razón por la que aumentan los desarrolladores de lenguajes emergentes como Java es porque se incrementa la demanda de esos perfiles. Y si escarbamos un poco, nos damos cuenta de que dicha demanda obedece a dos factores que CodeGear habrá de atender tarde o temprano: precios bajos y multi plataforma. Así de sencillo. ¿Cuándo lo hará? (pero ahora sí, bien pensado); estimo que no llegaremos al 2010 sin algún anuncio positivo a ese respecto de parte de Scotts Valley.

Un abrazo convincente.

Al González. :)

[julyus]

tratare de explicar de la mejor manera que diferencia que hay entre vcl.net y .net, y el porque se decidio a incluir .net en los rad de Borland anteriormnete

vcl.net se desarollo como una estrategia de borland para trasladar a los programadores al mundo del .net sin necesidad de cambiar un poco los conceptos de programacion ya usados en las versiones win32 este leguaje soporta los dos tipos vcl y .net, los dos en el mismo codigo mas o menos eso es lo que hace para mi parecer, Segun borland era un trassicion entre el mindo win32 y el .net (mundos totalmente diferentes)

De todas maneras me parece que el compilar el lenguaje nativo que solo queda es el .net por que cuando pruebas el testing framework solo ves sentencias .net y nada de vcl (persiste el .net en nivel mas bajo sin importar el codigo delphi)

ademas en mi opinion creo que borland se dejo enfermar con la idea de M$soft de dejar el soporte de win32 para sus versiones futuras de su OS
se decia en tonces cuando saliera vista que era su primer sistema operativo 100% .net framework de pronto desapareceria el win 32 y el soporte win 32 seria un paquete solo para compatibilidad de programas y tardaria mas en salir

Esa fue la razon por que borland decidio incluir una version de .net, y como soporte a versiones anteriores metio su conocidisimo delphi ademas para mi fue mas que estrategia, un mensaje subliminal de todas manera aqui todavia estamos no se preocupen

al salir code gear quien retomo el delphi y M$soft obligado a dar soporte win 32 por ovias razones, se cambio la estrategia que a hora es liderada por code guear quien para su primer entrega de un RAD decide eliminar .net para no dejar ir a otro lenguaje a sus compradores y entusiastas por que se perderia la esencia y la diferencia que se marca en el mercado y tendria las dos opciones win32 y .net y el lenguaje es el mismo con algunas variantes muy minimas

detodas maneras ya para terminar mi consigna es gracias a que existen fuerzas mayores que nodejan a M$soft decidir sobre el futuro de la programacion y los paquetes estamos vivos y programando en el lenguaje que nos gusta DELPHI