Look app développées avec XE3 et Windows 8

Bonjour,
je me posais la question de la comptabilité Windows des applications développées avec XE3.
1/ Dans les autres versions les composants de la VCL encapsulent les contrôles Windows, mais il est relativement facile d'appeler les fonctions Windows manquantes (tel que le custom draw), etc... en passant le Handle du controle.
Du fait de la compatibilité de XE3 avec Mac OS je me demandais si on pouvait toujours faire ça facilement (et tant pis pour la compatibilité Mac bien entendu).
2/ Et si les contrôles sont toujours Windows natifs: héritant des thèmes,... bref qu'on ne fait pas la différence avec des applications développées avec par exemple Visual Studio.

3/ Aussi à propos de Windows 8. Il y a si j'ai bien compris 2 modes Windows différents : un mode classique, et un mode genre tablette (appelé Metropolis). Les applications développées avec XE3 sont elles compatibles avec les 2 modes ? Je veux dire pour un même exécutable, possibilité de le lancer quel que soit le mode de l'utlisateur.

Merci pour vos réponses.

Tu n'as pas lu la documentation ni même les nombreux blogs à ce sujet ?
Comme Colibri - Delphi XE3 Tour

Citation:

---

Envoyé par yarp

1/ Dans les autres versions les composants de la VCL encapsulent les contrôles Windows, mais il est relativement facile d'appeler les fonctions Windows manquantes (tel que le custom draw), etc... en passant le Handle du controle.
Du fait de la compatibilité de XE3 avec Mac OS je me demandais si on pouvait toujours faire ça facilement (et tant pis pour la compatibilité Mac bien entendu).

---

Si tu fais une application VCL, oui c'est comme avant

Si tu fais une application FMX, il faut éviter d'inclure des elements spécifiques à Windows si tu veux être multiplateforme,
Si tu fais du FMX pour Windows, tu peux faire des include genre Windows.h et accéder à tout ce que tu veux, FMX le fait lui même mais en gérant des directives de compilation ou en utilisant des classes d'implémentation différente selon l'OS ciblé

Par exemple, LoadLibrary fontionne sur Win et MAC, tu peux donc charger manuellement kernel32.dll, faire un GetProcAddress ... tu pourrais ainsi invoquer n'importe quelle API dont SendMessage, en déclarant tout manuellement SANS inclure d'unité Windows

Mais ce n'est pas nouveau, c'était le cas en depuis XE ou XE2 ! non ?

Citation:

---

Envoyé par yarp

2/ Et si les contrôles sont toujours Windows natifs: héritant des thèmes,... bref qu'on ne fait pas la différence avec des applications développées avec par exemple Visual Studio.
).

---

VCL oui, TWinControl, TGraphicControl comme avant mais tu as en plus un gestionnaire de thème qui permet de "skinner" toute ton appli

FMX non, c'est QUE du DESSIN !

Citation:

---

Envoyé par yarp

3/ Aussi à propos de Windows 8. Il y a si j'ai bien compris 2 modes Windows différents : un mode classique, et un mode genre tablette (appelé Metropolis). Les applications développées avec XE3 sont elles compatibles avec les 2 modes ? Je veux dire pour un même exécutable, possibilité de le lancer quel que soit le mode de l'utlisateur.

---

C'est un mode spécial à la création du projet !
Delphi XE3 émule l'aspect graphique Metro de Win8 pour les applications VCL
Pour FMX, cela reste du Dessin
Voir Développement des applications Metropolis UI

Citation:

---

Seules les applications de bureau Metropolis UI sont supportées dans XE3. Les applications mobiles Metropolis UI (et WinRT) ne sont pas actuellement supportées.

---

J'ignore totalement, si l'on peut passer d'une application VCL standard en bidouillant le gestionnaire de style pour utiliser l'un des 4 styles metro ou si c'est plus subtile que cela !


Pour WinRT le nouveau "noyau", c'est Visual Studio + Delphi Prism

J'ignore si Embarcadero prévoit de gérer, il faudrait considérer WinRT comme une plateforme à part entière au même titre que Win32, Win64 et MacOSX pour le Desktop et iOS ou Android pour les tablettes

Si j'ai bien compris WinRT devient la seule interface entre le programme et l'OS dans ce mode, c'est comme si Win32 n'existait pas !

Microsoft réinvente le .NET, ce dernier était prévu multi-plateforme mais comme ça marche pas ou qu'il a été trop spécialisé, ils ont pondu une nouvelle couche d'API (codé en COM à l'ancienne)

En gros, le message de MS au développeur :
Vous, les débiles, utilisez .NET c'est fait pour vous, :bebe:
Nous, les maîtres du monde, nous faisons ce que nous voulons comme nous le voulons :langue2:

Merci pour ta réponse si détaillée et pour les liens.
Je travaille toujours avec CBuilder 5 (c'est un utilitaire et ça passait encore bien avec Seven alors j'ai reculé l'évolution). Mais maintenant il est temps de faire le grand saut alors je vais étudier ta réponse en profondeur pour prendre une décision.

Je ne te pensais pas sur une si vieille version !
Je pensais que tu étais déjà au moins en 2009-2010 !

Avant même de penser à Metro UI, il faudra revoir la gestion du char, le type String passe de AnsiString à UnicodeString dans TOUTE la VCL !
Avant Char (Deplhi) et char (C) était compatible, ce n'est plus vrai en XE3, AnsiChar<->char et Char<->WideChar<->wchar_t

Si tu as bcp de code mélangeant VCL, STL et API Windows, cela peut être une certaine gymnastique, surtout qu'il ne t'avertira pas toujours que tu passe un wchar_t* au lieu d'un char*

Un ancien projet reste en API char
Un nouveau projet passera en API wchar_t
c'est une option qui décide du Mappage !

>Un ancien projet reste en API char
>c'est une option qui décide du Mappage

Ah bien. D'autant plus que c'est un gestionnaire de fichiers, mais d'un autre côté ça va m'obligerais là aussi à faire le saut Unicode. Je ne m'inquiète pas trop pour ça.

Le plus gros problème c'est en effet le mix entre API Win32 et VCL, et surtout la myriade de librairies C à recompiler (les ZLib, libjpeg, libpng, etc...).

Je viens de lire ta réponse en détail. Merci pour tes réponses et pour les liens, ça m'a beaucoup aidé à y voir clair dans l'offre Borland et sur W8.

XE3 me parait en effet convenir parfaitement. Maintenant que j'ai les bases je vais pouvoir creuser le sujet.