Installation de Delphi 10.4.2 CE

Bonjour,

suite à mes conversations avec Navyg et ses TGrids à colonnes fixes, j'envisage d'installer pendant quelques temps un Delphi 10.4.2 CE, la version la plus récente en Éditions communautaires. Seulement comme d'habitude, comme ce produit cible de nombreux OS, j'aimerais m'assurer avant de prendre "un petit peu de temps" pour l'installer qu'il cible mon OS mac actuel.
Je me suis attaché à synthétiser les cibles macOS possibles de la dernière version CE. [Sources : docwiki.embarcadero, wikipedia (Historique de Delphi) et un article embarcadero de mise à dispo de 10.4.2 CE]

J'ai rencontré le problème évoqué dans la discussion "macOS Monterey n’aime déjà plus les anciennes versions de Xcode" dans cette page. Évidemment, on peut configurer mac OS à la main pour régler ce problème mais ensuite les mises à jour automatiques de mac OS deviennent extrêmement pénibles et redemandent une post-configuration manuelle et chronophage. Pas du tout dans la philosophie Apple.

Donc ma question : J'installe Delphi 10.4.2 dans une machine virtuelle Parallels de mon mac OS Ventura. Je construit un petit projet FMX. Je cible mac OS... Et ? Je ne souhaite pas une réponse théorique mais un retour d'expérience : Concrètement, Delphi 10.4.2 cible-t-il la dernière version de macOS et iOS ?

Cordialement. Gilles

PS : Toujours aussi curieux cet affichage d'images dans le forum... Normalement je les ai insérées dans le message... On les voit, c'est déjà cela.

Hello

Le problème n'est pas réellement de cibler macOS/iOS dans leurs dernières versions mais de cibler la bonne version des outils de travail fournis par Apple avec Xcode.

Si tu n'as pas besoin de la dernière version de Xcode pour autre chose tu peux en télécharger une antérieure sur https://developer.apple.com/download/all/?q=xcode qui contiendra les SKD macOS et iOS ciblés par la 10.4.2 Sydney / Community Edition.

Pour la compilation Mac ça ne posera aucun soucis. Pour iOS c'est globalement cuit si tes appareils sont tous dans la dernière version.

Depuis macOS Monterey Apple est passé de Python 2.x à 3.x et manque de bol Python était utilisé par PAServer (avec des liens en dur) pour le déboggage. Donc plus de déboggage possible sauf bidouilles et réinstallation de Python 2.6 ou 2.7 (je ne sais plus) et adaptation des liens vers les DLL locales dans le package de PAServer.

Pour résumer, sans bidouille, faut pas trop compter cibler les dernières versions d'OS Mac.

Bonjour Patrick,
merci pour la réponse rapide.

Le vrai problème n'est pas réellement de cibler de vieilles versions, sauf avec Delphi CE qui l'impose dans les faits. Je parlais de "philosophe Apple" dans un autre message. Avec Apple, les versions des OS se succèdent rapidement mais quand tu achètes un appareil, il est compatible très longtemps avec les versions successives de l'OS. Les mises à jour sont gratuites. Si tu ne bricoles pas ton mac comme un Windows, les mises à jour sont automatiques... Donc dans la pratique, une très grande majorité des possesseurs de matériel Apple dispose de la dernière mouture de leur OS favori. le ciblage de vieille version est donc très limité. Rien à voir avec le monde Windows.

Donc c'est ici purement un problème de la plus récente version Delphi CE qui ne bénéficie pas des mises à jour nécessaires pour suivre (i.e. rester compatible avec) les OS cibles du moment. J'ai récemment rencontré le problème avec un autre framework dans un cas particulier pour un appareil Apple à processeur intel (un mac mini Late 2014 avec une Big Sur).
Pour les puces intel, c'est jouable autrement que de faire coexister plusieurs xCode, Python... dans une seule version de mac OS... mais il faut beaucoup de RAM. Voila comment j'ai procédé :

