Discussion :

[gvasseur58]

Comme décidé en février dernier, Embarcadero publie sous la plume de Marco Cantù sa nouvelle feuille de route semestrielle. L’idée essentielle est de revenir à un rythme annuel pour les versions de l’environnement de développement, avec deux ou trois mises à jour intermédiaires.

En premier lieu, Rad Studio Update 2 est annoncé pour cet automne : incluant de nouveaux styles et contrôles UX, cette mise à jour supportera l’édition anniversaire de Windows 10, en particulier Centennial.

Cependant, plus intéressante semble être la version RAD Studio 10.2 alias Godzilla prévue pour fin 2016 : inclusion des contrôles Konopka et Radiant Shapes rachetés récemment par Embarcadero à la société Raize Software (pour VCL et FMX), RAD Server multi-tenant (multi-tenancy capabilities), support de l’ordre Z pour Android (Firemonkey), QA Automation et surtout le retour très attendu de Linux sous la forme de serveurs Delphi et C++, RAD Server étant dorénavant proposé en version Linux avec intégration d’Apache.

La feuille de route voit encore plus loin puisque la version 10.3 prévue pour fin 2017 porte déjà le nom de Carnival et devrait tout particulièrement s'intéresser à macOS, mais un astérisque rappelle qu’il ne s’agit dans toutes ces annonces que de projections susceptibles d’être modifiées... Aussi nous arrêterons-nous à cette version 10.2, avec la réintroduction de Linux dont les premiers aperçus sont attendus avec impatience par la communauté des Delphistes et des programmeurs C++ Builder !

Source : Embarcadero

[archqt]

Bonjour,
par rapport à Qt/C++ et QtCreator cela donne quoi. Quelqu'un a déjà comparé les deux ? c'est juste par curiosité vu que je suis déjà sur Qt je ne vais pas changer.
Bonne fin de journée

[ApproxDev]

Bonjour,

je travaille sur les 2 (sur les 3 avec Lazarus ). En Delphi je n'utilise FMX qu'à titre personnel, en tant qu'ancien enseignant (une XE 7) et j'utilise Qt/C++ et Lazarus dans une SSII que j'ai créée avec mon père il y a plus de 25 ans, et que j'ai réintégrée il y a peu à la disparition de ce dernier des suites d'une longue maladie comme on dit.

Donc je suis un Pascalien universitaire. J'ai développé épisodiquement (en soutien) pour la société jusqu'à mon abandon de poste d'enseignant. Et avant de partir pendant 3 longues années je me suis formé à Qt (à partir de la version 4.8) difficilement, laborieusement avec des périodes de rejets:. Cela va un peu mieux Mais l'apprentissage de FMX n'a pas été plus facile, compliqué par mes habitudes en Delphi VCL et Lazarus.

Une énorme limite de Delphi totalement insensée est l'absence de Linux, corrigée partiellement par l'apparition d'une prochaine version "serveur Linux seulement". Alors FMX c'est un énorme potentiel visiblement mais encore mal abouti. On peut difficilement faire des applications Desktop aussi sophistiquées qu'en VCL. C'est pratique par contre pour la réalisation pour les mobiles (sauf processeur Intel.. en voie de disparition paraît-il). A l'époque où je découvrais les capacités de FMX, cela fonctionnait mal sur les mobiles bas de gamme (question de composant vidéo). FMX, c'est léger au niveau du débogage sur les plateformes Mac parce qu'on utilise la cross-compilation. Et FMX sous Mac (ou iOS), c'est la nécessité d'acheter un gros (i7/16Go) appareil Mac parce qu'il faut faire tourner dessus un Windows. J'avais naïvement essayé le câblage entre un PC et un Mac Mini bas de gamme.
Car ce n'est pas comme en Qt (ou en Lazarus) où on utilise l'IDE sur la plateforme de développement. Cela à mon avis est un énorme manque. Pour atteindre les bases de données c'est FireDac. Il n'y a pas d'équivalent en Qt. Je préfère utiliser Unidac (qui existe aussi pour lazarus). Les composants graphiques sont totalement obsolètes même s'ils s'améliorent. En réalité la solution vient des composants TMS Software. Certains sont portés sur Lazarus. Le Pdf est mal géré (sauf sous Mac car nativement). Les générateurs d'états sont arriérés quand on les compare à NCreport (voire même Lime) qui coûte pour le premier grosso le même prix que la version complète de la version light qui est offerte dans Delphi et qui est gratuit pour le second. Mais les FastReport (VCL, FMX voire Beta Lazarus) s'améliorent lentement.

