Discussion :

[weabow]

Ceci est un retour d’expérience que j’aurais aimé trouver lorsque j’ai été amené, en 2017, à choisir un nouvel outil de développement. Il s’agit ici de raconter et aussi donner mon impression subjective dans l’utilisation de Delphi et FireMonkey.


Le projet
Redévelopper une application typiquement Desktop en Delphi, pour Windows, OSX (Mac), Android et IPad (IOS). Le déploiement se fera au travers des Stores.


Qui suis-je ?
Je développe depuis que j’ai 18 ans (Z80, Commodore64, Apple2, les premiers Mac) et j’en ai 58. Je connais très bien VB (depuis la version 2 jusqu’à la version 6), Java, puis moins bien (mais quand même…) le C (couches de comm temps réel avec dialogue Unix, Windows), C++, php, mysql, SQL, HTML, JavaScript (un peu), ACCESS et enfin vaguement DotNet C#.

Bref je suis loin d’être un débutant.


L’application
Elle n’est pas hyper complexe mais comporte beaucoup d’écrans modaux. La version actuelle que je redéveloppe sous Delphi a nécessité deux ans pleins de développement sous VB6. La précédente avait pris plus d’un an, mais était moins sophistiquée.

Elle n’utilise pas de base de données (c’est important), mais elle dessine beaucoup à l’écran, en print et pdf (natif).

Elle dialogue avec le serveur (Apache , php, MySql) sous forme d’appel https sur du php, qui lui gère la base de données. Les accès Internet sont fréquents, mais elle doit pouvoir fonctionner hors-connexion.

Comme c’est une application Desktop, elle a beaucoup recours à des boîtes de dialogues.

Elle se paramètre dans ses droits et habilitations en temps réel, suivant les dialogues avec le serveur.


Le contexte
Comme je suis un peu feignant, j’ai décidé de m’adjoindre le support d’un MVP Delphi (très talentueux et constructif). Je lui dis ce que je veux, nous discutons d’une stratégie argumentée, et avec lui je développe (dans un premier temps) dans le projet d’être 100% autonome.

Quand il y a des bugs, je lui donne les sources et il cherche. Parfois je lui sous-traite des modules.

C’est donc une configuration de succès idéale.

Le projet à la base est de coder sous Windows, et de lancer sur les autres plateformes directement. Cela fonctionne bien dans 95% des cas, une fois les bonnes stratégies adoptées …


La gageure
Les environnements tablette ne sont pas prévus pour avoir des fenêtres modales, et encore moins du code qui stoppe son exécution lors de l’affichage d’une boîte de dialogue.

En revanche, l’application nécessite de manière impérieuse d’avoir des boîtes de dialogue (pour de multiples excellentes raisons que je ne développerai pas ici, et qui ne sont pas informatiques, mais marketing).

La gageure est alors de re-fabriquer de façon totalement artificielle le système modal sur des systèmes qui sont conçus pour être définitivement asynchrones, tels que JavaScript.


L’expérience

L’apprentissage du langage
Delphi est du Pascal qui à mon sens ne pose pas de pb particulier. L’orientation objet fonctionne bien. Le debuggage sous Windows ne pose pas de pb particulier (sous les autres OS, c’est plus sioux, voire peu opérationnel). Le compilateur Windows est très rapide (Proc I7, 8 threads à 2.5 Hgz, 16Go de ram, SSD 1 T). RAS.

J’ai trouvé Delphi confortable comme langage.

FireMonkey est un FrameWork (qui remplace la VCL) crossplatform qui fournit les contrôles et la Frame et bien d’autres choses plus ou moins pratiques. Il a quelques curiosités de conception que l’on comprend bien du fait du caractère crossplatform de la bête. Soyons clairs : il est très loin d’être dépourvu de bugs, et c’est là une vraie difficulté.

L’aide
L’aide n’est pas très claire, mais pléthorique, donc peu aisée à utiliser. Parfois, il y a certaines propriétés/instructions qui ne bénéficient d’aucune aide, tout simplement. Le cas appelle d’être souligné car il est récurrent.

L’aide sur Internet : puisque Delphi existe depuis des lustres, il y a quantité de code sur le Net qui traîne. Bonne nouvelle ! Grossière erreur : les versions successives de Delphi ont fait que du code ancien ne fonctionne tout simplement pas sur la version actuelle (Berlin, Tokyo). Donc en fait il est assez délicat de se dépanner grâce au Net.

