Bonjour Paul et merci pour votre réponse.
Je comprends et malheureusement je n'en tire pas de bonnes conclusions mais je vais quand même continuer à étudier la question : ras le bol de tous ces aller-retours Delphi <-> Autre chose sans avoir un avis personnel étayé (sachant évidemment que je garde Qt).
Mes conclusions actuelles et évidemment non définitives au bout de quelques heures de travail et de recherches sur la question :
- le code fonctionnel (ie le traitement métier des données) et celui des styles (ie la présentation des données) ne sont pas séparés : on est totalement à l'opposé d'une véritable architecture 3 tiers. Il y en a partout ! ma perception est qu'on a un cadre rigide mais sans les avantages qu'il devrait apporter !
- le choix retenu par Embarcadero est compliqué d'accès et d'utilisation. Enfin pour moi... mais quand on parcourt le web, pas que pour moi. Ce qui n'arrange pas mes affaires.
- le code n'est pas facilement réutilisable d'un projet à l'autre. Enfin il semble compte-tenu des "acrobaties" nécessaires et de l'imbrication que vous mettez en évidence entre les 2 couches.
- il faut que je trouve un autre moyen dans la limite de l'espace que me laisse la techno FMX... parce que je ne vois pas quel est son apport dans mes applis mais par contre, je perçois toute la complexité qu'elle m'impose. Dériver des composants, je ne faisais que cela en Lazarus... Mais j'obtenais le résultat voulu dans le cadre très "large" que me permet le langage. Là, j'ai un véritable problème. Si je dérive un composant sans aucun degré de liberté dans le cheminement de ma pensée, de mon savoir-faire pour respecter le cadre ultra-rigide de la pratique des styles que me semble totalement -bof je ne qualifie pas-, j'étouffe.
Il est totalement exclu que j'utilise le code que vous me proposez pour colorier en rouge un nombre négatif. La question est de savoir : "Est-ce la seule approche possible ?" Je n'ai qu'un QI standard... et je suis natif de la Terre (un seul cerveau utilisé à quelques %) ! Bref, la normalité... Alors avec un peu d'optimisme (en supposant que j'arrive à comprendre) quand je vais vouloir justifier des TMemo dans une cellule de ma Grid ou, comme j'arrive en Qt -après là-aussi de longs efforts de compréhension- en quelques lignes (en code "natif" en utilisant les widgets de base), à incorporer du HTML dans le "TMemo" -enfin il n'y en a pas besoin- de la cellule de ma Grid et par exemple à en changer la police suivant l'OS (par style), même en prenant une Grid TMS, ce genre de péripétie doit pouvoir être facilement gérée. Euh... c'était une phrase à la FMX et... une "simple" comparativement... Comment je vais gérer la dérivation de ma TMS Grid si je ne dispose pas du code source ?
Votre code est certainement fonctionnel mais je ne veux pas faire "cela"... Le type de code que je cherche à produire est celui qui je l'espère fonctionne dans l'exemple que j'ai relevé en XE6 : affecter le style à l'objet, cela me semble correct :
T.StyleLookup := 'textcellnegativestyle';
Si cela ne fonctionne pas, alors il y a peu d'espoir pour moi un jour de produire quelque chose en FMX.
Mais il y a toujours ce souci que me tenaille. L'approche que vous me proposez est adaptée à mon avis à de l'Androïd et de l'iOS. Un seul style pour l'appli, une "page", peu de modifications, peu d'objets graphiques, tous élémentaires... Et je développe principalement pour les Desktops. C'est pour cela -on en avait parlé- que je disais qu'Androïd Studio me semblait adapté à sa fonction et je crois me rappeler que vous m'aviez précisé qu'il n'était pas adapté à un codage "un peu" sophistiqué. Je sens FMX comme cela pour l'instant. Mais si le code XE6 "voulait" fonctionner, je changerais aussitôt d'avis parce que d'une manière simple, il élargirait le champ des possibles.
Encore merci pour votre aide. Je retourne essayer de progresser un peu.
Partager