En terme de productivité, pour voir les programmeurs C++ ("natifs")/Qt de mon entreprise, on fait pratiquement match nul... sauf quand je réalise une maquette Windev où là, ils sont vraiment à la ramasse. Mais Windev ne produit que du code Windows avec le niveau de sophistication que l'on peut obtenir en Qt (voire en Delphi). Mais si par exemple on veut gérer du texte enrichi, on arrive aux limites de performances de Windev et de Delphi/TMS software... et pas de delegate possible Alors, à ce moment, la finition demande largement autant de temps que la réalisation en Qt à qualité égale. Ce qui est long en Qt, c'est de constituer ses propres bibliothèques : Dnd entre 2 tableview, SpellChecker dans des QTextEdit...

Par contre, il y a un énorme avantage en Lazarus/Delphi, c'est le déploiement des programmes réalisés. Un exécutable (éventuellement quelques bibliothèque tierces) point final. On fait aussi bien en stactic avec Qt enfin presque... c'est souvent nettement plus compliqué.

En conclusion,

• Delphi n'est pas un concurrent de Qt pour le développement Desktop multiOS. D'abord parce qu'il ne gère pas Linux, ensuite même avec l'amélioration apportées par les composants TMS, je le mets au déphi (défi) de gérer du texte enrichi (HTML), de la visualisation, à l'édition et à l'impression. Avec Qt, nous arrivons à faire cela en incorporant même des images encodées en base64 y compris jusqu'à l'édition. Eux, ils en sont au "miniHTML". C'est frustrant.
• Pour le mobile, je ne sais pas, je n'utilise pas Qt pour le faire mais une autre solution. Par contre j'ai pu me rendre compte à titre personnel, que c'était sympa (réellement productif) autant que Windev Mobile.
• Enfin pour le moteur 3D, j'ai eu beaucoup de mal difficultés à comprendre l'approche et heureusement, les membres de ce forum ont été très patients. A l'arrivée, j'ai pu simuler la deuxième Loi de Kepler, avec des images de la Nasa (faites pour), en mettant en évidence l'effet de fronde sur les foyers, en jouant avec l'excentricité, les masses : fabuleux. J'ai bien vu les exemples fournis avec Qt (Planetarium) mais je ne les ai pas étudiés. Alors qu'avec FMX, le prof de maths et l'informaticien se font un énorme plaisir. Rien que pour cela, j'aimerais soutenir Delphi... Reste, non pas la tarification, mais l'approche commerciale du repreneur et d'ailleurs du précédent... et le soutien aux équipes de développement utilisant leurs produits. Il n'y a que des "vendeurs" dans cette nouvelle structure ?

Enfin une dernière petite remarque concernant les ancrages des "objets" dans les IHM. Lazarus est génial. Delphi est compliqué. Au départ je n'ai pas compris pourquoi... parce que je n'utilisais pas le développement pour les mobiles. Ensuite il a fallu cloner l'approche VCL (largement inférieure à celle de Lazarus) avec les exigences des mobiles. Le résultat est déconcertant mais fonctionnel. Enfin Qt (Qt Creator... on s'y fait. Plutôt efficace et rien de génial).
Et dernière chose qui fait l’intérêt à mon avis de Delphi/Lazarus, c'est l'utilisation des composants à comparer avec la réalisation de plugin sous Qt surtout si on veut les intégrer dans Qt Creator On comprend pourquoi la promotion existe en Qt.

Cordialement. AD.

[foetus]

On fait aussi bien stactic avec Qt enfin presque... c'est souvent nettement plus compliqué.

Si je ne dis pas de bêtises , lorsque tu intègres Qt en statique, tu passes en licence commerciale payante

[ApproxDev]

Si je ne dis pas de bêtises , lorsque tu intègres Qt en statique, tu passes en licence commerciale payante

Je crois que c'est normal pour une société de développement ? Non ?

De toute façon, j'ai déjà parlé de la tarification à maintes reprises. Ce n'est pas payer qui est un problème mais d'en avoir pour son argent et ce dont on a besoin. VCL ne m'intéresse pas par exemple. FireDac pas plus. Pourquoi je payerais cela ? Mais une assistance technique OK. Une "visibilité" sur Linux Desktop même à 3 ans m'intéresserait et même j'accepterais volontiers d'être beta-testeur. Je n'achète pas un paquet de lessive. Et cela se présente mal aux niveaux des interlocuteurs Delphi: il n'y en a pas ! Je n'ai pas besoin d'un vendeur ni d'un distributeur, j'ai besoin d'un interlocuteur connaissant le produit et faisant interface technique avec non pas son client, mais avec l'équipe de développement qui utilise ses produits.

Il ne faut pas rigoler : avec Windev/Webdev j'ai ce service et PC Soft propose même la possibilité de détacher un de leurs ingénieurs sur site pour plusieurs jours pour renforcer mon équipe... moyennant finances évidemment Si PC Soft faisait également du Linux et du Mac à un niveau égal au développement Windows que permet Windev, je balancerais sans hésitations tous les autres produits que j'utilise parce qu'à mon sens le support est aussi important que le langage utilisé.