Méthode de développement
Pour celles et ceux qui croient que sous Delphi on développe 5 fois plus vite, dans ce cas il faut coder ( ?) en mode graphique, c’est-à-dire poser les contrôles sur les feuilles, comme on faisait en VB (au début). De même, on utilise alors les systèmes de lien des contrôles avec les champs des tables des bases de données (les exemples proposés sont effectivement très séduisants).

À l’usage, et très personnellement, j’ai laissé tomber cette stratégie, et je code tout. Je ne crois pas à cette façon de faire pour des applications lourdes et qui se redimensionnent et se re-paramètrent en temps réel. Mais ceci est un avis personnel.

Bugs
Il y en a pas mal. Surtout sur FireMonkey. Et ceux-ci sont particulièrement délicats à identifier. Certains nécessitent de revoir complétement la stratégie. Plus grave pour moi : l’aide indique certaines choses, qui ne sont pas effectives, donc fausses. J’ai été amené à redévelopper des outils de base car ceux proposés étaient buggués (par exemple des listes qui contiennent des objets : la base – ceci est dû à la gestion mémoire particulière).

Après quelques temps, on en arrive à douter systématiquement de FireMonkey, ce qui est sage et qui fait gagner du temps dans l’identification des bugs.

Gestion de la mémoire et fuites

Du fait du Crossplatform, il y a 2 systèmes de gestion mémoire :
• Le traditionnel, à la dure sous Windows (et Mac),
• Arc, pour les tablettes et téléphones (système de déchargement automatique suite à un comptage de référence, comme sur Java).

Clairement, Arc n’est pas fiable (exemple de redéveloppement d’objets de base cité plus haut, qui fonctionne bien sous Windows, pas sous IPad/Android), et parfois décharge des collections, et ainsi supprime des objets en cours d’utilisation. La stratégie consiste donc à conserver une méthode plus traditionnelle, en mode bourrin, pour gérer la mémoire et limiter les fuites.

Ceci était su, on arrive à fonctionner correctement.

Emabarcadero – Mises à jour
C’est l’éditeur de Delphi. L’ancienne équipe a été remerciée il y a bientôt deux ans. Aujourd’hui la nouvelle équipe tente de réparer les erreurs passées (et y arrive peu à peu), tout en continuant d’avancer.

Cela se traduit par 3 à 4 mises à jour par an, immanquablement suivies par des patchs et des fixs qui mettent à jour la mise à jour.

Bref : il est urgent de ne pas se presser de mettre à jour. Voire, il est recommandé d’installer sur une machine virtuelle pour tester les sources, avant de mettre à jour.

Personnellement, j’installe sur accord de mon support MVP, qui lui s’appuie tous les tests.


Ce serait à refaire
Delphi est à ma connaissance un des seuls outils à faire aussi bien du Crossplatform. Xamarin a tenté (j’avais regardé à l’époque, mais la couche Mac était seulement en cours de développement, et surtout Visual Studio était une usine à gaz très peu fiable). Malgré son côté gratuit, j’ai renoncé très vite. Je ne sais pas ce qu’il en est maintenant.

J’ai maintenant trouvé QT, qui est fort mal référencé, et plus cher que Delphi. Aujourd’hui, si je n’étais pas aussi avancé, je regarderais cette solution de très près.

Prendre un conseil MVP est pour moi une nécessité définitive : sans lui j’aurais abandonné (pourtant je ne suis pas un débutant). Disons aussi que pour lui, l’application est réellement complexe (150 fichiers sources pour l’instant, sachant qu’à la fin il y en aura probablement 300 à 500).

Je doute ? Oui, mais c’est trop tard. Donc je continue. Et finalement l’application commence à tourner très proprement et de façon opérationnelle.


Forces Freins

Les forces : FireMonkey reste en définitive une force. Le langage, quant à lui, me semble bien fait. L’environnement, malgré les critiques, est très opérationnel et fait pour cela. C’est confortable. La productivité est dans la norme, sans plus.

Les freins : pas mal de bugs sur FireMonkey, avec une équipe qui rame un peu (mais qui avance, je tiens à le souligner) pour rattraper les errances du passé.

