RAD Studio XE2 disponible

[evarisnea]

Nouvelles versions « XE2 » de RAD Studio, Delphi et C++Builder
"La plus importante mise à jour fonctionnelle de ces dix dernières années" selon Embarcadero

Article complété le 05/09/11 par Gordon Fowler

Embarcadero Technologies vient d'annoncer le lancement de la nouvelle version XE2 de sa suite d’outils de développement RAD Studio, « la plus importante mise à jour fonctionnelle de ces dix dernières années ».

RAD Studio XE2 intègre les nouvelles versions d’Embarcadero Delphi, C++Builder, Embarcadero Prism et RadPHP.

Les principales nouveautés concernent le support complet Windows 64 bits de Delphi, le support complet Mac OSX et iOS avec la nouvelle plateforme pour applications métier riches FireMonkey, et le développement iOS et Android (applications web et mobiles) avec RadPHP XE2.

L’ajout très du support 64 bits de Delphi permet de mettre à jour les applications Windows VCL pour exploiter tout le potentiel des équipements hardware 64 bits, gérer de plus grands volumes de mémoire et s’intégrer avec les autres applications 64 bits.

L’une des principales nouveautés intégrées à Delphi XE2 et C++ Builder XE2 est FireMonkey, première plateforme pour applications riches fonctionnant nativement sur CPU et GPU, et conçue pour créer des applications métier.

Avec FireMonkey, les développeurs Delphi et C++Builder peuvent bâtir des applications HD et 3D avec une nouvelle expérience visuelle, et en s’appuyant sur les bases de données d’entreprise telles qu’Oracle, Microsoft SQL Server, IBM DB2, Sybase etc.

Les applications FireMonkey fonctionnent nativement aussi bien sur PC que sur Mac, et exploitent les capacités GPU modernes pour visualiser les données et les interfaces utilisateur avec un meilleur niveau de détail et des performances inédits.

FireMonkey permet également aux utilisateurs Delphi XE2 de créer des applications natives HD et 3D pour les terminaux mobiles (iOS).

De leur côté, Delphi et C++Builder proposent une approche native du développement applicatif, tandis que RadPHP XE2 porte les développements et applications web sur les appareils mobiles.

Avec RadPHP XE2, les développeurs peuvent créer des applications web avec des fonctions tactiles et des UI adaptées aux smartphones et aux tablettes. « Les développeurs ont la possibilité de développer leurs applications web mobiles en tant qu’application native pour l’AppStore iOS d’Apple et l’App Marketplace d’Android », explique Embarcadero. « Ils peuvent utiliser directement les équipements mobiles tels que les appareils photo, les GPS et les accéléromètres dans leurs applications web mobiles ».

« RAD Studio XE2 permet aussi bien de moderniser les applications Windows plus anciennes que servir de plateforme pour créer de nouvelles applications métier de prochaine génération pour les plateformes et les appareils les plus utilisés, » se félicite Michael Swindell, vice président sénior en charge du Marketing et des Produits chez Embarcadero Technologies.

Les versions d'évaluation sont disponibles ici :

RAD Studio XE2 Trial (la gamme complète)
Delphi XE2 Trial
C++Builder XE2 Trial
RadPHP XE2 Trial
Embarcadero Prism XE2 Trial


Et vous ?

Alors, qui l'évalue ou le télécharge déjà ?

Et aussi :

La fiche technique de RAD Studio XE2 (le PDF)
La liste des fonctionnalités Delphi XE2, (le PDF)
Une première présentation de Delphi XE2

Liste des nouveautés additionnelles :

Delphi XE2 et C++ Builder XE2 :

