Discussion :

[Invité]

Bonjour,

je dispose de vieux sources qui dérivent la méthode CreateCellControl: TStyledControl; Avec ma version actuelle de Rio (la dernière), cette méthode est introuvable. J'ai utilisé mon NotePad++ pour trouver cette fonction dans l'ensemble du dossier sources/fmx : introuvable

Code :

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

1
2
3
4
type TPanelCol = class(TColumn)
 protected
    function CreateCellControl: TStyledControl; override;
 end;

[dcc32 Erreur] UFRM_Main.pas(40): E2137 Méthode 'CreateCellControl' non trouvée dans la classe de base

Code :

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

1
2
3
4
5
type TGenericColumn<T: TStyledControl> = class(TColumn)
  private
    FOnCellCreated: TCellCreatedEvent;
  protected
    function CreateCellControl: TStyledControl;override;[...]

[dcc32 Erreur] GridColumns.pas(14): E2137 Méthode 'CreateCellControl' non trouvée dans la classe de base

Pfffffffff... Merci pour votre aide.
Cordialement. Gilles

[SergioMaster]

Bonjour Gilles,

J'espère que tu seras patient, sur mon île mon programme actuel ne nécessitant ni FMX ni VCL mais palmes masque et tuba
En tout cas si CreateCellControl est aux abonnés absents c'est le cas c'est vraiment un sale coup !

[Paul TOTH]

je viens de contrôler, ça a disparu depuis un moment déjà je pense, probablement quand TGrid est passé en composant stylé. J'ai retrouvé cette méthode sous XE3 mais elle n'existe plus sous Berlin

dans XE3 TCustomGrid est un dérivé de TScrollBox, sous Berlin elle dérive de TCustomPresentedScrollBox

je ne sais pas quelle part des composants FMX est maintenant stylée, mais au départ c'était quelques uns et cela a tendance à ce généraliser.

[SergioMaster]

Re,

Finalement j'étais mal réveillé vacances obligent, il suffit de créer un TColumn, pour les exemples il suffit de regarder dans FMX.Grid, Le TColumn est déclaré à partir de la ligne 128 et les StringColumns et autres à partir des lignes 350
En fait si tu y regardes de plus près il n'y a aucune intervention de style (sauf pour la colonne CheckBox)

[Invité]

Bonjour,

conclusion,

il ne faut pas utiliser FMX "en pointillé" comme c'est mon cas et réactualiser ses codes régulièrement. Mais j'en ai marre de devoir réécrire mes codes à chaque version de XE. Quelle perte de temps ! La réutilisation de codes est quasiment impossible d'une version n à partir de la n-2 ou n-3 !

Evidemment c'est pour améliorer le produit... diront les optimistes. Je crois que c'est plutôt pour uniformiser les différentes briques achetées.

J'attends vraiment avec impatience la prochaine version de Lazarus avec la cible mac OS Cocoa 64 bits exploitable
Et pour iOS et Androïd, je compte à terme -mais c'est déjà en grande partie le cas- me passer de FireMonkey.

D'une certaine manière, la question est "résolue" : quand je fais la somme de toutes mes contrariétés avec les produits d'Embarcadero, les retards, les incapacités, l’instabilité des codes dans le temps, la difficulté à créer ses propres composants, ... je ne peux que me résigner.

2 mois sur les TGrids et ne pas être capable d'arriver au niveau de développement que j'ai atteint avec Lazarus ou Qt sur des composants équivalents, dénotent une certaine improductivité improductivité certaine à mon niveau. On a beau être un ancien développeur Delphi (le vrai) d'un niveau qui me satisfaisait, un développeur Lazarus ou Qt à peu près à niveau pour les exigences des applications que je développe, en FireMonkey, je n'atteins pas le niveau et franchement, je ne me sens pas le seul responsable. Si à chaque objectif, il faut rebâtir les sous-objectifs atteints -dans le meilleur des cas-, il est vrai que les approches se compliquent un peu !


Sur ce, comme Serge, je termine aussi mes vacances, "tranquillou".
A bientôt Gilles.

[SergioMaster]

Bonjour,

