Discussion :

[Invité]

pour en revenir à LiveBinding, ce n'est pas magique...

Je ne dis pas que c'est magique. Je dis 2 choses [voire 3]

1. Je ne veux pas m'en servir non pas par fixette mais pas raisonnement. J'ai toujours demandé à mes élèves de développer leur sens critique.
2. C'est pour moi une gymnastique qui ne vaut pas le coup compte tenu du reste du contexte [des composants vieillots dignes de delphi 7 : TEdit, Tlabel, TMemo,...] et encore en desktop firemonkey avec moins d'évènements qu'en VCL
3. Une approche [pas un code puisqu'il n'y en a plus] outrageusement compliquée, totalement absconse pour un résultat et des performances douteuses : en XE 7, j'avais réalisé 5 tests de traitements statistiques d'une base de données de relevés automatiques de température par une sonde distante, données chargées dans une TGrid ou équivalent.

• XE7 Livebinding et FireDac
• XE7 sans Livebinding avec Unidac directement connecté de manière classique sur des composants TMS
• Lazarus même code que le précédent
• Qt avec une programmation type Lazarus : on lit direment sur le Query
• Qt avec des classes QTableModel

Quel était le moins performant ? XE7 Livebinding et FireDac !

Bon je me remets au travail même quand on est à la retraite... Fini le WE !
PS : Pour moi, les lfm, dfm... sont simplement la traduction de l'UI Designer. Quand on commence à faire des liaisons avec des des bases de données dans ces fichiers, cela devient une mixture indigeste... On laisse l'UI d'un côté dans son langage de description et tout le reste s'écrit en C++ ou en Pascal

[Paul TOTH]

Intéressant ça, et tu vires RTTI ?

virer RTTI c'est plus compliqué, car toute la gestion des flux DMF/FMX est basée dessus mais à une époque de l'avais fait LVCL est un début de réécriture de la VCL de Delphi 6 / Kylix, complètement débarrassée des RTTI...mais ça impose que chaque composant connaisse le nom des ses propriétés.

et la RTTI c'est pas le mal, c'est super pratique en fait pour sérialiser en JSON/XML/CeQueTuVeux ... après elles souffrent de l'historique...C'est une structure mémoire assez mal foutue quand on y pense, mais la changer casserait sans doute la compatibilité avec pleins de produits. Exemple de choses que je ferais : extraire les chaînes dans un dictionnaire afin d'avoir des structures de taille fixe et éviter les redondances...aujourd'hui tu es contrains de parcourir la structure pour sauter les chaînes de taille variable qui sont nécessaire dupliquées si deux objets ont des propriétés avec le même nom.

[pprem]

On s'est nettement éloignés du sujet de base, Python dans Delphi, Delphi dans Python, oui ou non ?

Pour moi, il faut voir Python comme une extension possible de nos programmes. Au lieu de passer par une DLL pour faire un truc, on passe par du code dans un autre langage.

Etrangement on se posait moins de questions il y a 20 ans quand on devait distribuer 20 DLL avec un exe pour afficher un truc à l'écran.

Ceci dit, si on peut éviter les dépendances, quelles qu'elles soient, c'est toujours mieux, donc trouver l'équivalent Pascal de ce qu'on aurait déjà en Python me semble être la meilleure approche. Après tout est question de temps et d'ampleur du travail à faire. Le bénéfice / risque est-il vraiment en faveur du bénéfice ? Est-ce que c'est pas juste pour le plaisir d'avoir un truc qu'on sera seul à utiliser et maintenir alors que le troupeau (et la team de mainteneurs) se focalisera sur l'autre projet ?

--

Concernant les LiveBindings, oui, Gilles tu te concentres trop dessus et surtout sur l'assistant visuel (forcément très simpliste) pour les mettre en place. On peut très bien s'en passer quand on sait coder comme on l'a toujours fait depuis Delphi 1. Peut-être devrais-tu jeter un oeil à Open Wire que Boian Mitov a finalement mis à disposition gratuitement. Ca ajoute un éditeur dans la conception des fiches pour lier les composants entre eux. Une sorte de Live Bindings aussi, mais avec une philosophie légèrement différente.

