Tokyo et OS X 64

Bonjour,

comme je ne possède qu'une version starter de Delphi XE10, je suis incapable de répondre avec certitude.

Je rencontre ce type de documentation :http://docwiki.embarcadero.com/RADSt...du_compilateur.

Je lis

Citation:

---

VER280
Delphi XE7 / C++Builder XE7
(Delphi :Win32/Win64/OSX/iOS/Android) (C++Builder :Win32/Win64/OSX/iOS/Android)

---

et aussi

Citation:

---

Delphi Tokyo / C++Builder Tokyo
(Delphi:Win32/Win64/OSX/iOS32/iOS64/Android) (C++Builder:Win32/Win64/OSX/iOS32/iOS64/Android)

---

En XE7 je ne peux construire que des applications OSX 32. Il semble que quand la cible soit uniquement du 32 bits, Embarcadero ne le précise pas. Ainsi en Tokyo, on voit apparaitre iOS32/iOS64 en remplacement du vieil iOS de Delphi XE7 (sous entendu "only 32").

Est-ce que cela signifie que Tokyo ne compile que pour OSX32 et non pour OSX64 ?
Merci. Cordialement. AD

Bonjour,

Effectivement, Tokyo (10.2) ne compile qu'en 32 bits pour Mac OS. La compilation en 64 bits est prévue en version 10.3 (cf https://community.embarcadero.com/ar...admap-may-2018).
En attendant, un binaire 32 bits peut quand même s'exécuter sur un Mac OS 64 bits.

Oui si on n'utilise pas de librairies clientes qui par nature sont installées par défaut dans le mode de l'OS (32 ou 64). Pour avoir galéré avec Lazarus sous OS X, je peux vous dire que cela a une grande signification au déploiement : forcer l'installation d'une librairie 32 au moment du déploiement (par un paquet nécessitant évidemment le respect des dépendances) sur une station qui fonctionne en 64... je n'en redemande pas. :ptdr:

Or comme FireDac nécessite l'installation de telles bibliothèques, c'est peut-être pour cela que cela a été une catastrophe avec XE7 OS X liée à une mariaDB distante (sur un serveur Nux 64) lors de mes essais. Par contre, aucun problème avec UniDac qui ne nécessite pas de lib externe.

D'ailleurs je me demande si les nouveaux produits d'accès aux bases promus par Embarcadero présentent cette intéressante "faculté".

Si cela arrive avec la prochaine version, c'est une lacune qui est éliminée. 8-)

Il ne me reste plus qu'à trouver un générateur de pdf à la hauteur (avec pagination, entête, pied de page...) et mon cahier des charges sera respecté ! Il faut que je teste TTMSFNCPDFLib...

Cordialement. AD.

Bonsoir,

Je ne sais pas si ça peut répondre à ton besoin de générateur de pdf, mais à l'époque de Delphi XE2, j'ai eu à utiliser QuickPDF (payant) de l'éditeur Debenu (racheté depuis par Foxit Software). Mon besoin n'était pas de générer du pdf, mais "OCRiser" des images présentes dans des pdf.

Pour l'instant seul le mode 32 bits est fournis avec Delphi pour OSX est aprés la réalisation de plusieurs progs multiplateforme, la version OSX m'a l'air pas du tout optimisé :aie:

J'ai comparer des traitements de lecture/calculs/écriture sur des quantités astronomique de fichiers est la version OSX était globalement 10 fois plus lente que la version WIN32 :calim2:

Est le soucis est bien du côté de Delphi car le même genre de traitement fait sous Qt sont aussi performant sous Windows que MacOS X.

Bonjour Der§en,

Sous FMX, c'est avec les streams que je constate une vitesse de traitement très inférieure à ce que propose Lazarus (sur toutes les plate-formes).
Avez-vous essayé UniDac avec Delphi ? Avec FireDac, je suis toujours en panne sous MacOS.

Je relève encore des données statistiques de capteurs dont les signaux sont envoyés à une base mariaDB par Internet. Effectivement je constate -après des débuts très difficiles- qu'avec Qt les temps de traitement sont compatibles avec la fréquence d'émission de mes signaux. Avec Lazarus aussi d'ailleurs. Avec FireMonkey, j'ai laissé tomber... mais je vais refaire un test. Je n'ai jamais été convaincu par FireDac ni par l'architecture qu'il impose pour son exploitation avec des dbGrids. En plus UniDac est multi plate-formes et multi IDE ;)... Dommage qu'il n'existe pas d'approche similaire en Qt !