Le problème est qu'il y a deux versions de FMX, celle de départ avec XE3 était disons le, peu mature. Je ne sais pas trop quand est apparu FMX 2 (XE4 ?) mais cela fait un peu l'effet des versions ante et post Unicode. De plus, concernant FMX, il est très difficile de trouver les évolutions qui sont faites à chaque version (à part en fouillant avec soins dans les notes de release).
Cela dit je n'ai eu aucun problème de migration depuis les versions 10 (Berlin->Tokyo->Rio). J'avoue ne pas avoir tenter de migrer mon seul projet XE4 (cf tutoriel mes premiers pas avec les styles) vers Rio mais impliquant TList et Styles j'écrirais certainement un peu différement aujourd'hui.

Quant aux composants, finalement s'ils ne sont pas à utiliser en liaisons avec des données, je ne vois pas trop de différences avec un composant VCL "classique". Là où je butte c'est dès qu'il s'agit d'ajouter cette liaison. Le plus difficile et pas forcément recommandable est de faire un composant VCL et FMX sinon que reste t-il ?
La partie style, là c'est toujours un peu flou pour moi. Je sais comment indiquer un nom de style particulier pour un composant, je sais en théorie comment inclure un style non existant pour un composant mais de la théorie à la pratique Je ne désespère pas d'en finir avec mon RadioGroupBox , deuxième volet de mon tutoriels sur les composants mais je me suis trop dispersé sur d'autres sujets : Grid (que tu as lancé) m'a amené à TPath (pour dessiner des triangles) qui m'a ensuite poussé sur les SVG qui m'ont poussé sur les Gradients et les Styles, Quelques besoins pros m'ont relancé sur TList bref aucune chose n'est réellement terminé chaque sujet en entrainant un autre j'en suis même à penser à un OTA pour remplir TPath (Paul ayant déjà proposé sur GitHub un truc semblable pour les fontes).
Heureusement la pause vacance est là pour remettre (et vider la tête) les choses en perspective !

Sur ce, comme Serge, je termine aussi mes vacances, "tranquillou".

déménagement terminé ?

[Invité]

Bonjour Serge,

non, non je migre en Bretagne à partir du 19 août... Seul pour l'instant. J'essaye de convaincre Madame de déplacer l'entreprise familiale dans le 56... Comme l'essentiel de sa clientèle n'est pas locale, cela ne devrait pas poser de problème. Mais Madame est une Normande de souche (i.e. attachée à ses racines) donc pour l'instant . Et Caen est une ville très agréable à vivre.

Bon pour le reste, il est vrai que je me suis investi de manière soutenue dans Rio. Les composants tiers que j'ai achetés pour les Grids (TMS, TeeGrid) ne me donnent pas satisfaction et quand je vois la complexité d'améliorer -restons humble : de modifier- les TGrids, je peux comprendre. Néanmoins, quand je les utilise, j'ai l'impression d'avoir à faire avec des bricolages et non à du développement rigoureusement natif (donc pleinement intégré dans les concepts du langage utilisé). C'est du pur adaptatif pour obtenir à tout prix le comportement désiré. Si chacun fait comme cela, on ne s'en sort pas. A chaque version de XE, il faut réétudier tous les composants. A l'époque de Lazarus 0.9, cela me faisait "hurler". J'avais compris (imaginé) que FMX c'était du pur objet permettant l'inclusion simple des objets les uns dans les autres et donc l'intégration de n'importe quelle propriété par l'objet inclus dans l'objet de départ. Comme en Qt. J'en bavais déjà !

Mais ce n'est pas si simple. En Qt, tu prends l'équivalent d'une Grid. Puis tu places dans une cellule l'équivalent d'un TLabel qui gère le HTML et la cellule de ta Grid gère le HTML. Simple, efficace, natif... même si j'ai simplifié un peu le concept. Avec FMX, quid de ces m... de LiveBinding et de Style dans l'inclusion d'objets par d'autres ? Le principe de base était bon, mais ce que j'appelle l'enveloppe des objets (Style, LiveBinding), cela ne respecte pas la POO donc cela bidouille, cela n'a pas de cohérence, cela est remis en question à chaque nouvelle version... En réalité dans le temps, cela me semble impossible à gérer. Je ne demande pas un RAD qui fait tout à ma place. En Lazarus et en Qt, j'ai construit mes Grids à partir des éléments natifs et du code natif. J'attendais une telle plateforme pour FMX, un outil universel de développement, cohérent, stable. Je n'en ai rien à faire des styles ! Pour moi c'est un gadget. Par contre, sa présence imposée et pénible me complique la vie. Il en est de même pour le LiveBinding. Je n'ai pas cela en Qt ni en Lazarus et je fais au moins aussi bien et plus simplement au point qu'à la place de l'IDE je peux utiliser un simple traitement de texte pour écrire tous mes codes !

