Discussion :

[SergioMaster]

L'autre "avantage" à mes yeux de MySQL, c'est l'excellent MYSQL WORKBENCH, pas sur qu'il existe l'équivalent pour Firebird !

Je n'utilise pas mais si c'est l'outils d'UPScene il existe aussi pour Firebird et je pourrais certainement en citer plusieurs équivalents (RapidSQL SQLMaestro) et pour Firebird/Interbase l'incontournable IBExpert ... chacun avec ses plus et ses moins

[ApproxDev]

Amalgame, amalgame...

C'est FireMonkey l'amalgame : VGScene + AniDac sont les solutions retenues (rachetées et rendues plus ou moins cohérentes). Je dois dire que je préférais l'original . Enfn ce n'est certainement pas nécessaire de l'écrire; Cela transparaît dans tous mes propos. Vous enlevez FastReport qui est un add-on. Il reste quoi ? L'utilisation du Pascal... C'est déjà cela

Cordialement. AD.

[SergioMaster]

Bonjour,
te connaissant c'est presque écrit volontairement pour faire réagir

VGScene = Firemonkey
AniDac = Firedac
FastReport ou autre ....
Après c'est une question de choix et de formation aux composants je présume car ta remarque :

rachetées et rendues plus ou moins cohérentes

me fait douter de cette belle adéquation
ce que moi je pense (mais il faudrait que je teste) c'est que le fait d'avoir une approche plus QT que Delphi change en partie la donne tout comme passer de VCL à FMX à changer le "mode de pensée" de l'application Delphi (jongler avec ces deux mondes n'est pas simple)


N.B. Je remarque quand même que tu n'écris plus FireDac (ça au moins cela semble entré )

[ApproxDev]

Bonjour Serge,

te connaissant c'est presque écrit volontairement pour faire réagir

Non, non, tu penses bien !

que moi je pense (mais il faudrait que je teste) c'est que le fait d'avoir une approche plus QT que Delphi change en partie la donne tout comme passer de VCL à FMX à changer le "mode de pensée" de l'application Delphi (jongler avec ces deux mondes n'est pas simple)

J'adore Delphi (enfin le langage Pascal Object). Ce qui me navre, c'est de voir ce que je suis capable de faire avec d'autres langages qui ne me sont pas naturels... et que je ne peux pas réaliser avec les limites de FireMonkey actuel. Pour le reste, tu as tout à fait raison. Sans Qt, pour moi, il n'y aurait jamais eu de FireMonkey. La modification d'approche obligatoire avec Qt m'a permis d'assimiler (un peu) celle de FMX. Je pense que pour un plein développeur VCL, la migration vers FMX est très délicate et pénible. La "déconstruction" nécessaire des acquis est très importante.

Pour en revenir aux limites, par exemple, mon éditeur de rapport sous Qt est NCReport Le prix environ 400 euros, celui de FastReport en version complète. Les descriptions des 2 solutions semblent assez équivalentes. Alors tu vas encore me dire amalgame. Mais il n'y en a pas. FastReport est fourni avec Delphi. Que ce soit une société rachetée ou une société tierce, je m'en moque. Ce que je regarde c'est ce que j'obtiens ou peux obtenir. Delphi a déjà changé de générateur de rapports.

Alors, j'ai posé la même question au deux sociétés avec mon "broken english" :

I should like to know whether it would be possible to print HTML tags of base64-image

Un extrait de la réponse de la société éditrice de NCReport :

Yes, it is possible. NCReport uses QTextDocument for HTML items and it supports the following subset:
http://doc.qt.io/qt-4.8/richtext-html-subset.html. I attach a tiny demo of such report [...]

Un résumé de la réponse éditrice de FastReport : Pas à l'ordre du jour . Lazarus contacté également à ce niveau : même réponse.
C'est là qu'une fois sorti des annonces, on constate les différences. Le miniHTML est une restriction, celle choisie par toute la "lignée" Delphi/Lazarus.

N.B. Je remarque quand même que tu n'écris plus FireDac (ça au moins cela semble entré )