• Delphi XE2 intègre Windows 64 bits pour FireMonkey, compilateur, débogueur, RTL et VCL.
• dbExpress offre une nouvelle connectivité avec InterBase XE, FireBird 2.5, SQL Anywhere 12 et ODBC.
• Les nouveaux connecteurs mobiles DataSnap apportent des composants et des exemples plateforme pour créer des clients mobiles connectés avec les serveurs Delphi DataSnap d’Android (Java), iOS (Objective C), Blackberry (Java) et Windows Phone 7 (C#).
• Les outils nouveaux et mis à jour élargissent le périmètre fonctionnel, incluant FastReport pour la conception et la génération rapide de rapports ; Documentation Insight, outil de documentation de code source pour Delphi ; et les versions 64 bits de TeeChart, IBX, InstallAware, IP*Works, AQtime, FinalBuilder, IntraWeb et Indy. TeeChart, Indy et FinalBuilder ajoutent également le support Mac.
• De nouvelles fonctionnalités d’audit de code et de mesure de la qualité logicielle sont intégrées dans C++Builder XE2.
• LiveBindings permet aux utilisateurs de connecter n’importe quel type d’information à n’importe quelle interface utilisateur ou objet graphique FireMonkey. Les utilisateurs peuvent lier les données live à des contrôles d’interface utilisateur standards, des graphiques HD ou 3D pour créer de nouvelles manières de visualiser n’importe quel type de données.

RadPHP XE2 :

• Développement web mobile optimisé et intégré
• Déploiement d’applications web, iOS ou Android
• Extension de la gamme de composants Zend Framework

Embarcadero Prism :

• Nouveau .Net Oxygen Compiler 5.0 de RemObjects
• Implémentation d’interface anonyme
• Outil de reporting FastReport.net

[CapJack]

Ça y est, c'est fait.

Bon, ça promet pour la suite, j'ai déjà mis 20 minutes pour comprendre comment compiler en 64 bits.

J'en dirai plus plus tard. En tout cas, ça marche !

Edit : deux directives utiles pour bien commencer, que je viens de tester :

Code :

1
2
3
4
5
6
7
 {$IFDEF VER230} // Comme prévu
    ShowMessage('VER230');
 {$ENDIF}
 
 {$IFDEF Win64} // Ben ouais... 
    ShowMessage('Welcome to 64 bits!');
 {$ENDIF}

Edit 2 :
Bon, alors quelques premières impressions.

Il y a dorénavant deux frameworks, la VCL et la FMX (FireMonkey).

La VCL : n'est pas multiplateforme, mais elle a été portée en 64 bits, ce qui permet dorénavant d'écrire des applications pour les versions 64 bits de Windows.

Rien de spécial à en dire, le choix d'avoir gardé les types génériques (comme Integer) à leur taille traditionnelle s'avère pertinent. La plupart de mes anciennes unités déjà adaptées à l'Unicode se sont recompilées sans problème. Toute application se compilant correctement sous Delphi 2009/2010/XE devrait s'adapter très facilement (à moins que vous ayez des typecasting pointer/integer à chaque ligne ). Seule particularité notable, l'apparition des espaces de nommage, qui nécessitera de retravailler les clauses uses, ce qui nous amène à des solutions du type :

Code :

1
2
3
4
5
  {$IFDEF DCC} // Delphi XE2 Win 32/64
   uses WinAPI.Windows, System.SysUtils, VCL.Forms;
  {$ELSE} // Delphi other
   uses Windows, SysUtils, Forms;
  {$ENDIF DCC}

(la directive DCC fait sa première apparition (nouveau compilateur), donc ça me paraît la plus simple à utiliser).

À noter :

• l'intégration d'un système de thèmes basique mais efficace.
• On ne plaisante plus avec les paquets : l'EDI restant 32 bits, il faudra se contraindre à faire une version conception, et un version exécution séparées (ce que personnellement je n'ai jamais fait , et vous ?).

La FMX : me laisse dubitatif. Prévue pour le multiplateforme, le principe général est de fournir une interface graphique propriétaire, soit 2D, soit 3D, où tous les composants sont dessinés par l'application sans faire appel à l'API de l'OS hôte. Très bien, ça marche, les composants visuels classiques, bases de Données, Indy, etc. sont présents, un système de thèmes personnalisables différent de celui de la VCL offre beaucoup de perspectives, et apparemment on peut faire des choses incroyables avec des tas d'effets spéciaux.

Seulement voilà, certaines fonctions système d'usage courant sont inaccessibles, et rien ne les remplace.

À titre d'exemple, le manque le plus cruel pour moi (et la plus grande déception) est l'absence d'un composant du type TProcess de Lazarus, permettant de lancer un processus tiers à partir de l'application. J'ai cherché un peu partout sur le net, il n'y a rien. Pour le moment, impossible de lancer un utilitaire en ligne de commande à partir de son appli, fonctionnalité pourtant basique et fréquemment utilisée dans les environnements Posix/Unix me semble-t-il, ce qui fait que même pour MacOS, je ne crois pas que c'eût été un challenge insupportable pour les professionnels d'Embarcadero.