Affectivement comme toi, je suis lié à Delphi. Mais raisonnablement, en terme de productivité, je n'ai absolument pas atteint mes objectifs. Mon année sabbatique est terminée ce qui implique de devoir repasser en mode "pédagogie productive" aussi bien sur les PC que sur les tablettes. Heureusement, je n'ai pas misé que sur FireMonkey sinon je serais dans une impasse.

Ce qui me contrarie fortement est que pendant cette année, je me suis initié à d'autres langages notamment pour le développement mobile. Et de manière plus performante que ma démarche FireMonkey. C'est un comble.

Il faut dire que j'ai assisté à des "séminaires" ouverts (par internet) où n'importe quel béotien peut interrompre la "mise en oeuvre" et non pas la démonstration. D'ailleurs, si je n'avais repris de poste, je crois que j'aurais créé une société pour cette activité liée à l'apprentissage et à l'assistance au développement. L'entreprise familiale est déjà spécialisée dans ces activités mais pour la gestion, la paye, la compta, la bureautique "pointue", les CRM, le e-commerce... La partie développement n'étant plus essentielle mais au service des autres activités.

Je voyais avec intérêt la proposition de cours 3D sur le forum. C'est à Paris... Je me déplace bientôt à Bordeaux pour me perfectionner sur une plateforme mobile. Le problème, c'est le "cours" et pas le déplacement. Au contraire. Mais je n'y participerais que si j'avais un cahier des charges. On fait quoi ? Le mieux, c'est du concret. Par exemple un classique planétarium. Un peu ambitieux . Alors, l'effet de "fronde gravitationnelle à partir des Lois de Kepler". Les matheux préparent les équations avant la "réunion" et les transmettent aux intervenants. L'équipe qui assure la réunion transmet également avant celle-ci les pré-requis nécessaires faisant ainsi une piqûre de "rappel" (piqûre est le mot adapté dans mon cas). Et sur place, le(s) jour(s) de la réunion, on construit l'application : une sonde, une planète, des trajectoires d'approche de la planète par la sonde... et on visualise le résultat. J'ai fait cela avec des classes de Terminales en maths/info pour illustrer l'utilisation du calcul différentiel avec XE7. Mon projet ne marche plus avec Rio...

Evidemment je reste en contact avec FMX mais je ne pourrai pas l'utiliser pour mon travail. Avec regrets... comme d'habitude.

A plus. Gilles

[Paul TOTH]

... Je n'en ai rien à faire des styles ! Pour moi c'est un gadget. Par contre, sa présence imposée et pénible me complique la vie. Il en est de même pour le LiveBinding. Je n'ai pas cela en Qt ni en Lazarus et je fais au moins aussi bien et plus simplement au point qu'à la place de l'IDE je peux utiliser un simple traitement de texte pour écrire tous mes codes !...

alors les styles, sont un choix pour permettre à un composant donné d'avoir un look adapté à la plateforme cible...ce choix peut être critiqué, mais le problème n'est pas simple quand tu veux permettre aussi à l'utilisateur de personnaliser le look des composants.

Quand est-il sous QT ? le look de l'application est-il impacté par l'OS ? et qu'utilises-tu pour afficher les données à l'écran ?

[SergioMaster]

Bonjour,

Avec FMX, quid de ces m... de LiveBinding et de Style dans l'inclusion d'objets par d'autres ? Le principe de base était bon, mais ce que j'appelle l'enveloppe des objets (Style, LiveBinding), cela ne respecte pas la POO donc cela bidouille, cela n'a pas de cohérence, cela est remis en question à chaque nouvelle version...

Je ne suis pas totalement d'accord, considère les Styles (et pour la grid il y en a peu au niveau cellule) comme du CSS et cela s'éclaire d'un jour nouveau, même si je pense qu'il y a mieux qu'une image (en 3 résolutions donc beaucoup d'octets) découpée en région pour obtenir certaines informations (équivalent de skin ?) depuis que je me suis penché sur le TPath

J'attendais une telle plateforme pour FMX, un outil universel de développement, cohérent, stable. Je n'en ai rien à faire des styles ! Pour moi c'est un gadget. Par contre, sa présence imposée et pénible me complique la vie.