J'ai toujours été un peu lent.. et têtu donc je ne reviens pas sur le sujet d'autant que je viens d'en remettre une couche avec FastReport. !

Au plaisir de te relire. Cordialement.

[SergioMaster]

Re Bonjour Gilles

Je pense que pour un plein développeur VCL, la migration vers FMX est très délicate et pénible.

je me considère comme tel (tiens compte du fait que je continue ma maintenance d'appli de D3-D2010 en plus de mes approches de FMX (à base d'heures de visionnage vidéos et écriture de tutoriels)

La "déconstruction" nécessaire des acquis est très importante.

bien là il y a plusieurs choses différentes :
- la partie composants, c'est vrai que l'adaptation au fait qu'un composant peut en contenir d'autres ça change un peu la donne
- la partie Style, là pour moi c'est le pire, la galère
- la partie LiveBindings on y revient, je commence à m'y habituer et ce même pour les nouveaux programmes VCL que je peux écrire. Un tutoriel est dans les tuyaux à ce sujet

Pour le reporting, là je me répète, Delphi ne fournit aucun outil de reporting mais propose des outils aux "bons soins" des sociétés tierces
ReportSmith, Quickreport, NevronaRave, FastReport et je ne sais plus lequel pour les prochaines versions (j'ai pas encore mémorisé) mais il y en a d'autres
et en général il n'est proposé qu'une version "limitée" charge à l'utilisateur d'acheter une version pro (en bref c'est un coup de pub)
Donc tout est encore une question de besoin (perso mes états n'ont pas besoin de HTML mais d'un état que l'utilisateur peut réarranger en cas de besoin sans toucher au code programme) de budget et de durée de vie de l'éditeur

Les descriptions des 2 solutions semblent assez équivalentes. Alors tu vas encore me dire amalgame. Mais il n'y en a pas. FastReport est fourni avec Delphi. Que ce soit une société racheté ou une société tierce, je m'en moque. Ce que je regarde c'est ce que j'obtiens ou peux obtenir. Delphi a déjà changé de générateur de rapports.

Embarcadero se limite à écouter les critiques de ses utilisateurs (Delphi ou C++) puis à faire ses appels aux sociétés tierces pour avoir une produit d'appel distribuable
à l'époque de la présentation de D2010, Rave avait été fortement critiqué (ça peut se comprendre) quand on m'avait demandé par quoi le remplaceriez vous mon choix s'était porté sur FastReport (un mix entre Rave et Quickreport, le meilleur des deux mondes ... pas sûr) je suis donc dans un infime pourcentage (parce que je ne pense pas avoir une oreille très attentive de la part d'Embarcadero) responsable de ce choix (sondages sondages ....).
Prends bien en compte la date toutefois, à l'époque le choix des générateurs Pascal Object était plus limité qu'aujourd'hui (un de mes arguments était surtout que de gros éditeurs (Sage, EBP je ne suis plus sûr de la liste) utilisaient déjà ce générateur

J'ai toujours été un peu lent.. et têtu donc je ne reviens pas sur le sujet

Lent je ne sais pas têtu ça je crois que je vais je te croyais plutôt normand, breton sort de ce corps !

[ApproxDev]

Serge, une nouvelle fois tu as raison. Je ne parle pas de delphi . Mais effectivement, je suis Normand de naissance et Breton de coeur depuis longtemps... S'il ne tenait qu'à moi, je vivrais en Bretagne depuis plusieurs années. D'ailleurs, mes week ends sont souvent bretons. Mais mon épouse n'est pas de cet avis... Le tourisme, oui, la résidence, non... et Caen est une ville fort agréable. Je me sens Caennais effectivement. J'y suis né et je revendique ces racines caennaises. Mais la Normandie ? Toujours plein de contradictions le bonhomme.

A bientôt.

[ApproxDev]

Bonjour,

Maintenant sur le fond : Serge, as-tu lu la réponse de la société éditrice de NCReport et as-tu suivi le lien qui y est inséré ? Elle me répond que NCReport est basé sur un "composant" Qt, un composant qui n'a pas d'équivalent en Delphi, ni en fonctionnalités, ni en capacités de programmation.

Et c'est là tout le problème de l'évolution de Delphi. Delphi/Lazarus n'ont jamais proposé dans leurs composants natifs un TEdit/TMemo digne de ce nom, gérant le HTML dans sa plénitude. Il a toujours fallu utiliser des bricolages très limités (RichEdit, ...). De ce fait que peuvent-ils demander aux sociétés tierces puisque eux-mêmes ne donnent pas le signal ? TMS a fait un effort, mais la philosophie de tous ses composants est mauvaise : au lieu de préférer un système d'emboitage des composants, par exemple, on aurait pu emboiter un TEdit ou un TMemo gérant le HTML dans des cellules de TGrid, ils ont développé des "monstres" autonomes, comme les TTMSFMXGrid et les TTMSFMXRichEditor.

Delphi VCL, c'était les composants. FireMonkey aurait du reprendre les bases du "canal historique" et pousser le langage objet plus loin en permettant d'inclure de manière développée des "custom components" dans d'autres composants. Là, le LiveBindings ou équivalent aurait eu tout son sens, en terme d'interactivité entre le contenant et le contenu (et réciproquement). Le modèle proposé est loin de cet objectif à mon sens. Il n'y a qu'un embryon d'idée (et de possibilités)... et on est déjà à la version 10.

Et il est vrai que je préfère de très très loin les capacités offertes par Qt même si cela demande parfois un travail de "modélisation" ardu. Mais ceci dit, si l'approche décrite au-dessus fonctionnait avec des exigences suffisantes (et non pas embryonnaires), la position de Delphi serait aussi remarquable que quand elle a introduit et développé la notion de composant.


Bonne journée. AD.

[SergioMaster]

Bonjour Gilles,

Delphi VCL, c'était les composants.

il faut préciser les composants Windows ou plus exactement à base de Windows (la plupart étant l'encapsulation d'API windows mais je schématise)

Delphi/Lazarus n'ont jamais proposé dans leurs composants natifs un TEdit/TMemo digne de ce nom, gérant le HTML dans sa plénitude

Lazarus est un fork de Delphi 7 Open Source donc parti d'une base VCL Windows (et ce même pour Kylix). Il y a t-il un "composant" windows qui le permette ....

FireMonkey aurait du reprendre les bases du "canal historique"

Firemonkey c'est VGScene donc son "canal historique" n'est pas celui des VCL

et pousser le langage objet plus loin en permettant d'inclure de manière développée des "custom components" dans d'autres composants.

je ne comprends pas car, pour moi, c'est plus que possible d'utiliser/dérivé des composants "Firemonkey" pour en faire ses propres composants et ces derniers peuvent très bien être inclus dans les composants existants. Le hic étant plutôt les styles, ça pour moi c'est encore un vrai casse tête pour ne pas parler d'une autre partie de mon anatomie.

Là, le LiveBindings ou équivalent aurait eu tout son sens, en terme d'interactivité entre le contenant et le contenu (et réciproquement).

ça encore, c'est possible cela fait l'objet d'un de mes tutoriels en cours de rédaction. Toutefois ce tutoriel qui sortira peut être à la rentrée ne me plais pas complètement faute d'un exemple vraiment applicatif.
J'étais parti du tutoriel de base Comment rendre un composant activé d'abord pour en donner des explications supplémentaires puis je me suis lancé dans l'écriture d'un composant : un TImage qui charge l'image en fonction d'un nom de fichier et non d'un blob. D'où, ajout d'une propriété (Fnomimage) et surprise, cela suffit ! pas besoin de l'activer d'avantage (ça fonctionne très bien avec une liaison BDD). L'activation LiveBindings ne permet qu'un chose supplémentaire pour ce composant : si l'on change la valeur de la propriété FNomImage celle-ci peut être répercuté (bi direction) vers un Label ou un TEdit et donc cela agit sur le concepteur visuel de liens .Mais AMHA c'est hélas pas utile,du coup ma démonstration tombe à plat et j'avoue je n'ai plus d'inspiration depuis

Serge, as-tu lu la réponse de la société éditrice de NCReport et as-tu suivi le lien qui y est inséré ? Elle me répond que NCReport est basé sur un "composant" Qt, un composant qui n'a pas d'équivalent en Delphi, ni en fonctionnalités, ni en capacités de programmation.

oui j'ai bien lu, mais il est peut être possible d'écrire ce composant en Delphi si toutefois on en a les sources pour s'en inspirer et dans les limites de Pascal Object

TMS a fait un effort, mais la philosophie de tous ses composants est mauvaise : au lieu de préférer un système d'emboitage des composants, par exemple, on aurait pu emboiter un TEdit ou un TMemo gérant le HTML dans des cellules de TGrid, ils ont développé des "monstres" autonomes, comme les TTMSFMXGrid et les TTMSFMXRichEditor.

Ces deux derniers sont de "simple" (enfin quand j'écris simple ce n'est pas vraiment le terme) dérivés des composants TStringGrid et TRichEditor, et en regardant les sources il y a bien "emboitage" dans certaines limites. Ce que je n'arrive pas à maitriser dans leurs composants c'est, encore une fois, les Styles. Et, je te coupe de suite, non, les styles ce n'est pas FireMonkey du moins pas totalement (et ce même si Firemonkey les utilise) pour moi il s'agit d'un dérivé des Skins autrefois proposé par des tiers pour "looker" des programmes VCL Windows de base de très triste figure

Pour ce qui est du HTML plutôt que le richeditor c'est le moteur d'un webbrowser light qu'il faudrait (mais ce n'est que mon avis perso)

@+
Serge

[ApproxDev]

OK, comme j'ai un petit peu de temps, je peux te proposer une petite réalisation en Qt à transposer en Delphi.

On n'utilise pas le WebBrowser car ce n'est pas un outil de saisie mais simplement de consultation. Et moi je veux écrire dedans, passer du DnD, des images encodées en base64. Tous les traitements sont prêts... séparément.

Le cahier des charges :
Etape 1 : Donc un composant natif, acceptant le HTML. Appelons-le tEditHTML. Cela veut dire quoi ? J'écris dans ce TEditHTML ce simple texte : "Ceci est un test". Je mets un 1er TButton sur ma TForm qui quand je clique dessus ajoute la balise <b> </b> autour du texte sélectionné "un test", la validation entrainant un réaffichage du composant TEditHTML en respectant le rendu HTML : "Ceci est un test.". Evidemment je peux modifier directement le contenu texte de mon TEditHTML par exemple en corrigeant "Ceci est un test." par "Ceci est un petit test." Exactement, comme je suis en train de la faire tout de suite sur ce forum.

En Qt : aller, 3 minutes. Je n'utilise pas un composant spécialisé. Ce serait en quelque sorte un TEdit standard. En Delphi on commence par quoi ?

Etape 2 : fois ceci réalisé. Je place une TGrid et je signifie à ce composant que la première colonne contient mon fameux TEditHTML et je "LiveBindings" mes liaisons. Je veux que la cellule puisse par exemple s'autosizer en hauteur, ayant défini une largeur de 200.

En FMX avec ses composants natifs, je ne sais pas faire... mais je veux bien apprendre Quand j'ai vu comment on faisait l'étape 1 en Qt, j'en suis resté sans voix. L'étape 2 a été un peu plus longue. Mais le résultat est là.

Si tu sais faire cela en Delphi (sans les TMS) avec les composants natifs, je suis preneur. Ensuite si tu veux, vu que je peux rendre publiques les sources et que dans ce forum j'agis en tant que particulier, je peux te le compiler statiquement en ce que tu veux : Win 32, Win64, Ubuntu 64, OS X 64...

Ce n'est pas sophistiqué comme demande.

[SergioMaster]

Ben je n'en ai aucune idée et pas le temps de me pencher dessus.
A la volée, je dirais : on part, comme pour le TRichEdit, soit d'un TCustomRichEdit soit de son ancêtre TCustomMemo

Faut pas croire comme ça, mais je bosse, les vacances approchent mais pas assez vite quand à la retraite elle est encore loin par manque de trimestres passés à l'étranger

[ApproxDev]

La retraite, la retraite... je comprends et je compatis. Je me rappelle d'un Président qui nous a fait miroiter la prise en compte des années d'études supérieures... Les promesses n'engagent que ceux qui les écoutent... je sais.

Sinon tu ne m'aides pas beaucoup.

"Dis Monsieur, c'est quoi un TRichEdit en FMX ?". Je vois bien TEdit, TMemo, mais ces composants-là n'ont pas d'approche HTML à ma connaissance... C'est certainement parce que j'utilise une vieille XE7. Ou que je suis gâteux avant l'âge . Ou alors que dans Tokyo est apparu un TRichEdit, un vrai, avec sa version custom ? +

[SergioMaster]

Sinon tu ne m'aides pas beaucoup.

j'ai écrit : "à la volée"

Je vois bien TEdit, TMemo

on oublie le TEdit, on garde le TMemo ou plutôt son ancêtre le TCustomMemo

mais ces composants-là n'ont pas d'approche HTML à ma connaissance...

c'est là qu'il faut se coltiner le boulot (en regardant les sources d'un TRichEdit VCL pour les traitements et propriétés). Ceci dit outre TMS il y a aussi HTMLComponent parce que ça risque de prendre un bout de temps à coder ce truc !

Ou que je suis gâteux avant l'âge

No comment

[der§en]

Sous Qt Creator, tu as aussi une idée tout bonnement GÉNIAL, c'est le "promote" qui permet d'utiliser un composant personnalisé visuellement à la place du composant de base en un 1 clic, j'aurait aimer trouver l'équivalent sous Delphi…

Il est vrai que l'absence de traitement de l'HTML dans Delphi est un manque vraiment génant, le nombre de fois où il m'a fallu "bricoler" un TRichView pour répondre aux demandes des clients, je ne les comptes plus !

[tourlourou]

Code :

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

type TEdit = TMyEdit;

judicieusement placée,cette redéfinition suffit à remplacer le composant désiré par celui voulu. Cela fonctionne-t-il dans l'EDI ?

[ApproxDev]

Bonjour,

Code :

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

type TEdit = TMyEdit;

judicieusement placée,cette redéfinition suffit à remplacer le composant désiré par celui voulu. Cela fonctionne-t-il dans l'EDI ?

Ce n'est pas le judicieusement placé qui compte mais les nouvelles propriétés qu'il faut créer. Qui s'y colle pour implanter des propriétés HTML dans un TEdit/TMemo custom ? J'ai fait cela en Lazarus, enfin modifier des RichEdit ou assimilés pour les rendre portables... Restait plus qu'à faire cela pour les rendre fonctionnels dans des Grids.

En Lazarus, j'ai abandonné la gestion du HTML. J'ai commencé par le MultiSelect dans des TStringGrids, puis l'affichage des TMemo dans des dbGrids, essayé d'améliorer l'ergonomie de l'accès à des données (alors avec le nouveau Livebindings, je ne sais plus où j'habite) ... pour me rendre compte que mon approche était mauvaise car le rafraîchissement des cellules était trop lent en partant dans des imbrications de customs. Partir d'éléments souvent rustinés de la LCL s'est révélé au final totalement irréaliste. Il fallait reprendre le problème à l'envers, partir des objets natifs que fournissaient les divers OS et bâtir des wrappers Lazarus les pilotant.
J'ai mis quelques réalisations épique d'il y a quelques années. Je n'ai pas cherché à être exhaustif; J'ai dû en poster sur le HTML aussi. Mon souvenir (cuisant) est qu'on rencontre souvent des problèmes inattendus dus pour la plupart à des modifications superposées les unes aux autres sans prendre le temps de nettoyer régulièrement les codes de la LCL pour les rendre maintenables et surtout adaptables aux demandes, aux besoins qui se font jour. Ces codes sont totalement imbriqués et figés et à mon avis le resteront; C'est pourquoi la LCL et la VCL sont immuables et ne bougent plus. Elles ne le peuvent plus sauf par un hypothétique énorme travail de réorganisation, d'assainissement. Pour VCL c'est un problème d'intérêt économique, nul en la matière : le parc des utilisateurs est en voie d'extinction. Pour LCL, c'est un problème de moyens (de développeurs et surtout de compétences dans chaque OS hors Windows) et de management de l'évolution de l'orthodoxie : ils sont "coincés" !

• https://www.developpez.net/forums/d1...fixedcols-1-a/
• https://www.developpez.net/forums/d1...s-multilignes/
• https://www.developpez.net/forums/d1...-natifs-mysql/

Mais FMX est un nouveau concept. VGScene est certainement plus récent. Maintenant, à mon avis, il faudrait examiner les codes sources de VGScene et espérer qu'il existe dans cet environnement un objet connecté sur les OS permettant d'afficher du HTML. S'il n'existe pas, il faut un spécialiste VGScene qui en construise un, qui sera par nature compatible avec chaque OS cible. Si un tel objet existe, le problème du wrapper serait simplifié pour un développeur Delphi. Mais existe-t-il ? J'ai vu que je pouvais me procurer ces sources... mais je ne connais pas VGScene et franchement je ne sais pas si cela vaut le coup de retourner dans ce type de programmation, ni d'ailleurs encore si Tokyo peut me convenir. Je suis obligé de faire encore beaucoup trop de concessions dans mon cahier des charges.

Sous Qt Creator, tu as aussi une idée tout bonnement GÉNIAL, c'est le "promote" qui permet d'utiliser un composant personnalisé visuellement à la place du composant de base en un 1 clic, j'aurait aimer trouver l'équivalent sous Delphi…

Il est vrai que l'absence de traitement de l'HTML dans Delphi est un manque vraiment génant, le nombre de fois où il m'a fallu "bricoler" un TRichView pour répondre aux demandes des clients, je ne les comptes plus !

Oui sauf que la promotion n'est pas aussi facilement portable d'un projet à un autre qu'un composant Delphi/Lazarus. La promotion est liée au projet alors que le composant est lié à l'IDE. Mais enfin, le "promote" fonctionne très bien avec quelques petits copier-collers d'un projet à l'autre. Ce que je veux dire c'est que le vraiment génial, c'est le composant Lazarus (comme de nombreuses choses chez Lazarus que je trouve nettement supérieures à Delphi - mais malheureusement Lazarus a oublié d'évoluer faute de moyens paraît-il ) , surtout quand on le compare au composant Qt. J'ai testé :

Cordialement. AD.

[der§en]

N'étant pas un expert Lazarus, je serait vraiment curieux de connaître ce qui rend un composant Lazarus supérieur à celui d'un Delphi ou d'un Qt ?

[ApproxDev]

Bonjour Der§en,

Pour Qt, c'est la compilation qui dans chaque OS (en share et en static) reste pénible. D'ailleurs, c'est la compilation de l'environnement qui est pénible et tellement chronophage que comme je l'ai déjà écrit, nous sommes en discussion pour sous-traiter. Les versions se succèdent avec leurs améliorations. Et je te rappelle qu'il faut EN PLUS compiler ce composant avec le compilateur utilisé pour Qt Creator pour l'intégrer dans ton IDE. Alors sous Windows, c'est en général un vieux VS totalement dépassé et évidemment pas le tien qui a servi à compiler Qt Creator. Evidemment tu peux recompiler Qt Creator avec le compilateur que tu as retenu pour ton environnement. On travaille de base avec les LTS. La 5.9 remplace donc la 5.6. Donc, avec mariaDB 5.5.56 (et openSSL), il nous faut recompiler : Windows 32 et 64, Ubuntu 64, ArchLinux 64 (non portable d'une Linux à l'autre), OS X.12 64 et quelques plugins "désopilants".

Par exemple, je viens de télécharger et installer une Qt 5.9.1 Mingw.5.30. Tu devines quel est le compilateur utilisé pour compiler le Qt Creator fourni ?

Et bien pour installer mon nouveau composant dans mon IDE et donc pouvoir en profiter, il faut que j'installe VS2015 pour le compiler dans la même "langue" que son IDE d'accueil... alors que j'utilise MinGW.

En Delphi c'est l'installation dans l'IDE qui n'est pas réellement transparente, il y a plusieurs formats. Il y a aussi le portage macOX et son debogage minable (pas celui de mac OS, mais la procédure retenue par Delphi pour la cross-compilation), peu pratique pour la mise au point sauf erreur grossière...

En Lazarus hormis l'icône associée, c'est totalement transparent. Tu réalises ton lpk et cela sera utilisable quasiment immédiatement. J'ai de vieux (vieilles ?) sources d'il y a plus de 10 ans, des boutons graphiques, des dbStringGrids maison, un gestionnaire de versions, des accès aux bases améliorés, une gestion de threads maison... que je charge facilement à chaque nouvelle version. Ils représentent plus de 5 ans de développements. C'est confortable mais quand même un peu inquiétant cette... "stabilité". Comme tu ne connais pas Lazarus, je te donne ma perception : Je ne porte pas vraiment l'équipe qui pilote Lazarus dans mon coeur (ni dans ma raison). Hormis le décès de l'un de ses membres fondateur, c'est toujours la même équipe depuis que je pratique Lazarus. Ils t'expliqueront, qu'il n'y a pas de successeurs volontaires. Ce qu'ils oublieront de préciser, c'est qu'il y a dissension dans l'équipe de départ et que certains innovateurs ont été ou sont encore marginalisés. Et, je ne parle pas de tous les développeurs qui ont mis au point bénévolement des composants et qui ont abandonné. A mon sens, il y a eu tromperie sur l'évolution de l'environnement ... car il n'y a même pas eu d'évolution, cette dernière n'étant pas régulée par l'évolution des OS mais par un dogmatisme obscurantiste lié au respect de la compatibilité avec Delphi 7 ! Un programme conçu avec Lazarus devait pouvoir être compilé en Delphi 7 avec LA release Lazarus 1.0 qui représentait la première version respectant l'Objectif, le Dogme. Totalement absurde notamment parce que Delphi 7 n'existe plus. Quel est l'intérêt de compiler aujourd'hui avec Delphi 7 ? Tactiquement, au début, il y avait un intérêt : la documentation de Delphi 7 qui était remarquable. Heureusement parce que celle de Lazarus a toujours été au mieux dépassée. Donc, au départ et certainement même aujourd'hui encore, la documentation de Delphi 7 pallie la faiblesse de celle de Lazarus. Autre point tactique qui finalement s'est retournée contre Lazarus : le potentiel de développeurs que leur amenait Delphi... sauf que les développeurs Delphi tous VCL à l'époque étaient exclusivement des Windowsiens. Pour un IDE de développement multi-OS, ce déséquilibre est particulièrement nocif. Alors quand tu leurs signifies une insuffisance, la pirouette officielle est "Cela fonctionne comme cela avec Delphi 7 donc RAS".

Mais malgré cela, il est très facile d'utiliser un composant Lazarus sans dévoiler ses sources, y compris en développement interne quand par exemple tu accueilles des stagiaires. Je me rappelle aussi des ancrages VCL et LCL. La nuit et le jour ! Même ceux de Qt Creator me semblent inférieurs. Reste que la LCL (finalement le coeur des applications) est à nettoyer. J'avais écrit sur leur forum il y a quelques années qu'au lieu de sortir de nouvelles versions sans vraiment d'intérêts, ils feraient mieux de refondre les codes de la LCL pour repartir sur des bases saines, excédé par leurs rétropédalages trop fréquents à mon goût. Totalement hors dogme, totalement hérétique : je me suis fait jeter !

Bon alors je retourne à Qt. J'essaie de comprendre comment intégrer en static une désormais obsolète Qtmultimediawidgets en 5.9.1. Et tu me parles de composants sous Qt. J'oublie... pour l'instant ! Je dois avouer que la promotion me suffit actuellement.

Bonne fin de WE. Cordialement

[der§en]

Merci de ta réponse argumentée.