Concernant le manque de HTML dans FMX (ou au moins de flexibilité de mise en forme des textes, puisque pour le reste on peut tout faire nous-mêmes), c'est aussi un truc qui n'était pas apparu à l'époque comme nécessaire : ceux qui l'ont développé n'avaient probablement pas la culture web où tout se paramètre facilement avec une feuille de style. C'est frustrant, j'en conviens, mais rien n'empêche de le faire nous-même et distribuer la solution.

On peut aussi faire des tickets de demandes de nouvelles fonctionnalités. C'est disponible sur https://quality.embarcadero.com et peut-être que ça permettra à Embarcadero de voir qu'il y a des demandes dans ce sens qui ne seraient pas remontées par leurs clients entreprises car elles utilisent du DevExpress ou du TMS Software partout plutôt que le socle de base fourni avec delphi.

--

Pour DzHTML, c'est vrai que son choix de balises est étrange, mais après tout ça reste un format classique pour mettre un texte en forme et même si son code source n'est pas limpide, on peut l'adapter (ou convertir du HTML) assez facilement.

[pprem]

Quand on commence à faire des liaisons avec des des bases de données dans ces fichiers, cela devient une mixture indigeste... On laisse l'UI d'un côté dans son langage de description et tout le reste s'écrit en C++ ou en Pascal

C'est pourtant ce qui se fait en VCL avec les composants dédiés depuis Delphi 1.

[Invité]

C'est pourtant ce qui se fait en VCL avec les composants dédiés depuis Delphi 1.

Ouii mais on fait cela avec une chaine de composants spécialisés donc optimisés pour cette fonction.

D'ailleurs, je n'ai jamais été vraiment convaincu par la fragilité des composants TDBxxx. A une époque les liaisons internet étaient fragiles et tout s'écroulait y compris l'application en cas de rupture de la liaison. Aussi en Lazarus et un peu en VCL, j'avais créé mon proprement composant un TlzStrindGrid. J'utilisais les threads pour les chargements pour avoir les premiers enregistrements affichés disponibles immédiatement, le reste du chargement, threadé lui aussi, continuait en sous-tache. Pas facile de threader une connexion... Et évidemment comme à l'époque le multisemect non contigu n'était pas disponible dans les TStringGrid de base, j'avais dû le créer. Ainsi que des icones de tris dans les header et des champs de recherche intégrés. Je m'étais inspiré de ce que proposait Windev à l'époque qui ergonomiquement laissait Delphi à des années... de retard. Il doit y avoir plein de discussions à ce sujet dans le forum Lazarus.

Mais là encore tu vois, je n'apprécie pas les composants FireDac and Co de Delphi. C'est typiquement orienté Windows où tu copies la libmyslclent.dll dans le répertoire de l'application. Mais il en est tout différemment en Linux et sous mac OS. Tu déploies régulièrement tes productions sur Linux et os mac ? Donc tu es obligé de faire des paquets pour installer les drivers des bases de données comme MariaDB. C'est une horreur surtout si un autre driver de la même BDD utilisée par un autre programme mais d'une autre version est déjà installé sur le poste. Il faut prévoir le cas. C'est pas parce que tu installes ton programme que celui de ton Collègue doit ne plus fonctionner. Avec UniDac, on ne déploie pas de driver de BDD. En Qt, je compile statiquement en incluant openssl et le driver de la BDD utilisée et cela d'ailleurs sous les 3 OS. Pour le déploiement cela change tout, y compris pour les mises à jour. En Lazarus/Delphi c'est un add-on payant. En Qt, c'est un savoir-faire, chronophage à chaque changement de version notamment de compilateur, mais très satisfaisant. La liberté, la fierté aussi

Cordialement. Gilles

[SergioMaster]

Mais là encore tu vois, je n'apprécie pas les composants FireDac and Co de Delphi.

FireDac est l'ancien <machin>Dac (AnyDac ?) concurent de Unidac à l'époque de D7