Alors oui, bien sûr, en terme d'interface, apparemment on peut faire des choses sympas, mais s'il manque des fonctionnalités système de base, pour moi ça reste une jolie démo...

Je suis sans doute un petit peu sévère, Embarcadero a focalisé son attention sur le spectre d'application le plus commun de Delphi (bases de données et connectivité), en y ajoutant des fonctions graphiques tout à fait innovantes.

Mais bon, je reste déçu, du coup.


Enfin, la documentation a besoin d'être terminée, car elle ne l'est pas, et ça, c'est un très mauvais point.


Restons quand même sur le positif : Delphi a de tout temps été un outil Windows, le passage au multiplateforme n'est pas simple, le travail accompli par les ingénieurs d'Embarcadero est remarquable, quant au passage au 64 bits, même s'il arrive avec 5 ans de retard, arrive quand même, et ça, c'est bien.

[skywaukers]

Bonjour,

Envoyé par CapJack

À titre d'exemple, le manque le plus cruel pour moi (et la plus grande déception) est l'absence d'un composant du type TProcess de Lazarus, permettant de lancer un processus tiers à partir de l'application. J'ai cherché un peu partout sur le net, il n'y a rien. Pour le moment, impossible de lancer un utilitaire en ligne de commande à partir de son appli, fonctionnalité pourtant basique et fréquemment utilisée dans les environnements Posix/Unix me semble-t-il, ce qui fait que même pour MacOS, je ne crois pas que c'eût été un challenge insupportable pour les professionnels d'Embarcadero.

A priori en ajoutant Winapi.Windows, Winapi.ShellAPI on peut faire appel à ShellExecute. Après il faut voir si on a accès aux api MacOS et si il existe un equivalent. Dans l'affirmative il n'est pas compliqué de se faire une petite unité avec les fonctions dont on a besoin et qui appelle la bonne fonction en fonction du type de compilation. De toute façon dès que tu va vouloir une particularité système, tu vas te lier à l'OS de destination.

@++
Dany

[CapJack]

Envoyé par skywaukers

A priori en ajoutant Winapi.Windows, Winapi.ShellAPI on peut faire appel à ShellExecute.

Bien sûr, pas de problème pour ça, j'ai ma bonne vieille usine à gaz rodée sous Windows, sauf que si on développe sous FMX, c'est pour faire du multiplateforme, donc Winapi verboten.

Envoyé par skywaukers

Après il faut voir si on a accès aux api MacOS et si il existe un equivalent.

Oui, justement, j'ai vu traîner un namespace Macapi dans les docs que j'ai pu lire... maintenant on ne peut pas tout connaître non plus, et je n'ai pas réussi à l'utiliser. J'attends de plus amples informations.

Envoyé par skywaukers

Dans l'affirmative il n'est pas compliqué de se faire une petite unité avec les fonctions dont on a besoin et qui appelle la bonne fonction en fonction du type de compilation.

Mon inquiétude, c'est si le nombre d'OS gérés dans le futur augmente. On ne peut pas tout connaître, à un certain moment ça devient un boulot d'ingénieurs... d'autant que la FMX, si on voit les choses sous un certain angle, ressemblerait presque à un mini-système d'exploitation, ou en tout cas à sa couche graphique.

Envoyé par skywaukers

De toute façon dès que tu va vouloir une particularité système, tu vas te lier à l'OS de destination.

On est bien d'accord, mais là où je suis (gentiment) en désaccord sur ce point précis, c'est que le pipelining entre processus n'est pas vraiment une particularité. Il est même très courant dans les univers Linux, et je suppose, BSD comme celui du Mac.


Note fantaisiste : c'est marrant de se mettre à parler Mac dans le forum Delphi !

[skywaukers]

Envoyé par CapJack

Mon inquiétude, c'est si le nombre d'OS gérés dans le futur augmente. On ne peut pas tout connaître, à un certain moment ça devient un boulot d'ingénieurs...

et bien voilà peut-être du boulot pour l'équipe du projet Jedi.

Envoyé par CapJack

Note fantaisiste : c'est marrant de se mettre à parler Mac dans le forum Delphi !

oui, et ce serait vraiment cool qu'on en discute de plus en plus Plus il y aura de compétence Mac présente, et plus on fera progresser notre IDE préféré

@++
Dany

[Franck SORIANO]

Envoyé par CapJack

