FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#41
|
|||
|
|||
Cita:
Podemos retomar Kylix si, estamos esperando el crecimiento de Linux en Desktop. |
#42
|
||||
|
||||
Hola,
Cita:
Cita:
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... Última edición por dec fecha: 21-09-2007 a las 23:07:40. |
#43
|
|||
|
|||
Cita:
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. |
#44
|
||||
|
||||
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 .
__________________
Lecciones de mi Madre. Tema: modificación del comportamiento, "Pará de actuar como tu padre!" http://www.purodelphi.com/ http://www.nosolodelphi.com/ |
#45
|
|||
|
|||
Entendido... Winfowms, no esta mas.
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. |
#46
|
||||
|
||||
Hola,
Cita:
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... |
#47
|
|||
|
|||
Interrogante
Cita:
Cita:
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) ??? Cita:
Gracias DEC, por contestar. |
#48
|
||||
|
||||
¡Hola a todos!
Cita:
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, 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. |
#49
|
|||
|
|||
Muchas Gracias Al Gonzáles...
Me parece muy buena justificación de VCL.NET sobre VCL. gracias nuevamente. Saludos. |
#50
|
||||
|
||||
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/
__________________
El malabarista. |
#51
|
||||
|
||||
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 .
__________________
Lecciones de mi Madre. Tema: modificación del comportamiento, "Pará de actuar como tu padre!" http://www.purodelphi.com/ http://www.nosolodelphi.com/ Última edición por jhonny fecha: 24-09-2007 a las 18:11:00. Razón: Colocarle un poco de formato y corregir algunas palabras |
#52
|
||||
|
||||
Algo que no tiene la VCL win32 y la VCL.NET si tiene
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/...COIVIntro.html ECO IV development http://video.codegear.com/RADStudioD...O/ECODemo.html |
#53
|
||||
|
||||
Por lo que sé, si una aplicación funciona en Mono también funciona en .NET, pero lo contrario no siempre es cierto.
|
#54
|
||||
|
||||
Cita:
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 |
#55
|
||||
|
||||
Lo siento Jhonny no me habia dado cuenta que te habian respondido.
Saludos |
#56
|
|||
|
|||
Cita:
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 Exemplos: http://cc.codegear.com/Author/38483 |
#57
|
||||
|
||||
Gracias rruz .
__________________
Lecciones de mi Madre. Tema: modificación del comportamiento, "Pará de actuar como tu padre!" http://www.purodelphi.com/ http://www.nosolodelphi.com/ |
#58
|
|||
|
|||
Cita:
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. |
#59
|
|||
|
|||
No me convence RAD Studio
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).
|
#60
|
|||
|
|||
Cita:
|
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Delphi 2005 vs Visual Studio C# .NET | REHome | .NET | 43 | 09-01-2008 13:51:02 |
Codegear publica la ayuda de la VCL de delphi 2007 Win32 en PDF | rruz | Noticias | 1 | 28-06-2007 03:26:17 |
Delphi 5 vs Borland Studio | Moparova | Varios | 3 | 19-04-2007 23:52:09 |
Delphi 8 vs Visual Studio. | AngelMarvin | .NET | 7 | 29-10-2004 21:22:33 |
Delphi 7 Studio y .NET | kukinn | Varios | 3 | 04-11-2003 03:22:25 |
|