Imposée, oui et non en fait même en VCL tu trouves le principe (les apparences des options de projet) , d'ailleurs les .style dérivent des .vsf

Il en est de même pour le LiveBinding. Je n'ai pas cela en Qt ni en Lazarus et je fais au moins aussi bien et plus simplement au point qu'à la place de l'IDE je peux utiliser un simple traitement de texte pour écrire tous mes codes !

mais c'est également le cas tu peux très bien coder les Livebindings "à la main" sans utiliser le concepteur visuel c'est une gymnastique (il n'y a pas d'autre mots) plus délicate. Plus j'y pense plus je crois que mes années à utiliser le RPG (ou GAP) d'IBM s'avèrent utiles avec ses cycles et sa partie design (SEU)

Ce qui me contrarie fortement est que pendant cette année, je me suis initié à d'autres langages notamment pour le développement mobile. Et de manière plus performante que ma démarche FireMonkey.

Perso je me suis investi à fond pour comprendre le processus et j'ai maintenant du mal à me passer des possibilités offertes

Par exemple un classique planétarium. Un peu ambitieux . Alors, l'effet de "fronde gravitationnelle à partir des Lois de Kepler". Les matheux préparent les équations avant la "réunion" et les transmettent aux intervenants. L'équipe qui assure la réunion transmet également avant celle-ci les pré-requis nécessaires faisant ainsi une piqûre de "rappel" (piqûre est le mot adapté dans mon cas). Et sur place, le(s) jour(s) de la réunion, on construit l'application : une sonde, une planète, des trajectoires d'approche de la planète par la sonde... et on visualise le résultat. J'ai fait cela avec des classes de Terminales en maths/info pour illustrer l'utilisation du calcul différentiel avec XE7. Mon projet ne marche plus avec Rio...

ça je suis sûr que ça plairait à Grégory (gbegreg) moi, je ne veux pas encore m'investir dans ce genre de truc

Evidemment je reste en contact avec FMX mais je ne pourrai pas l'utiliser pour mon travail.

Hum, tu n'étais plus là à Nantes quand un de tes collègues (désolé je n'ai pas la mémoire des noms et ne retrouve pas le planning) à présenté l'appli faite en C++ de sa classe ?

[Invité]

Bonjour à tous deux,

alors les styles, sont un choix pour permettre à un composant donné d'avoir un look adapté à la plateforme cible...ce choix peut être critiqué, mais le problème n'est pas simple quand tu veux permettre aussi à l'utilisateur de personnaliser le look des composants.

Quand est-il sous QT ? le look de l'application est-il impacté par l'OS ? et qu'utilises-tu pour afficher les données à l'écran ?

Et bien je conteste. Chaque OS possède des widgets natifs. Je dirai un style "naturel". Evidemment si comme en Lazarus, on crée des wrappers pour les utiliser, on est sûr d'être dans le style. Je comprends évidemment que pour les mobiles chacun cherche à se distinguer par son "style", non pas de programmation, mais de présentation. A vrai dire, on ne peut pas faire grand chose d'autre (Courroux assurés de tous les développeurs mobiles ). En Desktop, c'est le contraire. Chaque utilisateur est habitué... à ses habitudes qui sont celles proposées par l'OS. Pour une très grande majorité des utilisateurs ce sont celles proposées par défaut. Par exemple, les boutons de réduction des fenêtres sont différents en Windows, Ubuntu ou mac OS. J'imagine mal placer les boutons à droite sous Ubuntu quand l'utilisateur les a laissés par défaut à gauche : contrariété assurée... même si on s'adapte à tout

Alors en Qt, malheureusement (et heureusement), on utilise les propres objets graphiques de Qt, donc il faut les rendre similaires au natif (comme FMX). Il existe des solutions et depuis longtemps même si elles ne se plieront sans doute pas aux Geeks qui ont choisi des skins particuliers pour leur(s) OS. Au hasard et en vrac :

• https://qt.developpez.com/actu/78902...iser-Ministro/
• https://forum.qt.io/topic/76620/can-...applications/3

La différence avec FMX est la simplicité en réalité. Cela se règle en quelques lignes de codes soit directement dans l'application, soit à l'extérieur. Et finalement, j'ai le style natif en ne faisant rien ou presque. C'est vraiment une épi-programmation sans impact sur le code. Evidemment pas de livebinding.
C'est un outil remarquable, une approche remarquable, des bibliothèques en nombre et pour tout. Il dispose de 2 approches composants :