1. Tu installes sur ton Mac Intel, un Windows 10 en dual boot (impossible actuellement avec les puces ARM d'Apple),
2. Tu lances Windows et installe vmWare
3. Tu crées avec les iso les machines mac OS dont tu as besoin [c'est légal puisque tu installes une VM mac OS sur un ordinateur Apple... mais même avec 32 Go cela se traine un peu et ce n'est pas toujours stable] :

Pièce jointe 633494

4. Avec ton FMX installé sur ton Windows, tu ciblerais la machine virtuelle dont tu as besoin. (Dans mon cas, j'ai installé directement la version encore disponible du framework utilisé sur Big Sur)

C'est également du bricolage mais, au moins, tu n'impactes pas le mac OS de ton poste de développement. Mais ce que j'aimerais que vous compreniez sur ce forum très "windowsien" est qu'il y a des "gens" qui utilisent mac OS non seulement pour "cross-compiler sur un sous-système" mais également comme appareil de tous les jours, y compris pour les développements principaux avec un IDE mac OS. J'utilise tous les jours Ventura et Windows 10 (un peu moins Windows 11) indifféremment et avec le même plaisir pour toutes mes tâches [développeur ou pas]. Je "reconnais" moins utiliser Linux qui est installé sur tous mes OS en VM peut-être parce que le "triple"-boot, cela me dépasse et puis parce que Parallels sur mac est vraiment bien quelque soit la puce Apple retenue. C'est peut-être pour cela aussi que je suis agacé vis-à-vis de Delphi et que je refuse d'acheter une version commerciale. D'autant que je possède une version XE 7 Academic valable sans restriction de temps (à vie) et que retraité, je ne peux plus bénéficier de version Academic alors que je travaille encore pour/avec mes Collègues sur des outils pédagogiques et de gestion internes aux établissements que j'ai fréquentés. C'est une politique très contestable, qui a mal évolué à mon sens. En réalité, si tu veux développer sur du matériel moderne autre chose que du Windows et de l'android, la version CE convient mal. Embarcadero devrait s'inspirer de la politique de Qt à tous les niveaux : diversification des versions payantes, distribution des versions Open Source à jour, mise à disposition des versions Beta.

En tout cas, merci pour le renseignement. Je vais réfléchir à tout cela (Question de temps même à la retraite : le code de Navyg était inattendu... autant que de penser réinstaller une CE aussi rapidement). A bientôt. Gilles

Assez inattendu, il me reste une Delphi 10.4.2 CE encore installée sur une VM Windows 10 :
Pièce jointe 633505
Donc il me faut respecter (déjà me souvenir de) la procédure d'installation pour cibler la VM mac OS Big Sur à partir de la VM Windows (comme je l'ai expliqué je ne veux pas installer Delphi sur mon dual-boot Windows)... En espérant que cela soit fonctionnel. Déjà l'ouverture de Delphi se traine sur la VM Windows... alors je vais augmenter la RAM de celle-ci et diminuer celle de Big Sur.

Si OK, je teste les codes de la TGrid à Colonnes fixes sur Big Sur... Sinon dernière solution, à partir du boot ventura, je créerai une Big Sur sur Parallels à côté de la Windows 10 sur Parallels déjà créée . Parallels fonctionne nettement plus rapidement que VmWare sur mon appareil.. Et il est possible avec la version 18 semble-t-il d'installer les versions précédant Ventura (jusqu'à Mojave donc pas de High Sierra ni de Sierra)...

Évidemment, je ferai un CR une fois testé.
Cordialement. Gilles

Bonjour,

j'ai installé une VM Windows 10 et une VM Big Sur sur ma Parallels 18 sous Ventura. Chaque VM dispose de 8 Go de RAM et l'utilisation est fluide. J'ai essayé d'abord d'obtenir un résultat identique avec VM Ware sur Windows 10 (en utilisant le dual-boot) donc toutes les ressources de mon mac Book. Cela fonctionne mais le résultat est nettement moins fluide. Concernant l'installation de la VM Big Sur sur Ventura, après plusieurs échecs successifs, j'ai décidé de désactiver la puce T2 du mac book :

• Aucune sécurité
• Autorisé le boot à partir de supports externes

Donc j'obtiens ceci :

Pièce jointe 633617