Seule particularité notable, l'apparition des espaces de nommage, qui nécessitera de retravailler les clauses uses, ce qui nous amène à des solutions du type.

Ce n'est pas vraiment nouveau. Tu n'avais pas remarqué Generics.Collections en D2009 ?
Il me semble même en avoir déjà mis en Delphi 2006...
Ce qui semble changer, ce sont les noms des unités standards. Plutôt que de modifier les sources, on ne peut pas plutôt définir un Alias sur les noms des unités dans les options de compilation du projet (comme pour WinTypes=Windows, WinProcs=Windows, DbiTypes=BDE, DbiProcs=BDE, DbiErrs=BDE) ?

[CapJack]

La ligne "Alias" est toujours là, sauf qu'elle est vide par défaut.

Par contre apparaît une ligne "Nom de portée d'unités", voici ce qu'en dit l'aide :

Spécifie les noms de portées d'unités (préfixes) pour les espaces de nommage à points, pour vous permettre d'utiliser partiellement les noms qualifiés dans votre code, et dans votre clause uses ou #include.

Il existe deux façons d'ajouter un nom de portée d'unité :

Spécifiez le nom de portée d'unité dans votre clause uses ou #include. Par exemple :
uses Vcl.Graphics; (Delphi)
#include Vcl.Graphics (C++)
Ajoutez le nom de portée d'unité (Vcl.Graphics) au champ Noms de portées d'unités.
Le nom de portée d'unité Vcl est alors appliqué automatiquement aux noms d'unités qui appartiennent à cette portée d'unité, et vous pouvez simplement spécifier :
uses Graphics; (Delphi)
#include Graphics (C++)
Le bouton surgissant ouvre une boîte de dialogue <liste-ordonnée> pour la sélection et l'ajout de noms de portées d'unités, comme décrit dans Eléments communs des pages Options de projet et Boîte de dialogue liste-ordonnée.

C'est sans doute plus élégant de passer par là dorénavant.

C'est pour ça que je pense que c'est vraiment de la nouveauté, car il s'agit de vrais espaces de nommages, comme en .NET. Dans les versions antérieures, il me semble bien que si les noms d'unités pouvaient contenir un point, ça s'arrêtait plus ou moins là... j'exclue évidemment les versions .NET de Delphi, qui avaient elles aussi des espaces de nommage.

Maintenant, tout dépend du contexte. Si le but est de publier ou de distribuer une unité, il est toujours délicat de dire à l'utilisateur potentiel de changer les options de son projet, au risque que ça entre en conflit avec ses propres options.

Je suis plutôt partisan dans ce cas de mettre toutes les informations utiles dans le source. Dans ce cas, je dis bien.

[Gordon Fowler]

Notamment avec des commentaires d'Embarcadero et la liste des nouveautés additionnelles :

Delphi XE2 et C++ Builder XE2 :

• Delphi XE2 intègre Windows 64 bits pour FireMonkey, compilateur, débogueur, RTL et VCL.
• dbExpress offre une nouvelle connectivité avec InterBase XE, FireBird 2.5, SQL Anywhere 12 et ODBC.
• Les nouveaux connecteurs mobiles DataSnap apportent des composants et des exemples plateforme pour créer des clients mobiles connectés avec les serveurs Delphi DataSnap d’Android (Java), iOS (Objective C), Blackberry (Java) et Windows Phone 7 (C#).
• Les outils nouveaux et mis à jour élargissent le périmètre fonctionnel, incluant FastReport pour la conception et la génération rapide de rapports ; Documentation Insight, outil de documentation de code source pour Delphi ; et les versions 64 bits de TeeChart, IBX, InstallAware, IP*Works, AQtime, FinalBuilder, IntraWeb et Indy. TeeChart, Indy et FinalBuilder ajoutent également le support Mac.
• De nouvelles fonctionnalités d’audit de code et de mesure de la qualité logicielle sont intégrées dans C++Builder XE2.
• LiveBindings permet aux utilisateurs de connecter n’importe quel type d’information à n’importe quelle interface utilisateur ou objet graphique FireMonkey. Les utilisateurs peuvent lier les données live à des contrôles d’interface utilisateur standards, des graphiques HD ou 3D pour créer de nouvelles manières de visualiser n’importe quel type de données.

RadPHP XE2 :

• Développement web mobile optimisé et intégré
• Déploiement d’applications web, iOS ou Android
• Extension de la gamme de composants Zend Framework

Embarcadero Prism :

• Nouveau .Net Oxygen Compiler 5.0 de RemObjects
• Implémentation d’interface anonyme
• Outil de reporting FastReport.net

[Dogueson]

Envoyé par Gordon Fowler

Les outils nouveaux et mis à jour élargissent le périmètre fonctionnel, incluant FastReport pour la conception et la génération rapide de rapports

Ôtez moi un doute de l'esprit, Rave est toujours disponible ?

[skywaukers]

Bonjour,

Envoyé par Dogueson

Ôtez moi un doute de l'esprit, Rave est toujours disponible ?

Oui, je te confirme que Rave est bien toujours présent.

@++
Dany

[Gordon Fowler]

Pour ceux que cela peut intéresser, Embarcadero organise un rendez-vous ce 8 septembre à Paris autour de toutes ces nouveautés (dernière étape du CodeWay Tour 2011).

Et c'est gratuit :

Plus d'informations ici

[Dogueson]

Merci

[Jacques Deyrieux]

Fan de Delphi, développeur depuis 20 ans sur ces produits (Turbo Pascal 3, ça ne rajeuni pas! ;-) )