• une approche composant classique plus compliquée que celle de Lazarus, autant que celle de Delphi notamment sous Windows, où il faut compiler les composants avec le même compilateur que Qt Creator par exemple si on veut les intégrer dans la barre d'outils de l'IDE, compilateur qui n'est pas forcément celui retenu pour l'application en cours de développement. Evidemment, on peut recompiler tout le framework à partir des sources. Je le fais systématiquement pour tous les OS desktop puisque j'utilise le développement statique. Cela me permet d'intégrer dans le framework SSL, mariaDB, postgreSQL... ce qui me libère de la distribution des bibliothèques clientes telles libmariadb... On lance cela le soir.
• et surtout la "promotion", géniale !

Alors Serge, je ne dis pas qu'il est impossible d'utiliser un TT pour développer les sources en FMX, mais enfin, tu admettras que "réaliser" (je ne sais même pas quel terme utiliser) du Livebinding avec un simple TT en dehors de l'IDE, c'est quand même pas évident ! Et pour les Styles, je n'en démords pas pour mon approche : aucune utilité. C'est très prisé semble-t-il. J'ai acheté Delphi Cookbokk Second Edition et on ne peut pas dire que ce n'est pas mis en évidence Cela frime... d'ailleurs je me souviens que mes stagiaires ont été impressionnés par la facilité de la chose. Mais ce n'est pas ce que je recherche. Sur une database SQLite embarquée localement sur un mobile, je préfère passer du temps avec SQLCipher à coder les données et la structure. C'est une des premières possibilités que m'a permise Qt. En Desktop, je mise plutôt sur la performance, des accès concurrentiels "fins", l'archivage des suppressions, des parades à la rupture de connexion internet... et la préservation des habitudes des clients et la simplicité. Dans une colonne de dbgrid, j'utilise (comme me le permettent mes maquettages Windev) :

• la visualisation du tri d'une colonne avec l'affichage des icônes nécessaires dans l'entête,
• par un double clic sur l'entête, l'ouverture d'un TEdit dans l'entête pour la recherche
• et évidemment les traitements par lot sur la dbgrid ce qui implique évidemment le multiselect non contiguë (et la visualisation "habituelle et naturelle dans le colonne fixe de gauche des lignes sélectionnées).

Alors évidemment c'est peut-être particulier, mais ce que j'admets mal c'est que Lazarus et Qt me permettent assez facilement de faire ce que je privilégie alors que FireMonkey ne me facilite pas la tâche, c'est le moins que je puisse dire... notamment pour les dbGrids.

Enfin pour le Collègue qui a développé en C++ Builder, j'espère qu'il ne dispose pas de postes Linux (voire macOS) dans son établissement... parce que sinon il fera la queue devant les postes Windows
Pour rappel, C++ Builder ne dispose pas de FMXlinux et j'ai encore souvent des problèmes sous macOS dus à la cross-compilation. Et est-ce que C++ en macOS propose le 64 bits ? Je sais les Windowsiens utilisaient (utilisent) le 32 bits sur des postes 64 bits. J'ai eu du mal aussi à utiliser la 6ème sur ma voiture habitué à seulement 5 vitesses

Lazarus depuis le 2.0.4 autorise la cible Cocoa-64 bits Génial... d'autant qu'Unidac fonctionne bien sous Lazarus. J'ai également les TMS mais ils ne me servent à rien puisque j'ai développé (par héritage) ma propre dbGrid. Vraiment dommage qu'iOS ne soit pas une cible de Lazarus et que son LazReport soit très loin de NCReport. Encore une possibilité avec laquelle FMX ne rivalise pas. Et en parlant de rivaliser, comparons le couple LiveBinding..TGrid avec l'approche DataSet-DataSource-TDbGrid de Lazarus/Delphi 7. Quasiment depuis l'origine le second permet "nativement" le Multiselect et pas le premier... D'ailleurs je comprends mal que FMX ne dispose pas d'un composant spécialisé pour les accès aux databases. Quelle régression !

On va finir par croire que je déteste Delphi. Ce n'est pas le cas. Mais il ne me permet pas de réaliser les développements avec les contraintes que je me suis fixé. Et cela passe toujours aussi mal... Frustré

Cordialement. Gilles