La question maintenant est :

Citation:

---

Est-il possible de transférer la licence de Delphi 10.4.2. CE qui est actuellement sur une VMware ou dois-je me "retaper" toute la procédure de Embarcadero : Demander une nouvelle licence, recevoir un mail,... ?

---

Sachant que lorsque j'ai installé sous Parallels la machine virtuelle Windows, la procédure m'a proposé d'y transférer directement le Windows 10 dual boot me libérant ainsi précisait le message 187 Go. J'en ai donc déduis que le BOOTCAMP (le dualboot) allait être supprimé. Pour simplement utiliser Delphi et cibler Mac, j'ai refusé :aie:

Parallèlement, j'ai commencé à étudier le code de la TGrids à colonne fixe et j'ai relu les problèmes en "suspens" qui m'étaient apparus autrefois concernant les TGrids, à savoir :

1. Est-il désormais possible de définir la taille de chaque Row d'une TGrid ? Il y avait bien une DefaultRowHeight mais elle était indifféremment imputable à toutes les lignes
2. Est-il possible plus facilement en fonction du contenu multi-ligne contenu dans une cellule et de la largeur de la colonne d'appartenance de la cellule de calculer la hauteur de cette dernière [j'avais réussi mais approche immonde] et ensuite de la diffuser à toute la Row contenant la cellule si la hauteur calculée est la plus grande [Ce dernier point m'était impossible, le point 1 n'ayant pas été résolu à l'époque en XE 7] ?
3. Si c'est le cas est-il possible de synchroniser cette "RowHeights[i]" avec celle de la TGrid à colonne fixe associée ?

Enfin :

• Contrairement à ce qu'a proposé Serge, je pense que l'approche de Navyg utilisant une TScrollBarVertical indépendante (à droite de l'association des TGrids) est la bonne solution : Très usuellement, on utiliser une colonne fixe à gauche de la TGrid pour afficher des moyennes par exemple. Il me semble plus pertinent d'utiliser une TScrollBarVertical indépendante pour simplifier le code.
• Et je n'ai réussi à déterminer encore en lisant le code comment la modification de la largeur des colonnes était gérée, notamment en cas d'un ancrage aux bords gauche et droit de la Form et du changement de largeur de cette dernière. Je suppose que c'est défini dans l'Inspecteur d'Objet, mais je me demande si c'est cohérent par exemple avec une TGrid à colonne fixe à gauche et une une TGrid à colonne fixe à droite.

Cela je le verrai quand j'aurai réussi à transférer ma licence Delphi :mouarf:
Cordialement. Gilles

Pour la licence, juste une réinstallation en utilisant le numéro actuel t'es refusée ou tu n'as pas tenté ?

Bonsoir Patrick,

j'ai récupéré le mail que m'avait envoyé Embardero avec le lien de téléchargement. Tout c'est parfaitement bien passé. Delphi 10.4.2 CE fonctionne avec une grande fluidité dans la VM Parallels Wibdows 10 (alors que la VM Parallels Big Sur est elle-meme ouverte sur un autre écran). On dirait même qu'il n'y a pas de VM !

Et cerise sur le gâteau, j'ai placé l'icône de Delphi dans le dock de Ventura (à gauche de la poubelle). Un clic dessus et la VM Windows s'ouvre et Delphi se lance automatiquement :
Pièce jointe 633620

J'installe demain mes composants habituels (Unidac et TMSFNCxxx) et je configure le ciblage de Big Sur et de l'iOS de l'époque. J'ai des vieux iPhone 6S qui devraient faire l'affaire. Mais je ne m'emballe pas de trop : je marquerai "Résolu" quand je pourrai au moins cibler Big Sur.:roll:

Cordialement. Gilles

Bonsoir,
Je ne pensais pas te poser autant de souci avec ces quelques lignes de code ;o)
Pour la hauteur des lignes, je n'ai pas essayé, mais je pense qu'il doit être assez facilement possible de répercuter un changement de hauteur de ligne d'une grid sur l'autre...
Quant à moi, c'était la première fois que j'essayais de compiler pour un Mac.
Un copain m'a prêté un IMac core 2 duo 64 bits (ouf) sous El Capitan 10.11, mais j'ai galéré pour comprendre comment ça fonctionnait.
J'ai chargé un Xcode 8.2.xip (difficile à trouver) et je l'ai décompressé après avoir compris que c'était une sorte de zip. Et après un double-clic sur le résultat, je croyais l'avoir installé mais impossible de récupérer le sdk dans delphi ... jusqu'à ce que je comprenne que le résultat n'est pas un pkg mais un app qu'il faut glisser dans applications ... et là victoire j'ai compilé et exécuté pour la première fois un programme perso sur un mac ... mais que c'est compliqué ... et que le système mac est fermé et compliqué ... je déteste .. sans parler de la molette de la souris qui fonctionne à l'envers !
Je ne sais pas si c'est ce que tu veux, mais en fait je crois que tu peux développer en fonction du sdk que tu récupères sur le mac ? Donc Mac récent = sdk récent ? On doit savoir très vite si c'est compatible ?
Mais je dis sans doute une grosse bêtise :o(
Bon courage.

Bonjour,

Citation:

---

Envoyé par navyg

Je ne pensais pas te poser autant de souci avec ces quelques lignes de code ;o)
Pour la hauteur des lignes, je n'ai pas essayé, mais je pense qu'il doit être assez facilement possible de répercuter un changement de hauteur de ligne d'une grid sur l'autre...

---

Ce ne sont pas les lignes de code qui me soucient mais leur "évolution" à mes besoins, en particulier au niveau de l'IHM avec la souris. Mais pour les TGrids, je dispose des TMSFNC que je commence à bien connaître.
Pour la hauteur des lignes, le problème ne se pose pas encore. Tu as remarqué qu'il n'existe qu'une DefaultRowHeight de la TGrid qui s'impose à toutes les lignes. Pas de RowHeights[i] sur les FMX.TGids. :ptdr::aie::weird:... Enfin, j'en étais resté là. J'ai eu le temps pendant mes installations de regarder le code source (i.e propriétés et méthodes) des TGrids et je n'ai rien vu pouvant s'apparenter à une évolution... Ceci dit, je suis preneur de toute méthode permettant de résoudre une hypothétique RowHeightAuto := True;

Cordialement. Gilles

Bonjour,

Concernant l'installation, j'ai terminé. Effectivement comme l'écrit Navyg, c'est compliqué du fait que l'environnement Delphi 10.4.2 CE impose des choix rétrogrades. Quand c'est dans l'environnement Windows, c'est facilement contournable et le problème se pose rarement puisque ce sont les mêmes API "recyclées" depuis des lustres. Mais quand c'est sous mac OS, cela se complique un tantinet :weird:

Une exemple simple : Lorsqu'on installe Xcode sur une Big Sur, naturellement le Xcode à installer serait au moins le 12.2 qui lui contient le SDK nécessaire (compatible). Le Xcode 10.3 plante si on l'installe par défaut. La solution est donc d'installer le Xcode 12.2 (on désarchive le Xcode_12.2.xip, on renomme le Xcode.app obtenu en XCode12.2.app, puis on le déplace dans Applications. On le "switche" (si on a déjà installé une autre version), on le lance et installe son Command Line.dmg. Ensuite on décompresse Xcode_10.3.xip, on renomme Xcode.app en Xcode10.3.app que l'on déplace dans Applications. On le switche (obligatoirement cette fois). Si on le lance à ce moment-là, on obtient une erreur, un problème de versions de dylib (signalée introuvable mais en réalité présente mais incompatible). Il faut ouvrir les paquets Xcode10.3.app et Xcode12.2.app et fusionner les répertoires Xcode12.2.app/.../developer/usr/lib avec Xcode10.3.app/.../developer/usr/lib dans Xcode10.3.app. Ensuite on relance Xcode10.3.app... Cela fonctionne !

J'ai dû renouveler plusieurs fois mes tentatives pour m'assurer du processus le plus simple. J'ai également fait des copies d'écrans. Je ferais volontiers un tuto mais je suppose que le système adopté par ce forum est toujours aussi compliqué et chronophage... Alors qu'un pdf, voire un document html... Évidemment, c'est moins homogène sur un site surtout avec des auteurs différents. Mais au final, cela fera un tuto de moins :aie: Choix cornélien : la forme ou le fond ?

Encore une remarque à ce niveau : à force de faire des vidéos, les gens ne savent plus faire une documentation d'installation. Pour Embarcadero, il faut suivre les hyperliens avec de nombreux retours sur les pages "parent" pour une installation standard au point que, même avec les 3 écrans sur mon mac, cela devient un fouillis mal exploitable. Avec un livre, on est obligé : il faut réfléchir au contenu de la documentation, l'ordonner, hiérarchiser les probables problèmes rencontrés par le lecteur... C'est plus compliqué pour son auteur évidemment mais quel confort pour l'utilisateur... et quel gain de temps !

Cependant il y a quelque chose qui m’interpelle un peu : la procédure est un peu compliquée. Sur Internet on devrait trouver la trace de cette complexité. Elle est quasiment inexistante. On en déduit quoi ?

Donc j'ai compilé un projet comprenant une simple TForm avec Xcode10.3. Le projet1.app fonctionne sous Big Sur. J'ai copié projet1.app sous Ventura : cela fonctionne également. Normal dans ce sens ! Donc résolu.

Cordialement. Gilles

Bravo !
Alors ça me paraissait complexe, mais avec tes explications, ça me paraît encore plus complexe ;o) !