En plus :
- version particulièrement soignée techniquement. Très stable par rapport à Delphi 2006.
- L'apport de FireMonkey est indéniable. Il fera l'objet d'un échange très interessant entre les passionnés de la VCL et le nouveau modèle FMX. FMX n'est pas fait pour toutes les applis, sinon celles qui le sont doivent être repensées ergonomiquement.

En moins je dirai :
- pas de documentation sur FireMonkey. ET là c'est vraiment dommage pour un nouveau produit. Beaucoup de développeurs sont autodidactes.
- Problèmes de Layers sur les évènements OnMouseOver et le TFloatAnimation. Exemple: placez un TPanel, associez un TFloatAnimation qui change la Position.X. Enfin placez un bouton sur le TPanel. Lorsque vous glissez la souris sur le panel, il coulisse correctement, si la souris se positionne sur le bouton le panel revient à sa position d'origine (le TPanel nest plus ciblé)
- L'éditeur de style ne donne pas le résultat réel de l'aspect et du comportement du composant que l'on customize.
- La version Delphi est un peu lourde à charger (D2006 * 3), peut-être à cause de la version Trial ?


Voilà un petit avis sur cette mouture que je conseil à tous ceux qui veulent vraiement s'amuser dans le développement.

[Andnotor]

XE2 intègre-t-il enfin un éditeur de manifest ?

[CapJack]

Question (bête, sans doute, comme d'hab... ) :

Je suppose que ce n'est pas inclus dans la version "allégée", ça me paraît logique, mais sait-on à partir de quelle version de Delphi XE2 le code source de la VCL et/ou de la FMX est livré avec la distribution, s'il l'est ?

[skywaukers]

Bonsoir,

Envoyé par CapJack

Question (bête, sans doute, comme d'hab... ) :

Je suppose que ce n'est pas inclus dans la version "allégée", ça me paraît logique, mais sait-on à partir de quelle version de Delphi XE2 le code source de la VCL et/ou de la FMX est livré avec la distribution, s'il l'est ?

j'ai les sources dans la version "professionnel".

@++
Dany

[CapJack]

Les deux ? Merci pour la réponse.

[colfire_dev]

En tout cas, nous vivons une renaissance de Delphi.
Notre manière de programmer se verra changée en utilisant FMX, du Delphi flashy.
Les performances du GDU face au CPU sont impressionnants.

Pour moi, il y a eu Delphi 1 puis Delphi XE2

[Paul TOTH]

Envoyé par colfire_dev

En tout cas, nous vivons une renaissance de Delphi.
Notre manière de programmer se verra changée en utilisant FMX, du Delphi flashy.
Les performances du GDU face au CPU sont impressionnants.

Pour moi, il y a eu Delphi 1 puis Delphi XE2

tu pourrais au moins mettre Delphi 2 pour le 32 bits

et Delphi 4 ou 5 pour les tableaux dynamiques qui sont bien pratique.

Ensuite chaque version à son intérêt mais ça ne touche pas tout le monde (ADO, dbExpress, CLX, UML, .Net, RaveReport, Unicode, ...)

[skywaukers]

Bonjour,

Envoyé par CapJack

Les deux ? Merci pour la réponse.

Oui, les deux

@++
Dany