Le code once, run anywhere est un peu une vue de l’esprit, atteinte à 95% pourtant une fois les bonnes stratégies adoptées.

Le debuggage reste souvent un problème du fait de sa lenteur, très particulièrement sur Android.

La compilation Android aussi (durée du fait des outils fournis par Google qui n’utilisent pas tous les threads disponibles, donc pas du fait de Delphi).

Il est clair aussi qu’il y a une marge de progrès très considérable pour créer des simulateurs dignes de ce nom.

En synthèse
Heureusement que je n’ai pas de Dead-line. Grâce à cela, et un bon budget pour mon conseil MVP, j’avance, avec la foi chevillée au corps (c’est utile dans les phases de découragement, régulières).

Dans tous les cas, Delphi, à par QT qui est sensiblement plus cher, n’a pas de réel concurrent à ma connaissance. Xamarin pourrait rattraper son retard à terme, mais clairement Delphi a aussi ici beaucoup d’avance dans les nombreux outils, bien intégrés, qu’il propose.

En revanche, démarrer un grosse appli orientée Desktop, de zéro et sans aide extérieure, ressemble pour moi à une stratégie à très gros risques, et surtout très coûteuse à bien des points de vue.

Hope this helps

Christian

[Papy214]

Voilà un avis détaillé et équilibré !

Le code once, run anywhere est un peu une vue de l’esprit, atteinte à 95% pourtant une fois les bonnes stratégies adoptées.

Je suis juste un peu circonspect sur le 95%.
Il y a tout de même pas mal de cas où il faut jouer sur 2 formes de code selon l'OS visé.
Je travaille sur une application prévue à l'origine pour Windows et MAC mais l'idée du MAC s'éloigne de plus en plus au fil du développement.
On a mis trop de choses liées à Windows et je crains que l'adaptation ne soit plus possible.

Merci pour ce retour d'expérience très intéressant.

[nostroyo]

Merci beaucoup pour ce retour d’expérience qui est très (trop) rare.

Pour ma part j'utilise FMX que pour une application mobile (iOS android) ou je n'ai pour l'instant pas eu beaucoup de bug. Il est vrai que je n'en suis qu'au début de mon projet et que l'appli ne fait que présenter et insérer des données sur un serveur. J'ai de gros doute pour FMX en desktop et ton retour ne fait que confirmer cela.

Encore merci.

[SergioMaster]

Bonjour
Je suis d'accord avec Papy214, ce retour d'expérience est très intéressant.

En revanche, démarrer un grosse appli orientée Desktop, de zéro et sans aide extérieure, ressemble pour moi à une stratégie à très gros risques, et surtout très coûteuse à bien des points de vue.

Je me lance dans un de ces chantiers pourtant et ce avec accès à une base de données. J'aurais pu me cantonner à la VCL car pour l'instant tous les postes clients sont Windows mais FMX me plait bien .. Ceci dit je n'en suis qu'au début de mon aventure, quand on me demande un programme pour hier je reste encore très VCL.