Cordialement. AD.

Bonjour ApproxDev,

Si cela ne te dérange pas, je préféré le tutoiement au vouvoiement ;)

Non, je n'ai pas testé Unidac, mais à te lire, je pense que je vais me tourner vers lui et refaire mes tests avec pour comparer.

Dans mes prog, les traitements utilisent énormément les TStream, ceci explique peut-être cela.

Je ne suis super-fan de Firedac, pour avoir constaté certains effets de bords indésirable…

J'utilise les TFDxxxxxxx uniquement dans un Datamodule et je préféré gèrer à la main les "liaisons" avec les composants visuels.

Cordialement,

Der§en.

Citation:

---

Envoyé par der§en

Si cela ne te dérange pas, je préféré le tutoiement au vouvoiement ;)
Dans mes prog, les traitements utilisent énormément les TStream, ceci explique peut-être cela.

---

Rebonjour,

OK pour le tutoiement. Il va falloir que je fasse une liste.:mrgreen:
A savoir sur Unidac : Il existe une version de test. Lorsque sous Windows j'ai installé une version payante, sans désinstaller la version d'essai :aie: pensant qu'elle serait remplacée par la nouvelle, il y a eu une.... "bagarre" entre la version de test et la nouvelle au point que pour en venir à bout, j'ai préféré réinstaller une précédente image système de mon Windows installé. Donc renseignements pris, il faut absolument désinstaller la version de test proprement (y compris sous Windows la base de registre).... Sinon que du bonheur et de la simplicité notamment de déploiement ! En plus, autant que je me souvienne, tu peux faire baisser le prix d'achat en faisant de la pub pour le produit sur ton site Web si tu en as un.

A bientôt. Cordialement. AD.

Bonjour,

Citation:

---

Envoyé par Approdev

Je n'ai jamais été convaincu par FireDac ni par l'architecture qu'il impose pour son exploitation avec des dbGrids

---

là il faut que tu m'expliques je ne comprend pas vraiment

Citation:

---

Envoyé par der§en

Je ne suis super-fan de Firedac, pour avoir constaté certains effets de bords indésirable…

---

idem effets de bords de Firedac ? tu peux me donner des exemples ?

Citation:

---

Envoyé par der§en

J'utilise les TFDxxxxxxx uniquement dans un Datamodule et je préféré gèrer à la main les "liaisons" avec les composants visuels.

---

Pour ce qui est des DataModules moi-aussi, de toute façon cela permet de séparer l'interface utilisateur de la partie données, mais j'ai quand même des exceptions à la règle. Par contre pour ce qui est de la gestion à la main des liaisons :roll: j'ai encore quelques surprises avec les Livebindings, quelques critiques quant à la maintenance future aussi, mais côté FMX j'utilise à fond les LiveBindings (en faisant attention aux pièges de la facilité des liaisons "express" du concepteur toutefois)

à vous lire pour les explications

Bonjour Serge,

Le changement structurel, la superbe nouveauté, le plus !

Jusqu'à l'apparition de FireDac (et donc je suppose de FMX), il existait des composants spécialisés dbGrid, db... qui comme leurs noms l'indiquent étaient spécialisés pour accéder (r/w) aux bases de données de manière optimisée. Quiconque est rentré dans le source d'une dbGrid et d'une StringGrid en Lazarus, connaît l'ingéniosité de la première citée et la répartition des tâches dans le DataSet>>DataSource>>dbGrid. C'est pour cela par exemple qu'il est facile de réaliser une sélection de 3 lignes non contigües d'une dbGrid et que cela demande une programmation très ardue au niveau d'une StringGrid.

Maintenant dans un schéma classique FMX/FireDac,
Pièce jointe 291696
"... but now using LiveBindings you could bind your data to a TStringGrid or a TGrid."
C'est mieux paraît-il ! Plus général, plus puissant mais surtout moins rapide. J'ai fait de nombreux tests sur de grandes bases de données, comme je le racontais à Der§en. Quand tu as 6*6 mesures à la secondes que tu dois enregistrer à partir de ta station PC sur une base de données distantes, dont tu fais les statistiques quotidiennes, hebdomadaires ou mensuelles sur une autre station de traitement, l'accès aux bases compte ... Et jusqu'à preuve du contraire, le LiveBinding se traine même "programmé" à la main.