Citation:

---

Cependant il y a quelque chose qui m’interpelle un peu : la procédure est un peu compliquée. Sur Internet on devrait trouver la trace de cette complexité. Elle est quasiment inexistante. On en déduit quoi ?

---

Chut ! Il ne faut surtout pas en parler ! Ou alors c'est qu'on est idiot qu'on trouve ça complexe ?

:oops: Désolé. On ne se posera pas plus de questions.
Bon WE. Cordialement. Gilles

j'ai pas tout suivi, mais je m'interroge tout de même, je crois comprendre que tu utilises le Mac comme machine principale...pourquoi vouloir développer avec Delphi pour Mac ? certes c'est possible, mais n'existe il pas dans le monde mac des outils de développement natif qui soient à la hauteur ? Car même si Delphi est multiplateforme, il est fortement ancré dans Windows et d'ailleurs l'IDE n'existe que sous Windows...donc ça ne me semble pas naturel de l'utiliser quand on travaille au départ sous Mac :)
VCL c'est Windows (sauf avec des outils tiers)
FMX c'est multiplateforme, mais à mon avis c'est surtout fait pour - justement - travailler sur de multiples plateformes; j'ai un produit Windows dont je veux proposer une version Mac, et pour ne pas tout refaire j'ai besoin d'un produit qui soit capable de compiler pour les deux plateformes. (bon je dis ça mais j'ai un produit FMX pour Windows car j'avais besoin d'un affichage graphique plus avancé que GDI et que je n'avais pas le temps de tout réinventer)
Je mets de côté le mobile car je reste persuadé qu'il ne faut pas développer la même appli sur Desktop et sur Mobile. Que Delphi propose de compiler l'appli Mobile sous Windows c'est pratique pour le débogage mais il me semble nécessaire de créer une IHM adaptée à chacun des deux mondes...et qui pourra être utilisée à l'identique sous iOS et Android d'un côté, et Windows OSX et Linux de l'autre (en gardant les objets métiers en commun ceci dit).