Avec UniDac, on ne déploie pas de driver de BDD.

Là, c'est de l'exagération.
Tout dépend du SGBD, seuls certains SGBD sont en direct (SQLite, MySQl, PostGreSQL, RedShift, Nexus, DBF ?)
dans mon cas, Firebird, je suis obligé de déployer la dll cliente tout pareil

[SergioMaster]

Pour moi, il faut voir Python comme une extension possible de nos programmes. Au lieu de passer par une DLL pour faire un truc, on passe par du code dans un autre langage.

Étrangement, on se posait moins de questions il y a 20 ans quand on devait distribuer 20 DLL avec un exe pour afficher un truc à l'écran.

Concernant les LiveBindings, oui, Gilles tu te concentres trop dessus et surtout sur l'assistant visuel (forcément très simpliste) pour les mettre en place.

aussi surtout la partie "très simpliste"

Peut-être devrais-tu jeter un oeil à Open Wire que Boian Mitov a finalement mis à disposition gratuitement.Une sorte de Live Bindings aussi, mais avec une philosophie légèrement différente.

à l'époque je n'avais pas accroché

Pour DzHTML, c'est vrai que son choix de balises est étrange, mais après tout ça reste un format classique pour mettre un texte en forme et même si son code source n'est pas limpide, on peut l'adapter (ou convertir du HTML) assez facilement.

Je m'y mettrai un jour, peut-être

[pprem]

Juste histoire d'en rajouter une couche sur Oui/Non Python et qu'est-ce qu'il propose à intégrer à Delphi, Embarcadero a publié plusieurs dépôts de code sur GitHub cette semaine pour simplifier les interactions entre un projet Delphi et des librairies d'IA / ML en Python.

A 17 heures Jim McKeeth présentera une session sur l'intégration de PyTorch à un projet Delphi en utilisant ces codes sources publics. dispo pur tout le monde, y compris les utilisateurs de la Community Edition.
https://blogs.embarcadero.com/pytorc...ces-libraries/

[der§en]

Je vient d’installer, Python 3.10.5 ainsi que PyScripter.

Ensuite, j’ai voulu installer Python4Delphi, mais impossible de compiler PythonVcl270.bpl sur l’erreur identificateur non déclaré : PyExc_RuntimeError dans le fichier WrapVclForms.pas.

Dommage que ce package, ne soit pas mieux testé avant sa publication , car cela avait l’air très intéressant !

[pprem]

Ensuite, j’ai voulu installer Python4Delphi, mais impossible de compiler PythonVcl270.bpl sur l’erreur identificateur non déclaré : PyExc_RuntimeError dans le fichier WrapVclForms.pas.

Dommage que ce package, ne soit pas mieux testé avant sa publication , car cela avait l’air très intéressant !

Difficile de tester toutes les combinaisons et configurations possibles surtout lorsqu'un langage ne respecte pas la compatibilité ascendante à laquelle on a été habitués en tant que développeurs Delphi (ou Pascal en général).

Tu n'as plus qu'à ouvrir un ticket directement sur le projet https://github.com/pyscripter/python4delphi/issues
(et éventuellement proposer la solution si tu l'as trouvée)

[Gouyon]

Pourquoi utiliser Python sous Delphi ? personnellement je ne le ferais pas...je n'aime pas Python mais une des raisons serait d'offrir à un utilisateur la possibilité de créer un plugin pour un logiciel dans un langage plus populaire que Delphi....et d'utiliser éventuellement les bibliothèques Python existantes dans ce plugin...

Moi non plus je ne suis pas très Pythonphyle mais il se trouve que pour un projet je suis en train de faire de l'IA (réseau de neurone et deep learning) et la plus part des librairies sont sous python (TensorFlow...). Du coup bien forcé d'en passer par là.

[der§en]

Je vient d'installé, la dernière version (M+1 depuis ma précédente tentative) et mon problème a l'installation a disparu

Du coup, je regarde les démos de Python 4 Delphi !

Je vais aussi regarder du coté de Delphi VCL 4 Python.