Voilà. Le LiveBindings sur les bases de données : :scarymov: Rendez-nous les composants db ou améliorez ce nouveau concept génial !
Alors tu vas encore me dire que je critique : mais en Qt, toute le chaine fonctionne acquisition >> base (sans saturation au bout de x minutes) puis "big table" >> station de traitement statistique également (dans un délai raisonnable). En Lazarus cela fonctionne, je suis prêt à parier qu'avec un vieux Delphi 7 (pas XE 7) cela fonctionnerait aussi. Peut-on y voir un rapport ?

Cordialement. Gilles

PS : je n'ai pas pu faire les tests de connexion sur la table avec FMX FireDac Mac OS puisque tu le sais, je n'ai pu me connecter avec mon XE7. Mais c'est un programmeur Qt et cela me semble une bonne référence quand on parle d'accès à des BDD. En Unidac, je n'ai pas comparé les temps d'accès Win/Mac mais de toute façon, c'est plus lent en effet. Par contre avec FireDac Win c'est encore plus lent qu'avec Unidac... Sur une petite table c'est peu perceptible mais sur de grandes tables, ou pour des séquences d'enregistrements fréquentes, on perçoit les limites de FireDac/LiveBindings sans pouvoir déterminer quel est le responsable exactement.

Citation:

---

Envoyé par ApproxDev

Jusqu'à l'apparition de FireDac (et donc je suppose de FMX), il existait des composants spécialisés dbGrid, db...

---

Bonsoir ,

c'est là où il ne faut pas supposer, Firedac et FMX ce n'est pas la même chose.
Firedac ne sont que les accès aux données (comme unidac) et n'ont rien à voir avec la disparition des DBgrid et consorts (pour preuve tu peux très bien utilisé le shéma indiqué en VCL)
Je suis d'accord j'ai plus que fortement été chagriné par l'absence de composants directement liés aux base de données en FMX et il m'a fallu plus qu'un certain temps d'adaptation (encore en cours). Je suis d'accord aussi sur le fait que les LiveBindings rende l'application plus lourde (en Ko) plus difficile à maintenir (une partie du code se retrouve dans le dfm en fait) mais :

Citation:

---

quand tu as 6*6 mesures à la secondes que tu dois enregistrer à partir de ta station PC sur une base de données distantes,

---

bon ça AMHA ça n'a pas besoin de passer par le visuel => pas de livebindings et la partie Array DML de Firedac devrait largement diminuer le temps d'exécution (j'ai été soufflé par la démo ArrayDML versus process normal)

Alors ne mélangeons pas Firedac et Livebindings !

Serge ;)

Non Serge, c'est trop facile.

FireDac et LiveBindings coïncident. Je te rappelle qu'autrefois, et encore dans Lazarus, l'association avec le dbGrid était liée au connecteur et faisait partie intégrante (et distribuée) de l'accès à la BDD. VCL je ne pratique jamais. Je viens de voir en effet qu'il existait une dbGrib avec une bonne vieille propriété DataSource.

En FMX, je "confondrais" si FireDac proposait "en réception" (SELECT) une autre solution que LiveBindings. Mais ce n'est pas le cas. A l'arrivée, je ne sais pas exactement où est le problème. Est-ce la partie connexion LiveBindings de FireDac, ou celle de TGrid ? Ce n'est pas performant.

Tu défends FireDac avec l'excuse que TGrid ne fait pas partie de FireDac ? Intenable pour l'instant, en première considération, selon moi parce que d'un côté du LiveBindings il y a une terminaison (?) sur le composant FireDac.

Je vais quand même vérifier le premier point avec VCL et un bon vieux datasource avec FireDac. Mais même si le test est concluant, cela n'exonère à priori en rien FireDac et sa partie Livebindings. D'ailleurs, je ne sais même pas comment vérifier "avant" le LiveBindings.

Ceci dit on ne va pas se courroucer sur ce point. J'évoque une situation limite.

----

Pour ton autre point de réflexion, je ne connais pas. Je n'ai pas vu la démonstration, ne l'ai pas testée. Par contre, dans le cas que j'évoquais avec Der§en, ce n'est pas le composant qui décide quand (à quelle fréquence) il envoie et comment il réalise les paquets de données. J'ai dû optimiser l'envoi des signaux. Je pourrais par exemple stocker toutes les mesures pendant une journée sur la station de captation puis les envoyer en une fois... mais le cahier des charges est "aussi proche du temps réel que possible".