Démarrer une nouvelle appli FMX à au moins un avantage, partant de zéro on évite la gageure principale de l'appli weabow.
Tout faire pour éviter ces fenêtres modales et donc repenser l'interface utilisateur en fonction. Mon principe : j'utilise un (ou j'abuse de) TTabControl et le docking de formes.

[free07]

Bonjour,

Merci pour ce retour d’expérience très intéressant et comme il a été dit, c'est malheureusement trop rare.

Ceci est un retour d’expérience que j’aurais aimé trouver lorsque j’ai été amené, en 2017, à choisir un nouvel outil de développement. Il s’agit ici de raconter et aussi donner mon impression subjective dans l’utilisation de Delphi et FireMonkey.

En 2017 Tu as commencé ce projet avec Berlin ou Tokyo ? ( vu que tu cites les nombreuses mises à jour de Delphi qui était réalisées les années précédentes ( avant 20216 ) )

L’application
Elle n’est pas hyper complexe mais comporte beaucoup d’écrans modaux.

Elle n’utilise pas de base de données (c’est important), mais elle dessine beaucoup à l’écran, en print et pdf (natif).

Je suis très curieux de savoir comment on peut effectivement résoudre ce problème de portage d'écrans modaux sur les mobiles, quelle solution a été prise ?

Elle dialogue avec le serveur (Apache , php, MySql) sous forme d’appel https sur du php, qui lui gère la base de données. Les accès Internet sont fréquents, mais elle doit pouvoir fonctionner hors-connexion.

AMHA c'est une bonne solution de faire gérer les données par un serveur dédié, par contre, pour le mode hors-connexion, l'application est autonome, est ce à dire qu'elle récupère les données dans un 1er temps et ensuite elle travaille de manière autonome ou alors parles tu d'une solution de réplication ( ou synchronisation ) des données une fois la connexion au serveur établie ?

Comme c’est une application Desktop, elle a beaucoup recours à des boîtes de dialogues.

Idem que pour les fenêtre modales, c'est vraiment pas simple de gérer bcp de boites de dialogues sur les mobiles.
Elle se paramètre dans ses droits et habilitations en temps réel, suivant les dialogues avec le serveur.

Le projet à la base est de coder sous Windows, et de lancer sur les autres plateformes directement. Cela fonctionne bien dans 95% des cas, une fois les bonnes stratégies adoptées …

J'ai du mal à comprendre "lancer sur les autres plateformes directement", peux tu préciser ?

Les environnements tablette ne sont pas prévus pour avoir des fenêtres modales, et encore moins du code qui stoppe son exécution lors de l’affichage d’une boîte de dialogue.

En revanche, l’application nécessite de manière impérieuse d’avoir des boîtes de dialogue (pour de multiples excellentes raisons que je ne développerai pas ici, et qui ne sont pas informatiques, mais marketing).

La gageure est alors de re-fabriquer de façon totalement artificielle le système modal sur des systèmes qui sont conçus pour être définitivement asynchrones, tels que JavaScript.

Comme je l'ai dit précédemment, je suis très curieux de connaitre la solution adoptée, si tu peux en dire un peu plus sur ce sujet, ce serait super.

Il y en a pas mal. Surtout sur FireMonkey. Et ceux-ci sont particulièrement délicats à identifier. Certains nécessitent de revoir complétement la stratégie. Plus grave pour moi : l’aide indique certaines choses, qui ne sont pas effectives, donc fausses. J’ai été amené à redévelopper des outils de base car ceux proposés étaient buggués (par exemple des listes qui contiennent des objets : la base – ceci est dû à la gestion mémoire particulière).

Tu parles de TListObject ? Pour ma part, j'utilise des listes d'objets et j'ai n'ai pas encore rencontré de bugs ( mes tests restent encore à approfondir )

Pour ma part, je travaille sur une nouvelle application et j'ai fais comme Sergio, j'évite les fenêtres modales en utilisant les tabcontrol

[weabow]

En 2017 Tu as commencé ce projet avec Berlin ou Tokyo ?
Berlin et maintenant Tokyo


Je suis très curieux de savoir comment on peut effectivement résoudre ce problème de portage d'écrans modaux sur les mobiles, quelle solution a été prise ?
Il s'agit dans un premier temps de créer un overlay qui couvre toute la TForm de fond, afin d'empêcher les clics de souris d'être actifs.
Là-dessus, on ajoute un TFrame, qui reçoit tous les composant nécessaires (bouton, labels, etc.)

Pour le déchargement, c'est là que c'est un peu sioux : le bouton Quitter ne peut pas supprimer le TFrame, car il est possédé (AOwner) par le TFrame. Donc impossible de décharger sans avoir une erreur de pointeur.
Du coup, j'ai tout un système qui ressemble à la gestion des messages de Windows : j'envoie à la feuille de fond une info, qui déclenche un timer (les threads ne sont pas suffisants), qui lui scrute les TFrames, détecte si l'un est susceptible d'être déchargé (propriété spécifique créée pour l'occasion), et si c'est le cas le DisposeOf (par de free du fait des pb crossplatform).

AMHA c'est une bonne solution de faire gérer les données par un serveur dédié, par contre, pour le mode hors-connexion, l'application est autonome, est ce à dire qu'elle récupère les données dans un 1er temps et ensuite elle travaille de manière autonome ou alors parles tu d'une solution de réplication ( ou synchronisation ) des données une fois la connexion au serveur établie ?
Les deux : pour les données de licence, elles sont stockées/cryptées dans un json sur disque, et nous sommes en train de développer un Cloud, style DropBox, mais qui rapatrie une base de données de contenus, avec les mécanismes d'update qui vont bien.


J'ai du mal à comprendre "lancer sur les autres plateformes directement", peux tu préciser ?
Dans la combo en haut, je change la cible (Mac, Android, etc.) et je lance.


Tu parles de TListObject ?
Exact : sur Windows/Mac (hors arc), il ne décharge pas son contenu sur un appel de feuille modale, tandis que sous IOs et Android, curieusement, il met tout à nil. Du coup on perd le objets, qui pointe dans le vide. Ce fonctionnement est très curieux et nous n'avons pas encore pu le reproduire sur un exemple simple. J'ai eu souvent des cas où le compteur de référence indique n'importe quoi.

Christian

[Paul TOTH]

Bon, merci pour ce retour d'expérience très instructif.

Pour ce qui est de la différence ARC/Non-ARC c'est en effet quelque chose d'assez déroutant.

Grâce à FMXLinux, il est possible de recompiler une application FMX sous Linux, et comme je testais l'écriture d'un nouveau composant j'en ai profité pour voir ce que ça donnait sous Linux...or Linux utilise ARC (mon composant n'est pas prévu pour mobile)...et là j'ai une surprise en effet, le composant possède des onglets, sur un clic je détruis l'onglet sous la souris, ça fonctionne nickel sous Windows/OSX mais sous Linux, il ne se produit rien...vu que la méthode Free ne fait rien et que mon onglet est toujours référencé par son parent, il n'est pas détruit

[free07]

D'accord,

En ce qui concerne les TListObject, je n'ai jamais constaté ce genre de problèmes, j'utilise aussi des TList<T> et pas de soucis non plus, faut dire que durant les tests, je ne dépasse jamais dépassé les quelques dizaines d'objets dans ces listes, faudrait que je fasse des test plus poussés.
Si tant est que le nombre d'objets est une importance ou un rapport aux bugs que tu as rencontré.

[SergioMaster]

je testais l'écriture d'un nouveau composant

"tu quoqui"

Linux utilise ARC (mon composant n'est pas prévu pour mobile)...et là j'ai une surprise en effet, le composant possède des onglets, sur un clic je détruis l'onglet sous la souris, ça fonctionne nickel sous Windows/OSX mais sous Linux, il ne se produit rien...vu que la méthode Free ne fait rien et que mon onglet est toujours référencé par son parent, il n'est pas détruit

j'ai lu quelque chose à ce sujet sur la toile mais je ne me souviens plus très bien où ! on ne sait jamais si je retrouve l'adresse je t'en ferais part

[weabow]

Pour ce qui me concerne : non.

Je passe un TListObject dans une fonction qui affiche une fenêtre modale, dans le constructeur de la classe.

A la sortie du constructeur, le TListObject reste intact sous Windows/Mac, et se purge sous IOs et Android.

Or j'ai bien vérifié qu'il est toujours référencé dans une autre partie du programme. Donc, le compteur de références devrait empêcher la purge, ce qui n'est pas le cas.

[Paul TOTH]

Pour ce qui me concerne : non.

Je passe un TListObject dans une fonction qui affiche une fenêtre modale, dans le constructeur de la classe.

A la sortie du constructeur, le TListObject reste intact sous Windows/Mac, et se purge sous IOs et Android.

Or j'ai bien vérifié qu'il est toujours référencé dans une autre partie du programme. Donc, le compteur de références devrait empêcher la purge, ce qui n'est pas le cas.

cela ressemble à une [weak] référence.

pour rappel, avec ARC tout objet qui est référence au moins une fois n'est pas supprimé....ce qui pose problème quand deux objets s'autoréférencent, ils se tiennent la main et ne meurent jamais.
pour casser ce lien infernal il est possible d'utilise un attribut [unsafe] ou [weak] sur l'une des deux référence. Avec [unsafe] l'ARC est désactivé et comme sont nom l'indique on ne peut pas être certain que la référence est valide car l'objet a pu être libéré par ailleurs. Avec [weak] c'est plus sioux, si l'objet est libéré par ailleurs, le référence est forcée à nil !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
var
  a: TObject;
  b: TObject;
  [unsafe] c: TObject;
  [weak] d: TObject;
begin
  a := TObject.Create; // refcount = 1
  b := a; // refcount = 2
  c := a; // refcount = 2 !!!
  d := a; // refcount = 2 !!!
  a := nil; // refcount = 1, a = nil, b <> nil, c <> nil, d <> nil
  b := nil; // refcount = 0, a = nil, b  = nil, c <> nil, d = nil !!!
end;

notez bien, "c" et "d" ne modifient pas le refcount de l'objet, et "d" passe à nil automatiquement (faut pas rêver y'a du code ajouté par le compilateur) pour le forcer à nil quand l'objet est détruit.

[bizulk]

Merci de ton retour très apprécié... justement j'étais en train d'évaluer la réécriture d'une IHM codé avec Emwin (pour plateforme cortex-M et autre famille de uC), et mon client souhaite du multiplateforme.

Nous avons dans notre équipe une expérience interne avec QtQuick positive (Android/Windows OK), mais effectivement les couts sont élevés pour une PME d'une dizaine de personnes : un peu plus de 10 K/ développeur + royalties pour la licence "Qt for devices". Pas de licence Flex. Ils proposent bien une licence desktop suffisante mais dès lors que l'on propose un appareil sans interface il faut sélectionner le paquetage complet (dédié à des kernels sans environnement graphique).
Les possibilités de travailler en LGPL sont possibles, mais il faut faire attention à la distribution du code distribué avec cette licence, compenser les composants que l'on ne peut intégrer....
Donc ton observation avec Qt est toujours d'actualité.

Je m'étais penché sur Xamarin qui est plus accessible en terme de licence, mais il faudra peut-être considérer également le cout d'un support.
Vu ton retour d'expérience je ne vais pas me risquer à me lancer sur Lazarus, ça risque d'être la jungle.
Par ailleurs je me demande ce que permet Kotlin.

Si tu devais recommencer tu reprendrais FMX ?

[bizulk]

J'ai une question concernant leurs produits : il distingue C++ builder et RAD Studio, il s'agit bien de la même base IDE n'est-ce pas ?

[free07]

J'ai une question concernant leurs produits : il distingue C++ builder et RAD Studio, il s'agit bien de la même base IDE n'est-ce pas ?

Oui, c'est le même IDE pour les deux produits : Builder C++ et Delphi

RAD Studio est leur offre qui comprends les deux langages.

[weabow]

Hello,

L'appli sort maintenant du statut Bêta. Elle fonctionne plutôt bien.

Le bilan intermédiaire :

Avec la dernière version 10.3 (Rio), Embarcadero a introduit des souplesses dans le langage (la base ailleurs). Rien de révolutionnaire, mais un très bon signe de leur investissement pour améliorer l'existant.

Avec une décision courageuse : abandonner arc pour avoir la même gestion mémoire partout. Excellent.

Un gros travail de fond est fait pour corriger les bugs, et il y en a. Le langage est clairement pris en main avec un objectif de fiabilisation.

Avec les bonnes stratégies maintenant établies, effectivement je développe sous Windows, et cela fonctionne pareil sur les autres plateformes, à 99,9%. Il m'arrive de déployer sans debugger sur toutes les plateformes. L'objectif annoncé me semble atteint.

Maintenant je reste ferme sur l'idée de se faire aider par un MVP :

1) une connaissance assez pointue des différents environnements est indispensable, et cela demande du temps,
2) le déploiement reste une difficulté récurrente, entre les ruses de sioux d'Apple, et les évolutions d'Android.
3) le renouvellement des certificats chez Apple est jute le parcours du combattant.
4) mon objectif était hors créneau : faire du modal événementiel sur des plateformes par essence asynchrones. Cela fonctionne très bien.