Après en grand fan de Delphi que je suis, je peux comprendre qu'on y soit attaché même si on migre sur un autre OS...mais vu que même sous Windows je développe mes propres composants, si je devrais migrer sous OSX je pense que j'utiliserais avant tout le compilateur et que je chercherais sans doute à me créer mes propres outils, mes propres composants adaptés à l'OS sans me soucier du multiplateforme. Ce que j'aime avant tout dans Delphi c'est le langage, je n'attends pas forcément d'avoir des composants tout fait adaptés à tous mes besoins. Mon expérience m'a montré qu'on passe moins de temps à créer un composant adapté a son besoin que de faire rentrer son besoin dans un composants existant qui n'est pas tout à fait adapté....et plus on crée de composants, plus c'est facile à faire.

Citation:

---

Envoyé par Paul TOTH

j'ai pas tout suivi, mais je m'interroge tout de même, je crois comprendre que tu utilises le Mac comme machine principale...pourquoi vouloir développer avec Delphi pour Mac ? certes c'est possible, mais n'existe il pas dans le monde mac des outils de développement natif qui soient à la hauteur ? Car même si Delphi est multiplateforme, il est fortement ancré dans Windows et d'ailleurs l'IDE n'existe que sous Windows...donc ça ne me semble pas naturel de l'utiliser quand on travaille au départ sous Mac :)
VCL c'est Windows (sauf avec des outils tiers)
FMX c'est multiplateforme, mais à mon avis c'est surtout fait pour - justement - travailler sur de multiples plateformes; j'ai un produit Windows dont je veux proposer une version Mac, et pour ne pas tout refaire j'ai besoin d'un produit qui soit capable de compiler pour les deux plateformes. (bon je dis ça mais j'ai un produit FMX pour Windows car j'avais besoin d'un affichage graphique plus avancé que GDI et que je n'avais pas le temps de tout réinventer)
Je mets de côté le mobile car je reste persuadé qu'il ne faut pas développer la même appli sur Desktop et sur Mobile. Que Delphi propose de compiler l'appli Mobile sous Windows c'est pratique pour le débogage mais il me semble nécessaire de créer une IHM adaptée à chacun des deux mondes...et qui pourra être utilisée à l'identique sous iOS et Android d'un côté, et Windows OSX et Linux de l'autre (en gardant les objets métiers en commun ceci dit).