En FMX, je "confondrais" si FireDac en émission (INSERT, UPDATE, LOCK...) n'était pas l'unique responsable... Il n'y a pas de LiveBindings ici. Et il est moins performant que le connecteur natif de Lazarus et les solutions proposées par Qt même en ne considérant que Windows. Maintenant qu'Embarcadero ait développé des méthodes pour pallier ces insuffisances, c'est recevable. N'empêche qu'en "émission", UniDac sous FMX fait beaucoup mieux sur une base mariaDB.

Bonne soirée. Gilles

Bonjour Gilles,

Citation:

---

Envoyé par ApproxDev

FireDac et LiveBindings coïncident. Je te rappelle qu'autrefois, et encore dans Lazarus, l'association avec le dbGrid était liée au connecteur et faisait partie intégrante (et distribuée) de l'accès à la BDD.

---

Firedac et Livebindings ne coïncident pas du moins de mon point de vue. Pour preuve je pourrais faire des programmes avec d'autres connecteurs ADO, IBExpress voire même ZEODBO ou même un simple cds (xml ou autre format) et utiliser des Livebindings. D'ailleurs si mes souvenirs sont corrects Firedac (AnyDac en fait) est apparu dans les packages avec XE4 alors que FMX et les LiveBindings sont apparus avec XE2 ? (faudrait que je retrouve cette version pour valider)

Pour "prouver" ce fait je pourrai te montrer ce que je viens de vérifier avec la version Starter sur laquelle, on est d'accord, il n'y a pas de Firedac ni de connecteurs aux BDD (sauf cds). J'ai installé zeosdbo et sur un projet FMX un Zconnexion,ZQuery,un TGrid. L'ajout d'un BindingsList (contenant un LinkGridToDataSource) et un TGrid me permet de visualiser ma requête sans soucis. tu noteras au passage que je n'ai même pas posé de Datasource ni même de Transaction, d'ailleurs dans ton schéma "Firedac" ces deux derniers ne sont pas utiles pour un schéma de base car :
- il y a une transaction par défaut intégrée (un FDTransaction c'est mieux si l'on veut modifier le comportement par défaut quoique s'il est le même pour toutes sources de données ...)
- un DataSource n'est pas nécessaire (sauf à utiliser un schéma plus compliqué maitre détail)

Pour "combler" la flèche rouge avec ? du schéma c'est le BindingsList avec un LinkGridToDataSource
Bon, je le concède, avec une version starter c'est pas évident et c'est beaucoup plus (trop?) facile avec le concepteur de liens.

Citation:

---

VCL je ne pratique jamais. Je viens de voir en effet qu'il existait une dbGrib avec une bonne vieille propriété DataSource.

---

je comprends, puisque tu fais des programmes FMX (traduction : multi plateforme), que tu n'ai pas regardé mais le bon vieux dev windows VCL a toutes les anciennes fonctionnalités, le hic c'est que VCL n'est pas portable

Citation:

---

Est-ce la partie connexion LiveBindings de FireDac, ou celle de TGrid ? Ce n'est pas performant.

---

c'est bien la partie connexion des Livebindings au TGrid (soit LinkGridToDataSource déjà cité)

Citation:

---

Tu défends FireDac avec l'excuse que TGrid ne fait pas partie de FireDac ? Intenable pour l'instant, en première considération, selon moi parce que d'un côté du LiveBindings il y a une terminaison (?) sur le composant FireDac.

---

l'exemple avec les zeosdbo (version 7.2.1 juste retouchée par mes soins, les packages, pour l'installation vers Tokyo) confirme ce fait il me semble ?

Citation:

---

Je n'ai pas vu la démonstration, ne l'ai pas testée.

---

j'ai indiqué le lien dans la discussion ici

Citation:

---

Par contre, dans le cas que j'évoquais avec Der§en, ce n'est pas le composant qui décide quand (à quelle fréquence) il envoie et comment il réalise les paquets de données.

---