Je ferai dans les semaines qui viennent une vidéo du soft.

Donc si c'était à refaire, oui. Mais dans ces conditions. En même temps je ne connais pas QT, ni ne sait s'il est facile de trouver un MVP QT. Pour moi, c'est indispensable (je sais je suis lourd...).

Christian

[bizulk]

Merci.
N'hésites pas à entretenir ce thread avec tes retours.
As tu eu à gérer les fonctionnalités suivantes ?

• Internationalisation (très facile sous Qt),
• Intégration d'une DLL écrite en C/C++ (j'ai trouvé des blogs Xamarin / Qt / Android pour le faire)
• Personnalisation apparence (Thèmes/style),
• affichage d'un widget existant de type "plot" (exemple Qt ici).

[weabow]

Avec plaisir.

Internationalisation : oui le soft est polyglotte, avec une stratégie "maison" : fichiers Word externes qui sont chargés au boot. C'est pratique pour travailler avec des traducteurs. Je sais qu'il y a des fonctionnalité pour cet objectif, mais je ne les ai pas étudiées.

Intégration d'une dll : non je ne l'ai pas fait. C'est possible, même d'intégrer des routines en assembleur (paraît-il).

Personnalisation : oui, le GUI est 100% maison et crossplatform. C'était un des impératifs pour mes utilisateurs qui ne sont absolument pas intéressés par l'informatique. Le leitmotiv : same UI, same UX.