Cordialement. AD.

[archqt]

Si je ne dis pas de bêtises , lorsque tu intègres Qt en statique, tu passes en licence commerciale payante

Bonsoir,
contrairement à une idée reçue tu as le droit de faire une liaison statique en licence LGPL à condition de laisser la possibilité au client de changer de version de Qt. Il faut donc fournir un fichier objet de l'application et la procédure pour que le client puisse faire lui-même le changement de bibliothèque.
Evidemment tu peux aussi fournir les sources ;-) mais ce n'est pas une obligation.
Après il est vrai que la liaison dynamique est plus simple, l'utilisateur change lui même la bibliothèque et tu n'as rien à faire (mais interdit sur iOS).
Bonne soirée

[ApproxDev]

Bonjour,

Un peu utopique non ? A partir du moment où votre programme accède à des serveurs, fournir les sources me semble un peu inadapté. Et fournir votre savoir-faire en clair, c'est un peu difficile à défendre économiquement. Chez nous, même la structure de nos bases locales (SQLite) est protégée par SQLCipher (y compris en Qt). Cela a demandé un travail supplémentaire. En Delphi ou en Lazarus avec Unidac, c'est une simple option à préciser dans le composant. Donc, quand je suis arrivé dans la "boutique", ces structures de bases en clair et la quasi absence de gestion d'exception dans Qt, m'ont laissé baba !

Cordialement. AD.

[Andnotor]

On ne va pas retomber dans les travers de la précédente discussion, n'est-ce pas

Et FMX sous Mac (ou iOS), c'est la nécessité d'acheter un gros (i7/16Go) appareil Mac parce qu'il faut faire tourner dessus un Windows. J'avais naïvement essayé la câblage entre un PC et un Mac Mini bas de gamme.

Je n'utilise pas FMX et ne connais pas Mac, mais n'y a-t-il pas un Remote Debugger pour Mac ? Est-ce cela qui coince dans la solution câblée ?

Enfin une dernière petite remarque concernant les ancrages des "objets" dans les IHM. Lazarus est génial. Delphi est compliqué.

As-tu déjà testé le TRelativePanel ? Ce n'est pas encore parfaitement intégré (certains contrôles ne sont pas supportés) mais fonctionne déjà pas si mal. Les composants sont positionnés relativement à d'autres composants, en déplacer ou redimensionner un déplace tous ceux qui y sont rattachés. Et pas de codage, tout ce fait par l'inspecteur d'objet

[ApproxDev]

Bonjour AndNotOr,

La solution câblée ? En réalité, je n'ai jamais su ce qui coinçait...puisque cela n'a jamais fonctionné alors qu'avec le Windows sur le Mac Mini cela a été opérationnel immédiatement mais inexploitable faute de puissance. D'ailleurs "on" m'a vite conseillé d'utiliser Windows en virtual box ou équivalent sur le Mac. Bon j'avais à l'époque une petite réduction sur le Mac (5%) et un prêt à taux nul de part mon appartenance à l'EN; cela a facilité la chose mais quand même !

Pour l'ancrage, j'ai eu des discussions épiques dans ce forum : "Je comprends vite mais il faut m'expliquer longtemps". Si un empilement de layouts dans le cadre d'une "FireMonkey Layouts Strategies" fonctionne en effet impeccablement, on ne peut pas qualifier cela de simple.