ce n'est pas le cas de ce que j'évoque, c'est bien toi (le programme) qui décide de l'envoi donc aussi proche que possible du temps réel. Cela n'a rien à voir avec une taille de paquets comme pour la lecture.
en gros le principe est : j'ai une requête paramétrée type INSERT INTO TABLE(champ1,champ2) VALUES (:param1,:param2)au lieu de faire un execSQL par ligne, on rempli un tableau de paramètres et on envoi un seul Execute
par exemple pour ton ensemble de capteurs (6*6 donc 36 ?) on rempli un tableau de 36 paramètres et on fait un seul envoi à la BDD.
De mon expérience avec Firebird, cela revient à faire un SQL avec un EXECUTE BLOCK contenant (selon l'exemple) 36 INSERT
Limite de ARRAY DML il faut que le SGBD permette ce type de manip, et dans le cas de Firebird la taille maximum du SQL

Citation:

---

N'empêche qu'en "émission", UniDac sous FMX fait beaucoup mieux sur une base mariaDB.

---

Unidac fait mieux car si j'ai bien compris Unidac intégre le moteur (la DLL cliente pour les SGBD Oracle, MySQL, PostgreSQL, SQLite et NexusDB), alors que Firedac n'intègre que SQLite du coup, l'appel systématique a une DLL cliente pêche. Je me serai certainement tourné vers Unidac s'il avait intégré le moteur Interbase/Firebird

Citation:

---

Envoyé par SergioMaster

Unidac fait mieux car si j'ai bien compris Unidac intégre le moteur (la DLL cliente pour les SGBD Oracle, MySQL, PostgreSQL, SQLite et NexusDB), alors que Firedac n'intègre que SQLite du coup, l'appel systématique a une DLL cliente pêche. Je me serai certainement tourné vers Unidac s'il avait intégré le moteur Interbase/Firebird

---

Bonjour,
Voila une conclusion qui me plait bien ! Mais quelle idée d'utiliser Interbase/Firebird ? Le cœur a ses raisons que la raison ignore...
Sur cette petite provocation, à bientôt. Cordialement. Pierre.

Pour des raisons de coûts pour mes clients, j'utilise beaucoup MySQL, à vous lire vous êtes en train de dire que si je migre sur Unidac, je n'aurais plus à fournir avec mes EXE la DLL cliente de MySQL ?

Si c'est vrai, voilà une raison de plus de m'intéresser à Unidac…

@Sergio, pour les effets de bords, je voulais parler des "livebindings" plutôt que de Firedac, désolé d'avoir été aussi imprécis.

Bonjour Der§en,

C'est valable pour MySQL (MariaDB) et PostgreSQL, les 2 bases avec lesquelles nous travaillons. Les "Direct" n'ont pas besoin de librairies clientes "à joindre au programme" .
Pièce jointe 292625

C'est l'équivalent en Qt, d'une recompilation statique de l'environnement dans laquelle on intègre les librairies clientes aussi. D'ailleurs je cherche un partenaire pour faire cela : cela prend trop de temps :oops:. En Qt, on a même le "driver" natif (mariaDB et pas mySQL). J'ai demandé à mes "Qtiens" de service si on pouvait faire pareil en shared. Ils m'ont regardé "effarés". Encore une mauvaise question :ptdr:.

Bref, c'est valable dans tous les environnements avec lesquels sous Delphi XE7 j'ai travaillé (Mac OS, Win). Il faudra vérifier si c'est compatible FireMonkey Linux. Il me semble même l'avoir utilisé avec XE 7 sous Androïd (mais sans certitude).
https://www.devart.com/unidac/compatibility.html

Evidemment les programmeurs VCL ne comprennent pas trop l'intérêt (la supériorité) de la "chose" et dénigrent un peu trop systématiquement à mon goût le produit... L'écriture du code est une chose. Le déboggage et la compilation une autre. Mais le déploiement fait partie des temps de travaux et ils sont souvent conséquents même si déployer en Windows c'est de la rigolade à mon avis, d'où la satisfaction des utilisateurs de VCL sur leur fameux FireDac. Quand on se frotte un peu à Linux et même à Mac, d'un seul coup ce dernier (FireDac) paraît insuffisant. D'ailleurs c'est très curieux que FMX soit ainsi en retard sur la question (je rouspète encore ! Et Serge va ma taper sur les doigts : je sais FMX <> FireDac ! ). Enfin, Unidac fonctionne avec Lazarus et je crois avoir lu C# (mais sans certitude). Même pour un développeur indépendant, à mon avis, c'est un très bon investissement (sans les sources, une licence mono-utilisateur, un peu plus de 300 euros).

A bientôt. AD

Bonjour,

Citation:

---

Envoyé par der§en

Pour des raisons de coûts pour mes clients, j'utilise beaucoup MySQL, à vous lire vous êtes en train de dire que si je migre sur Unidac, je n'aurais plus à fournir avec mes EXE la DLL cliente de MySQL ?

---

Marrant, si l'on parle de question de coût, je ferais remarquer que MysQL est un faux gratuit, de plus loin d'être aux normes SQL. Je n'arrive pas à comprendre pourquoi c'est la plus répandu

Citation:

---

@Sergio, pour les effets de bords, je voulais parler des "livebindings" plutôt que de Firedac, désolé d'avoir été aussi imprécis.

---

Je ne t'en veux pas puis que Gilles fait l'amalgame entre les connecteurs de données Firedac (en est un mais Unidac aussi) et FMX des composants visuels. Du coup les Livebindings se retouvent intégrés dans la discussion. De plus tes "effets de bord" ne sont peut être pas ceux que moi je connais d'une manière plus "positive" voir mon tutoriel Episode 2 - 1°partie, chapitre II. Ma constatation à propos des livebindings, c'est que, peu documentés il sont difficiles à maitrisé dès que l'on déborde des besoins simples (liaisons rapides) et pourtant, plus je rédige de tutoriels (il y en a 3 en cours), donc plus j'approfondis plus je découvre de possibilités !

@Gilles

Citation:

---

Evidemment les programmeurs VCL ne comprennent pas trop l'intérêt (la supériorité) de la "chose" et dénigrent un peu trop systématiquement à mon goût le produit...

---

Comme je l'ai déjà écrit, je serais certainement passé à UNIDAC SI il y avait eu des liens direct avec Firebird (seul SGBD Open Source à ma connaissance et répondant presque aux normes)

Citation:

---

Mais quelle idée d'utiliser Interbase/Firebird ? Le cœur a ses raisons que la raison ignore...
Sur cette petite provocation,

---

parce que fin du siècle dernier lorsqu'il a fallu choisir un SGBD, Interbase semblait le choix approprié (même cher il l'était moins qu'Oracle ou MS-SQL). Parce que quand la version 5.6 (je crois que c'est cette version à moins que cela soit la 6) d'Interbase est devenue opensource :
a) la structure de la base de données de production était déjà faite
b) Firebird (puisqu'il s'agit d'un fork) à remplacé avantageusement (du point de vue $) Interbase
(à ce propos la page UNIDAC que tu as indiqué n'est pas à jour ou du moins cache le fait que Firebird 3 tourne sur Mac et sur Androïd )

Citation:

---

Mais le déploiement fait partie des temps de travaux et ils sont souvent conséquents même si déployer en Windows c'est de la rigolade à mon avis, d'où la satisfaction des utilisateurs de VCL sur leur fameux FireDac.

---

Objection (normal) une fois de plus Firedac n'est qu'un connecteur d'accès aux données (comme Unidac mais aussi ZEOSDBO) ce qui est intéressant avec Firedac c'est qu'il est (comme ZEOSDBO) relativement proche des anciens connecteurs BDE pour lesquels on trouve facilement de la documentation. Pour avoir tâter (un peu) des connecteurs types DBexpress (pour parler VCL) j'en m'en réjouit souvent. D'ailleurs si les utilisateurs de VCL se réjouissent de Firedac c'est que avec DBExpress il fallait toujours "déployer" quelque chose en plus des bibliothèques clientes SGBD

C'est le terme "déploiement" qui ne va pas. Tu utilises ce terme comme s'il fallait déployer les composants Firedac alors que ce n'est pas le cas. Ce qu'il faut déployer ce sont les bibliothèques de connexion SGBD clientes non intégrées (donc toutes sauf SQLite pour l'instant) et ce avec Unidac tu le ferais si tu travaillais avec MS SQL, Firebird etc..

Citation:

---

Quand on se frotte un peu à Linux et même à Mac, d'un seul coup ce dernier (FireDac) paraît insuffisant.

---

je me frotte souvent à LINUX (j'ai d'ailleurs de vieille appli VCL connecteurs BDE ou DBExpress puis ZEOSDBO qui tournent sous Linux) et encore une fois Firedac n'est pas à déployer (les bibliothèques clients des SGBD si). Tu fais toujours la même confusion du genre Firedac=>FMX=>Livebindings=>...=> déploiement de ....

Il faut scinder Firedac ou autre connecteur | FMX et donc (à moins de vouloir tout se farcir à la main) LiveBindings | Déploiement de bibliothèques au besoin

Citation:

---

d'un seul coup ce dernier (FireDac) paraît insuffisant.

---

pour moi ce n'est pas Firedac qui est "insuffisant" (même si j'apprécierai que les dll clients soient intégrées pour des applications= un programme) j'en ai pas encore fait le tour !

C'est plutôt la question des "paquets" (Androïd ou Mac) qui me pose problème, je suis sûr qu'il y a une solution mais je ne l'ai jamais lue :
comment partager une bibliothèque cliente entre n paquets ?
Unidac permet d'avoir le moteur client , intégré quelque part c'est donc comme si on mettait la bibliothèque avec le programme donc la taille est augmentée maintenant si je met deux paquets ou plus on est d'accord qu'à chaque fois je rajoute un client SGBD ? C'est là où je bute car j'aime pas les redondances

Dernier point qui fait pencher ma balance pour Firedac (puisque le moteur IB/FB n'est pas intégré) il est compatible avec une vision programmation multi-tiers (autrement écrit : Datasnap) est-ce la cas pour Unidac ?

Pourquoi le choix de MySQL (ou MariaDB) c'est qu'actuellement pas mal de mes clients (des PME principalement) migrent leurs serveurs WINDOWS Server vers des solutions à base de NAS avec nativement soit MySQL soit MariaDB.

Petite question, il existe une version de Firebird pour Sinology ?

Citation:

---

Envoyé par der§en

Pourquoi le choix de MySQL (ou MariaDB) c'est qu'actuellement pas mal de mes clients (des PME principalement) migrent leurs serveurs WINDOWS Server vers des solutions à base de NAS avec nativement soit MySQL soit MariaDB.

---

Je sais bien que c'est le SGBD le plus répandu mais c'est le pourquoi du répandu qui m'interpelle alors que c'est loin d'être le meilleur SGBD qui soit !

Citation:

---

Petite question, il existe une version de Firebird pour Sinology ?

---

d'après Makowski c'est possible voir cette discussion
un vieil article (en allemand, mais avec googletrad rien d'incompréhensible) semble également indiquer que c'est possible.
Après tout un NAS c'est souvent du LINUX comme OS

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

Citation:

---

Envoyé par der§en

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

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 :P. 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 :aie:

Cordialement. AD.

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 :

Citation:

---

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é :scarymov::ptdr:)

Bonjour Serge,

Citation:

---

Envoyé par SergioMaster

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

---

Non, non, tu penses bien !

Citation:

---

Envoyé par SergioMaster

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" :

Citation:

---

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 :

Citation:

---

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.

Citation:

---

Envoyé par SergioMaster

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

---

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. ! :oops:

Au plaisir de te relire. Cordialement.

Re Bonjour Gilles

Citation:

---

Envoyé par ApproxDev

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)

Citation:

---

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

Citation:

---

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

Citation:

---

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 :plusser: :ptdr: je te croyais plutôt normand, breton sort de ce corps !

Serge, une nouvelle fois tu as raison. Je ne parle pas de delphi 8O. 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 ? :mrgreen: Toujours plein de contradictions le bonhomme.

A bientôt.

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.

Bonjour Gilles,

Citation:

---

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)

Citation:

---

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 ....

Citation:

---

FireMonkey aurait du reprendre les bases du "canal historique"

---

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

Citation:

---

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.

Citation:

---

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 :aie: et j'avoue je n'ai plus d'inspiration depuis :arf:

Citation:

---

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

Citation:

---

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 :roll:

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

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 :roll: 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.

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

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 :weird:. Ou alors que dans Tokyo est apparu un TRichEdit, un vrai, avec sa version custom ? :yaisse1: + :yaisse:

Citation:

---

Envoyé par ApproxDev

Sinon tu ne m'aides pas beaucoup.

---

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

Citation:

---

Je vois bien TEdit, TMemo

---

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

Citation:

---

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 !

Citation:

---

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

---

No comment

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 !

Code:

---

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 ?

Bonjour,

Citation:

---

Envoyé par tourlourou

Code:

---

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.

Citation:

---

Envoyé par 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 !

---

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é : :evil:

Cordialement. AD.

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 ?

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 ? :aie:
Pièce jointe 294229
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. :oops:

Bonne fin de WE. Cordialement

Merci de ta réponse argumentée.