widget : non. Je ne connais pas ces stratégies.

@+

Christian

[pprem]

Merci.
As tu eu à gérer les fonctionnalités suivantes ?

Pour l'internationalisation c'est à faire soi même avec FMX. Un composant TLang est fourni mais insuffisant car il ne gère que les textes d'une fiche.
Sur la VCL des outils puissants sont disponibles et fournis, ça pêche côté multiplateforme mais rien d'insurmontable.

Pour les DLL & co c'est toujours aussi simple que depuis le Turbo Pascal et ce quelle que soit la plateforme : on gère les liens à travers une unité qui marche les fonctions que l'on veut rapatrier. Des outils existent pour le faire "automatiquement" avec les libraires iOS, macOS et Android. Côté Windows c'est un classique mélange de "external" et "cdecl" dont est truffée la partie API Windows.

Pour les thèmes c'est à la fois simple et complexe. FMX est un framework graphique où tout est personnalisante tant dans les formes que les couleurs. Reste à savoir ce qu'on veut personnaliserai où le faire.

Pour les widgets, ce sont en fait des composants sous Delphi (comme Lazarus). Ils existent ou n'existent pas, sont fournis ou pas. Tout dépend des besoins. Concernant les graphiques la version de base de TeeChart est disponible. On peut prendre la version complète auprès de son éditeur ou auprès d'autres fournisseurs.
Et on peut bien entendu dessiner à la main si on ne trouve pas ce que l'on veut ou si on a des besoins spécifiques.