Mais bon je le redis, je ne critique pas sur le fond FMX (c'est un produit jeune... et puis sa 3D !) même si à mon avis il faut éviter 2 écueils : une spécialisation vers les mobiles ( peut être incitée par une répartition du CA allant dans ce sens), et une sous-traitance à des sociétés tierces comme FastReport pour des élément essentiels. Mes clients Linux basculent lentement soit vers Windows, soit vers Mac. Donc le Linux Desktop à mon avis ne me sera plus vraiment utile dans 2 ans, voire même avant, alors que le DataSnap sous serveur Linux me serait indispensable si je choisissais l'option Delphi. Mais qui sait ? C'est quand même incohérent de refuser de développer un programme parce qu'un futur potentiel Client fonctionne sous Nux et qu'on n'a pas de plateforme de développement. Delphi compile pour Mac OS (issu d'un BSD) et pour Androïd (issu de Linux), disposera d'une "base" Linux (server only) et ne serait pas capable de produire du Linux GUI ? Voila pourquoi je parle d'incohérence à ce niveau.

Non vraiment le problème, c'est le service. Tout à l'heure j'essayais de construire un bout de code Qt développé sous Linux et construit/compilé avec cmake. Sous Ubuntu 64 et Mint 32, RAS. Sur ma station Windows 7 [64], j'ai besoin d'utiliser le même code, cmake et le Mingw 5.3 [32] de ma Qt 5.7 (pour produire un exécutable compatible XP ultérieurement). Deux tentatives non réussies. Ma société est en vacances. Je poserai lundi la question au support Qt. Je veux pouvoir avoir le même service avec Delphi.

Cordialement AD.

[archqt]

En terme de productivité, pour voir les programmeurs C++ ("natifs")/Qt de mon entreprise, on fait pratiquement match nul... sauf quand je réalise une maquette Windev où là, ils sont vraiment à la ramasse. Mais Windev ne produit que du code Windows avec le niveau de sophistication que l'on peut obtenir en Qt (voire en Delphi). Mais si par exemple on veut gérer du texte enrichi, on arrive aux limites de performances de Windev et de Delphi/TMS software... et pas de delegate possible Alors, à ce moment, la finition demande largement autant de temps que la réalisation en Qt à qualité égale. Ce qui est long en Qt, c'est de constituer ses propres bibliothèques : Dnd entre 2 tableview, SpellChecker dans des QTextEdit...

Par contre, il y a un énorme avantage en Lazarus/Delphi, c'est le déploiement des programmes réalisés. Un exécutable (éventuellement quelques bibliothèque tierces) point final. On fait aussi bien en stactic avec Qt enfin presque... c'est souvent nettement plus compliqué.

Bonsoir,
il faudrait peut être voir avec Digia si vous avez le support Qt, pour combler le retard de départ par rapport à Windev non ? et Delphi/C++ Builder pour incorporer les composants dans QtCreator. Par contre en utilisant QML et le designer QML, les composants créés dans un projets sont disponibles dans le designer (car en QML un ficher QML=un objet).

Avec Windev le "10x plus vite" en développement cela ne fonctionne qu'avec des composants tout faits non ?

Bonne soirée

[ApproxDev]

Pour l'absence de sources, je ne suis pas convaincu du tout. Mais le problème ne se pose pas ici. Et pour le mobile on n'utilise pas. Donc idem.

On est mal parti sur Windev. Le 10 fois plus vite, c'est du marketing. On n'aime ou pas ce dernier (le marketing). Cela ne me concerne pas. Windev, on l'utilise à la main ou avec le Rad pour débuter. On peut faire ses composants ou pas. Evidemment comme pour Delphi ou Qt, il faut du temps pour l'approcher et maîtriser ce qui fait sa force. Le Rad n'a aucune importance. Franchement, je fais tout à la main avec plaisir tout autant qu'avec Delphi ou maintenant Qt. Mes serveurs de bases propriétaires (HyperFile) tournent sur des serveurs Linux 64 hébergé au même titre que MariaDB ou PostgreSQL. Mon lycée a fonctionné pendant des années avec Windev/Webdev/Hyperfile et je reconnais que cela m'a permis de mener de front mes développements et la maintenance nécessaire sans interférer de quelque manière que ce soit avec mes cours et leur préparation. Je doute qu'en Qt avec PHP/MySQL j'aurais pu en faire autant... à moins d'écourter mes nuits !

Maintenant cette contre-publicité envers les produits PC Soft,

• sert ceux qui les utilisent pour développer...
• permet à ceux qui ne les utilisent pas d'assoir leur soi-disante supériorité en matière de développement....

car je suis sûr qu'on trouve de bons programmes en Qt, Delphi et Windev et de mauvais en Qt, Delphi et Windev.
Windev, Qt, Delphi pour moi sont comme Windows, Linux, Mac OS : des solutions toutes aussi intéressantes les unes que les autres, mais de manières différentes.

Pour Qt je ne considère pas qu'il y ait du retard. Il est multiOS, possède son IDE sur chaque OS, gère même mieux le texte enrichi... On peut faire certainement plus personnalisé qu'avec Windev. Mais il est vrai que cela nécessite plus d'efforts au moment du développement. En Windev, la vérification orthographique est intégrée au champs de saisie RTF à condition d'avoir un libre office ou un Word installé sur le poste. On coche simplement l'option. En Qt, il faut intégrer un Spellchecker dans les QTextEdit... A l'arrivée, l'orthographe est vérifiée. Ce qui ne serait pas acceptable c'est qu'on soit obligé en Qt de renoncer à cette option. Et on en fait autant en Delphi (c'est incorporé dans certains composants TMS) et en Lazarus dans les TRichMemo (développé à la main comme en Qt).

Je ne partage pas cette attitude défensive dès qu'on parle d'un produit. Ils ont leurs avantages et leurs défauts. Les chapelles.... pfffff. Pour en revenir à ce que vous qualifiez d'insuffisance, je me rappelle mon premier programme sous Qt : lire un fichier ini. Souvent c'est essentiel au démarrage d'un programme. Sous Delphi/Lazarus, je place une exception un petit try..except..end. Si le fichier est corrompu, le except se déclenche... Et j'arrive avec ma tentative QSettings... Et si le fichier est corrompu, je le sais comment puisqu'on n'a pas d'exception à ce niveau ? "Ben", interlocuteur médusé par une telle question, "un petit m_pLabel(NULL) qui sera rempli lors de la lecture peut te renseigner... par exemple !" Impeccable et curieuse façon de procéder... Et, ici, on se dispense d'une remarque toute Qtienne : "les exceptions sont pour les nuls qui ne savent pas coder"... Non, c'est une autre approche et le résultat est semblable et garanti à l'arrivée.

Ensuite il y a une stratégie d'entreprise en tant qu'utilisateur. Et là se font les différences... et les choix.

Cordialement. AD.

[foetus]

"les exceptions sont pour les nuls qui ne savent pas coder"... Non, c'est une autre approche et le résultat est semblable et garanti à l'arrivée

Non c'est l'approche C++ d'une exception. En gros:

• Il y a un léger surcoût en performance lorsqu'on utilise les exceptions (voir point 3)
• Les exceptions sont fait pour remplacer le système "à la C" (voir point 3) "tester à chaque appel le retour (et/ ou un paramètre)". Même malloc
• De centraliser la gestion des erreurs. On lance une exception, elle va arriver gentiment à l'endroit où toutes les exceptions sont gérées (du moins c'est l'idée)

Donc tu mets cela dans une grosse marmite tu touilles et tu voies bien que coller des try/catch partout ce n'est pas le but des exceptions .
Puisqu'on se rapproche du système "à la C", et le petit surcoût en performance en plus.

Et même au tout début, on faisait la distinction entre les erreurs qu'on peut gérer plus ou moins facilement (un fichier mal formé, un utilisateur pas présent en base, pas de réseau, ...) et les autres (il manque une DLL, plus de place sur le disque dur, mémoire saturée, pas de réseau, ...)

Et les exceptions étaient surtout utilisées pour les erreurs qu'on ne savait pas gérer: on lançait une exception et le try/catch terminait l'application gentiment.

[free07]

FMX sous Mac (ou iOS), c'est la nécessité d'acheter un gros (i7/16Go) appareil Mac parce qu'il faut faire tourner dessus un Windows. J'avais naïvement essayé le câblage entre un PC et un Mac Mini bas de gamme.

Bonjour,

Bien que ce soit HS, je tiens à apporter mon expérience avec FMX, j'ai un mac mini ( mi-2011 ) avec un Core i5 de 2,3 GHz et 16 Go de RAM, windows est virtualisé avec Parallels Destop et je n'ai pas rencontré de problème de performance pour le développement d'application de gestion avec XE7.
J'ai même en maintenance une application de gestion de certains commerces ( front et back end ) assez conséquent qui est développé uniquement sous Windows ( donc avec la VCL ) et pas de problème de performance non plus.
[/HS]

[ApproxDev]

Bonjour,

Concernant le matériel APPLE, un Mac Mini à 16Go est un appareil spécifique : http://www.apple.com/fr/shop/buy-mac/mac-mini car je vous rappelle que les boîtiers sont scellés et donc l'ajout de RAM est impossible. Donc il ne s"agit pas d'acheter un appareil à 8Go d'autant que la mémoire est soudée.

Pour en arriver à un appareil correct, équivalent en terme de rapidité à mes appareils Linux ("kités" certes mais à un prix raisonnable.. et prévu), la facture avoisine les 2722 € HT. Évidemment si vous estimez qu'un PC bas de gamme avec 4Go, sans SSD, avec Windows 10 tourne de manière fluide, j'espère que vous ne facturez pas les temps de latence à vos clients !

Pour essayer de préciser le sens des mots : fluides sont les installations de Lazarus ou Qt/MinGw sur Windows ou Qt sur un Linux. Une latence, c'est l'installation de Delphi, de VS...

Mac mini [Simulateur]

Intel Core i7 bicœur à 3 GHz (Turbo Boost jusqu’à 3,5 GHz)
16 Go de mémoire SDRAM LPDDR3 à 1 600 MHz
1 To de stockage flash PCIe
Intel Iris Graphics
Adaptateur HDMI vers DVI Apple
Clavier Apple avec pavé numérique - Français
Guide de l'utilisateur (Français)
Magic Mouse 2
Kit d’accessoires

Cordialement AD

PS : zut, j'ai oublié l'abonnement à Parallels Desktop 99€ annuellement Et il faut aimer : j'ai rarement vu un tel foutoir sur mes écrans !

[free07]

Donc il ne s"agit pas d'acheter un appareil à 8Go d'autant que la mémoire est soudée.

Non, la mémoire n'est pas soudée, sinon je n'aurais pas pu faire l'upgrade à 16 Go

Pour en arriver à un appareil correct, équivalent en terme de rapidité à mes appareils Linux ("kités" certes mais à un prix raisonnable.. et prévu), la facture avoisine les 2722 € HT. Évidemment si vous estimez qu'un PC bas de gamme avec 4Go, sans SSD, avec Windows 10 tourne de manière fluide, j'espère que vous ne facturez pas les temps de latence à vos clients !

Merci de ne pas me faire dire ce que je n'ai pas dit

Cordialement aussi

[Serguei_TARASSOV]

Bonjour,
par rapport à Qt/C++ et QtCreator cela donne quoi. Quelqu'un a déjà comparé les deux ? c'est juste par curiosité vu que je suis déjà sur Qt je ne vais pas changer.
Bonne fin de journée

C++Builder est un vrai RAD (y compris les composants non-visuels) mais c'est important uniquement pour la conception visuelle et la simplicité.
Sinon C++Builder profit tous les avantages d'accès aux données de Delphi.
Dans "enterprise programming" t'a besoin les composants performants pour manipuler les grosses volumes des données de différentes types SGBD.
FireDAC (ancien AnyDAC) et UniDAC sont les solutions plus connues mais il y en a les autres.
En Qt c'est pas génial, i.e. QSqlTableModel / QSqlQueryModel sont assez primitifs et ne sont convenables que pour les cas simples et petites volumes.
Dans Lazarus le "data access" c'est quasiment nul (comme toute la palette de composant), il faut acheter UniDAC pour débuter le travail.
Il n'y a pas MVC dans Qt, MV uniquement.

Sinon Qt a ces avantages connus et si les pb ci-dessus ne te concerne pas c'est une très bonne outil.

[ApproxDev]

Bonjour Serguei,

Sinon C++Builder profit tous les avantages d'accès aux données de Delphi.
En Qt c'est pas génial, i.e. QSqlTableModel / QSqlQueryModel sont assez primitifs et ne sont convenables que pour les cas simples et petites volumes.

Parfaitement d'accord surtout quand je compare à UniDac.

Dans Lazarus le "data access" c'est quasiment nul (comme toute la palette de composant), il faut acheter UniDAC pour débuter le travail.

Tout à fait d'accord aussi. Pour diverses raisons et suite à divers essais, j'en suis arrivé à la même conclusion et j'ai retenu cette option.

Sinon Qt a ces avantages connus et si les pb ci-dessus ne te concerne pas c'est une très bonne outil.

Oui, comparés à Qt, C++ Builder, Delphi et Lazarus ne sont pas à la hauteur avec les composants graphiques tels que les Grids et d'une manière plus générale, tous les champs d'affichage/saisie même en les renforçant avec ceux de TMS. Et surtout ils ne sont pas personnalisables comme on peut le faire avec Qt. Les gestions de la saisie, de l'affichage et de l'impression du HTML et du RTF sous Delphi et donc sous C++ Builder puisque ce sont les mêmes composants, ainsi que celles de Lazarus (bien que différentes) sont simplement catastrophiques, totalement désuètes et limitées, à croire que les utilisateurs de Delphi/C++ Builder/Lazarus n'ont pas besoin du texte enrichi. Pourtant au départ le principe des dbGrids connectées aux DataSet est génial et à mon avis, supérieur à l'approche de Qt en ce domaine. Mais les développeurs de Delphi/C++ Builder se sont concentrés uniquement sur l'aspect des connexions au bases, délaissant totalement l'affichage notamment du HTML/RTF. D'ailleurs il suffit de regarder les capacités graphiques des TStringGrids (VCL) et des TGrids (FMX) fournies avec les actuels Delphi et C++ Builder pour se rendre compte du retard en la matière. A ce niveau, je les considère tout à fait moyenâgeuses et elles ne présentent pratiquement pas d'évolution depuis... Delphi 7, peut-être même avant. Enfin très grosse différence, la gestion des SIGNAL/SLOT de Qt qui même si elle est difficile à appréhender au départ est un immense avantage, une facilité de développement que je trouve maintenant incomparable.

En résumé, dans Qt il manque un accès aux bases à la C++ Builder et dans C++ Builder, il manque des composants modernes et facilement améliorables par le développeur comme ceux de Qt. Et pour rester équitable : j'apprécie les SIGNAL/SLOT de Qt inexistants dans C++ Builder et la présence des exceptions dans C++ Builder inexistantes sous Qt.

Cordialement. AD

[ShaiLeTroll]

à croire que les utilisateurs de Delphi/C++ Builder/Lazarus n'ont pas besoin du texte enrichi.

Tu confonds les développeurs et les utilisateurs des applications faites en Delphi
C'est le métier de l'utilisateur qui décide du besoin technique

1) HTML
En 15 ans, j'ai utilisé du HTML qu'une seule fois pour afficher un Hint et j'ai utilisé le THTMLCredit de TMS
le HTML était lui même issu d'un XML transformé via un XSLT et affichait tout l'historique de modification des valeurs (un besoin de forte traçabilité pour l'utilisateur de qui modifiait quoi et quand)
C'était l'approche choisi en D5 parce que le développeur voulait s'amuser avec ces nouveautés de l'an 2000, je n'ai fait que l'améliorer et stabiliser
la même chose pouvait être faite en stockant les infos dans une table et en jouant avec des TLabel positionnés manuellement (ben oui, le TFlowGrid n'existait pas et TDBCtrlGrid aurait été visuellement trop lourd)
Mais c'était moins fun et moins innovant !
D'ailleurs ce développeur avait aussi fait un XLST qui transformait un XSL en DFM, et la DFM pouvait être chargé via ReadComponent
Clairement un délire technique pour exploiter à fond le XSLT


Sinon, la plupart du temps un TWebBrowser affichant le résultat d'un script PHP, cela ne va pas plus loin !


Delphi VCL\FMX c'est du client lourd, on a tout plein de composant pour afficher ce que l'on veut, pourquoi se faire chier avec du HTML
(perso, la partie IHM du web est une vraie tannée pour moi, je préfère coder la partie serveur qui retourne du XML ou mieux du JSON laissant les pro du JS et du CSS faire leur boulot)




2) RTF
j'ai utilisé le TRichEdit, le plus souvent en lecture seule (finalement comme pour le HTML)
J'ai travaillé 9 ans dans le Médical\Socio-Médical, c'est là ou j'avais le plus de "texte" à afficher ou à produire
Le RTF, était un grand classique des versions informatisées du Vidal, des catalogues d'appareil médicaux, d'un diagnostique CIM ou d'un acte CCAM.
cela se limitait souvent à un titre, un sous-titre et un texte
Le plus souvent l'utilisateur préférait une version épurée du texte dans la TDBGrid pour une lecture rapide et le TDBRichEdit soit en dessous soit accessible en double-clic pour un texte plus long
A l'époque faut dire que la résolution phare c'était le 800x600 voire le luxe avec un 1024x768, il fallait faire des compromis

Pour avoir inclu, l'éditeur de RTF fourni sur le CD de Delphi 5 dans des applications, tu vois rapidement, que mieux vaut utiliser Word en OLE et faire du Publipostage

Avec un modèle Word + Publipostage, tu as obtients un beau document au contenu enrichi tout beau et un code simple ne se préoccupant que des données
C'est faisable en OLE, même si un peu pénible

Avec TReportBuilder + TwwppRichEdit, c'est plus cher mais à l'avantage de fonctionner sans Word sur un serveur d'impression (quand tu imprimes 5000 à 20000 documents par jour, tu n'as pas peur d'investir en outil et matériel)

Depuis, les 6 dernières années, alors que les utilisateurs ont maintenant des machines puissantes et des résolutions HD (mais pas des écrans beaucoup plus grand, les pixels sont devenus plus petits)
Beaucoup d'utilisateurs demande qu'on passe leurs Windows en 125% ou 150% pour avoir du texte plus grand.
Au final, un écran 1920x1080 avec le scale Windows, revient à un écran 1024x768, on affiche à peine plus de chose pour privilégier le confort sans noyer l'utilisateur d'effet visuel inutile et encombrant !


Mes autres années de travail en robotique ou vidéo-surveillance, le seul HTML que j'ai vu c'était parce que les appareils intègrent souvent un server web pour leur administration et supervision
Pas besoin de le faire soit même, un ShellExecute ou un TWebBrower sur l'URL cible et basta !

Maintenant, je travaille sur un ERP maison,
quand tu as une base produit de 400000 références, avec autant d'image miniature et HD, avec le descriptif en 5 langues, tu vas à l'essentiel !
Ce n'est pas du texte enrichi qui aide à vendre les 10 000 000 de produits par an !


Dans quel cadre tu travailles pour être obsédé par le Texte Enrichi, pour moi, c'est un élément anecdotique de mon travail
A part, les ressources humaines qui utilise du publipostage pour générer les contrats de travail, c'est bien la seule chose dans ce genre

Tout le reste, c'est du PDF généré via ReportBuilder pour les bons de commandes, bons d'expédition, de réception, les factures, les avoirs, ce qui compte c'est l'exactitude, le respect de la législation, la clarté, la simplicité de lecture du document
Et puis, évidemment, le plus important c'est l'EDI qui l'accompagne pour que les systèmes soit interopérables pour que tous les acteurs gagnent du temps !

[ApproxDev]

Bonjour ShaiLeTroll,

D'abord on ne se fâche pas. Ensuite on examine votre réflexion... Tiens, contiendrait-elle du texte enrichi ? C'est inutile pourtant. Curieux cela... C'est parce que vous utilisez votre navigateur préféré ? Oui c'est du Web... Et dans votre traitement de texte jamais de texte enrichi ? C'est bien un programme compilé celui-là ? Et donc dans Delphi compilé, vous n'en avez pas besoin. Je l'utilise tout le temps : je pense en couleur et en enrichi ! Mes clients aussi me semble-t-il.

Ensuite, c'est une impression que j'ai souvent en lisant votre forum, celle des habitudes VCL. L'ancien VCL ne le permet pas alors pourquoi cela aurait-il un intérêt ? Vous êtes en train de m'expliquer qu'une télé en monochrome me suffirait alors qu'on utilise des télés en couleur. Pourquoi n'utiliserais-je pas du texte enrichi -que ce soit RTF ou HTML- dans mes TMemo ou équivalents ? Ce n'est pas une fixation mais un besoin usuel. Ce n'est pas parce que VCL permet à peine de placer des puces (des listes) dans des TMemo que je dois abandonner cette idée. Dans un commentaire, je peux avoir le besoin de mettre en évidence un aspect. Pas vous ?

Donc la question se pose autrement pour moi. Pourquoi n'utiliserais-je pas le HTML dans la plénitude de ses fonctions avec un langage compilé de mon choix ? J'utilise comme tous mes clients des imprimantes couleurs, du PDF... et sous mes 3 OS ! Puisque vous me le demandez, mon dernier travail était un éditeur collaboratif... sous les 3 OS et à distance évidemment. Il ne vous arrive pas de rayer du texte ? D'un autre côté, vous pouvez avoir envie d'insérer un lien, une image évidemment dans votre éditeur. Faites cela facilement avec Delphi ! J'aimerais évidemment contrôler le choix des polices, la taille maximale, la taille minimale et en plus, la police d'impression ne sera pas forcément la police d'affichage, il peut également y avoir un ratio défini entre les 2 polices d'affichage et d'impression. Alors j'ai maquetté cela en Windev (en RTF) y compris le ratio (exe de R&D dispo) puis je l'ai réalisé en Qt. Évidemment les images sont déplaçables, codées en base64. Le texte même s'il est enrichi, dispose d'une vérification orthographique autonome à la saisie -comme le champ que j'utilise actuellement pour saisir mon texte sauf que là je vois la balise Size dans l'éditeur et que c'est peu esthétique et inutile-, d'un dictionnaire basé sur Hunspell et un dictionnaire pour chaque utilisateur, l'ensemble peut générer du PDF dans tous les OS et le visualiser.

Deux jours de travail pour faire cela en Qt, exe de R&D également disponible aussi à l'appui.

J'oubliais le copier-coller : il y a un peu plus d'un an alors que j'avais encore quelques heures d'enseignement pour quitter doucement et que j'avais déjà un pied dans l'entreprise (presque les 2) [jmon compte est devenu depuis dans ce forum un "Invité" lorsque j'ai quitté l'EN pour ne pas mélanger les genres], j'ai passé 2 semaines avec XE 7 avec la gestion du copier-coller qui était incapable dans certaines circonstances de coller ! Il pouvait coller du NotePad mais pas du NotePad++ ou l'inverse. J'ai retrouvé la discussion. Quant au plus évolué composant de TMS, essayez de gérer proprement les images dans le RichText Editor. De toute façon, l'impression ne gère que le miniHTML avec FastReport donc pas des images intégrées dans le HTML.

Bref, Delphi dispose d'un langage généraliste. Qu'il soit incapable de faire facilement ce que font d'autres langages généralistes cela énerve un peu. Alors évidemment, avec des recettes de sorciers, un truc plus ou moins portable sur la prochaine version de FMX, avec 50 ans d'expériences... peut-être, je vais vous croire sur parole, c'est faisable... Pas par moi, ni par beaucoup d'autres d'ailleurs. Que vous le vouliez ou non, dans ce domaine Qt est nettement supérieur car il permet sans bricolage simplement en utilisant les méthodes natives d'arriver à son but.
Ce qui n'empêche pas que j'apprécie Delphi mais que le FMX doit gérer proprement le HTML vu qu'une de ses cibles est le mobile... et qu'il doit me permettre de répondre à la demande de mes clients pour que j'en achète une version dans mon entreprise. Et pour l'instant, tel n'est pas le cas. On va patienter donc !

Dernière remarque, je ne sais pas ce que vous développez. Peu importe. Le problème (non la solution au mien) est le positionnement de FMX et TMS l'a bien compris avec ces composant d'un nouvel âge... dont vous n'avez pas besoin, j'en ai pris acte !... Et leur réponse commence à combler ma demande insistante (désolé)... Donc on ne se fâche pas. J'entends bien votre réponse. Pouvez-vous accepter que le recul de Delphi est partiellement lié à son manque d'innovation et de réponses à certains besoins comme les miens ? Et qu'on attend beaucoup de FMX et qu'il est encore temps de bouger et de faire bouger les sociétés tierces comme FastReport (et son antique FreeReport un peu amélioré) alors que d'autres comme TMS innovent chaque jour ?

Cordialement AD.