Après en grand fan de Delphi que je suis, je peux comprendre qu'on y soit attaché même si on migre sur un autre OS...mais vu que même sous Windows je développe mes propres composants, si je devrais migrer sous OSX je pense que j'utiliserais avant tout le compilateur et que je chercherais sans doute à me créer mes propres outils, mes propres composants adaptés à l'OS sans me soucier du multiplateforme. Ce que j'aime avant tout dans Delphi c'est le langage, je n'attends pas forcément d'avoir des composants tout fait adaptés à tous mes besoins. Mon expérience m'a montré qu'on passe moins de temps à créer un composant adapté a son besoin que de faire rentrer son besoin dans un composants existant qui n'est pas tout à fait adapté....et plus on crée de composants, plus c'est facile à faire.

---

Bonjour Paul,

effectivement, un peu dur à suivre mon histoire...:oops:

Je suis sans aucun doute comme dirait Navyg un vieux C.. mais ma génération sait lire et comprendre ce qu'elle lit. Évidemment la solution retenue par Embarcadero impose de développer avec un framework sous Windows et quelque soit la configuration, il va bien falloir mettre un mac dans le circuit pour compiler sous mac. C'est évident. Et je l'accepte même si j'ai horreur de la cross-compilation. Mais cela n'empêche pas de tester...

Mac OS n'est pas mon univers de développement mais un de mes univers de développement. J'utilise aussi régulièrement Windows 10 et 11. Avec des machines virtuelles, j'utilise Linux [debian, ubuntu, mint principalement] soit à partir de Windows [en général avec VMware ou VirtualBox], soit à partir de Mac [avec Parallels].

Sur le mac OS Ventura de mon mac book, dans le cas de ma VM "Windows 10 -Delphi 10.4.2 CE" sous Parallels, je ne constate pas de ralentissements particuliers. C'est fluide. En installant parallèlement une VM Parallels Big Sur pour y installer le Xcode10.3, puis le Paserver21.0.pkg, je n'impacte aucunement mon environnement habituel. L'installation est réellement réversible, sans aucun impact ni trace.

Donc j'en suis resté dans mon approche aux contraintes énoncées dans les divers documents Embarcadero que j'ai référencés précédemment dans cette discussion : Pour cibler les OS d'Apple, 10.4.2 CE impose Xcode 10.3 (au plus) et Big Sur (au mieux). Et j'ai précisé que sous une Big Sur d'origine le Xcode 10.3 n'est pas le standard et ne s’installe pas sans problème. Évidemment, il faut vérifier qu'il est correctement installé parce que si on ne le lance pas, rien n'avertit du problème rencontré.