[bizulk]

Pour les thèmes c'est à la fois simple et complexe. FMX est un framework graphique où tout est personnalisante tant dans les formes que les couleurs. Reste à savoir ce qu'on veut personnaliserai où le faire.

Pour les widgets, ce sont en fait des composants sous Delphi (comme Lazarus). Ils existent ou n'existent pas, sont fournis ou pas. Tout dépend des besoins. Concernant les graphiques la version de base de TeeChart est disponible.
Et on peut bien entendu dessiner à la main si on ne trouve pas ce que l'on veut ou si on a des besoins spécifiques.

Pour la personnalisation de l'apparence, on peut toujours coder mais des systèmes plus déclaratif permettent d'avoir un travail plus réutilisable. Si je reprends pour référence QtQuick il y une notion de thème sélectionnable qui permet d'afficher le style "métro" de windows, de Google, et d'autre sur les widgets présent en standard. Ensuite pour creuser dessous il y a un système de CSS déjà utilisé chez nous.
Donc ma question était plutôt sur la façon dont supporte la personnalisation d'apparence, outre bien sur le langage de programmation.

Merci pour teeChart, bon candidat à première vue et licence abordable

[lotfi.lahcene]

Perso, je rencontre un énorme problème avec le FMX, une lenteur anormal de l'EDI ! surtt que c'est mon premier projet FMX...
je travail sur une seul forme sur laquelle j'ai mis un tabControl afin d’éviter le multiformes....et au fur et à mesure que j'ajout des composants...s'accentue la lenteur graphique de l'EDI...(au point de devenir un handicape insupportable) mais à l’exécution l'application (enfin...je veux dire la ou j'en suis avec l'application) fonctionne normalement (sous win)...
des Solutions ?

Delphi 10.2 Tokyo