Effectivement, je n'utilise plus Delphi pour développer sous Mac, sur Linux et même sur Windows... Encore moins sous android, ni iOS. Comme tu l'écris, j'ai choisi des solutions natives et je ne cross-compile jamais mes projets, bénéficiant pour leur développement de tout le confort et des outils adaptés pour l'OS. J'ai pris la décision "radicale" de ne plus l'utiliser après un dernier "test" avec mon XE7 Academic.

Le code de Navyg a réveillé mon intérêt concernant les limites -c'est un euphémisme, par exemple- des TGrids natives de FMX et m'a incité à refaire un essai. Je n'ai pas eu vraiment le temps, il y a 4 mois de tester un ciblage mac. Je vérifiais la portabilité des nouvelles TMSFNCGrids de Lazarus vers FMX. Comme mon matériel et mes outils évoluent, régulièrement, je continue ma veille technologique concernant les possibilités de développement. J'ai toujours cherché des solutions de développement rapides et simples, aussi peu chronophages que possible et bien documentées. Elle doivent me permettre de mettre en œuvre mes idées, mes approches métiers sans concessions. Je reste persuadé que le développeur doit disposer d'un framework ne le contraignant pas à baisser le niveau de ses exigences. Depuis plusieurs années (avant même l'apparition de XE7), en desktop multi-OS, j'ai eu besoin de TGrids avec des colonnes fixes et des row fixes, gérant les cellules multilignes (enfin des rows) "autoheight", accueillant du HTML. Pour cette partie du développement Web le permet depuis longtemps maintenant. J'ai également besoin de disposer d'un moteur d'IA pour faire du learning analytics. J'ai donc besoin... d'un langage ouvert, complet "nativement" si possible, et multi-OS. Je préférerais produire du "compilé". Je n'en connais que 2 actuellement, le premier compatible Windows, Linux et Mac et le second purement Mac. Mais, dans ce forum, l'objet n'est pas de faire leur pub même si récemment j'ai créé un lien de description dans un autre forum du site. Mon vieux Delphi me rendait ce service il y a 30 ans, mais avec des exigences différentes.

De ce fait, je reste très attaché à Delphi. Je n'oublie pas des décennies de développement avec ce produit. Mais je regrette son positionnement actuel. Il y a longtemps déjà, j'avais fait remarquer que le ciblage des mobiles et des dektop aurait dû être totalement différencier, un peu comme l'a fait PC SOFT avec son Windev et son Windev Mobile, 2 produits que j'ai également abandonnés, ne conservant que Webdev que j'apprécie et qui me suffit pour le développement Web.

Donc pour les TGrids natives, j'ai peu d'espoir de résoudre le problème. Mais j'aimerais également tester le support des styles choisis par l'utilisateur dans son OS dans les applications FMX Desktop.

J'espère avoir été moins confus.
Cordialement. Gilles

Très clair.
Et finalement je me demande si je ne vais pas suivre le conseil de Paul (et Sergio) et essayer de faire un nouveau composant grid correspondant à mes besoins, même si la solution dont le code a relancé ton intérêt fonctionne très bien ;o)

Cela étant, c'est la première fois que je m'essaye au multiplateforme, et j'ai la surprise d'arriver à faire tourner le même programme (avec un peu d'instructions de compilation conditionnelle bien sûr) sur un pc, un mac et sur un téléphone androïd. Ios je n'ai pas pu essayer car avec l'imac qu'on m'a prêté, et le xcode que j'ai pu installer, je n'ai pas trouvé trace des sdk Ios.
Mais c'est quand même pas mal d'arriver à faire ça avec un petit delphi.

Bonjour Navyg,

c'est effectivement une approche possible :ccool: Ce qui ne convient pas à l'un, convient à l'autre. L'uniformité serait trop ennuyeuse. Je te souhaite de bons développements avec Delphi.
Bonne fin de WE.
Cordialement. Gilles