Delphi Starter Edition Survey Reminder

Bonjour,

j'ai reçu début juin une enquête intitulée "Delphi Starter Edition Survey Reminder" sur mon utilisation d'une Delphi Starter Edition, version gratuite que j'ai fait tester à des développeurs Qt.

J'ai répondu à cette enquête avec plaisir et posé 2 questions que, sans réponses d'Embarcadero, j'ai également posées hier à Barnsten. Je devrais recevoir une réponse complète la semaine prochaine.

D'abord le contexte que certains connaissent déjà : je suis un ancien enseignant, développant pour son établissement principalement en fin de carrière avec Delphi XE7 Architect Academic en ayant choisi d'utiliser exclusivement FMX. J'ai donc essuyé une bonne partie des plâtres :mrgreen:. J'ai quitté les 2 (l'enseignement et Delphi) pour remplacer mon père à son décès des suites d'une très longue maladie à la gérance de la petite SSII familiale qui développe en C++ depuis ses débuts, il y a plus de 30 ans maintenant -"seul langage avec le C dignes de ce nom" dixit l'équipe- et plus récemment Qt. C'est en plus le langage "familial" : mes 2 enfants ingénieurs informaticiens ne jurent également que par C++.... et évidemment, ils ne travaillent pas dans ma SSII mais dans d'autres ce qui semble conférer à leurs yeux encore plus de poids à leur argumentation... à laquelle je ne suis d'ailleurs pas toujours insensible ;).

Ainsi, je suis le seul Delphien dans mon environnement "proche" et j'ai failli baisser les bras de nombreuses fois, parce qu'il faut bien dire que, question soutien, Delphi fait très mal les choses depuis longtemps et que s'il n'y avait pas ce forum (et des Sergio), je crois que j'aurais abandonné depuis longtemps, convaincu à la longue par mon environnement... Je crois en effet que les diverses entreprises qui ont acquis Delphi, ont plus que négligé les développeurs VCL lors de l'introduction de FMX. Je crois que pédagogiquement parlant, on ne pouvait pas faire pire c'est à dire contre productif. Sachant qu'en plus de Delphi, comble de l'ineptie, je reste fidèle aux IDE de PC Soft depuis la version 5.5 !

Bref, dans mon cadre professionnel et familial, j'ai présenté à mes adorateurs de C++ des développement que j'avais réalisés en Delphi (cet antique langage... certes mais pas FMX et puis C et C++ datent aussi !). Et parallèlement, je m'étais préparé (aussi bien que possible) à Qt, ce qui paradoxalement m'a remis en selle pour l'apprentissage de FMX alors que mes vieilles connaissances VCL/LCL et les vieux réflexes les accompagnant m'empêchaient totalement de progresser en FMX.

Très rapidement, hormis l'absence de Linux desktop sous FMX (éliminatoire mais cela paraît être en cours de résolution 8-)) et l'obligation d'utiliser un Mac (j'adore le Mac :oops: -ce qui me contrarie un peu c'est d'utiliser Delphi dans VirtualBox), il y a 2 aspects du produit Delphi qui ne sont pas à la hauteur :
1. La correction des bugs de Delphi
2. L'absence de support technique professionnel

Je m'en suis déjà ouvert sur ce forum. Je (re)développe un peu : Il n'est pas admissible qu'il faille attendre la release suivante de Delphi (6 mois) pour obtenir la réparation d'un bug quel qu'il soit et surtout quelque soit son niveau de "nocivité" voire d'empêchement dans votre développement. Je ne sais pas où on trouve cela ? Je lis souvent des commentaires désobligeants sur PC Soft. Désolé, mais je n'ai pratiquement jamais été arrêté par un bug d'un produit de cette société. Il suffit d'être poli et un peu patient (1 semaine voire 2 grand max.) pour que le problème soit, soit corrigé, soit contourné. Par contre, il m'est arrivé de rencontrer sous XE7 des problèmes incontournables un peu comme sous Lazarus où c'est au programmeur-métier de rentrer dans le code des bibliothèques pour essayer de pallier le problème. Cela est hors de question pour ma petite équipe.

Le deuxième point est aussi crucial. Il se peut -mais c'est parfois encore le cas sur Qt ou sur les produits PC Soft- que l'on soit incapable de résoudre un problème de programmation ou que l'on demande conseil pour optimiser une approche ou un code réalisé. Nous avons besoin d'un interlocuteur technique si possible dédié, si possible contractuel. Nous disposons de cela sur nos produits de développement. Chez PC Soft, nous pouvons même louer le service d'un ingénieur maison. Je cherche une solution équivalente sous Delphi.

Donc j'ouvre cette discussion pour savoir comment les professionnels résolvent ces 2 problèmes auxquels ils sont normalement confrontés sauf à être évidemment ces "Dieux De Delphi incollables" qui ne rencontrent pas ces vicissitudes et donc pas besoins. Donc je m'adresse aux autres.

Merci pour vos témoignages. Cordialement. AD.

Bonjour,

Je me lance, histoire d'alimenter le débat avant la pluie de critiques, car après plus de soixante-dix vues pas de réponses me laisse perplexe (d'un autre côté on est samedi donc la veste pro est au placard)

Citation:

---

J'ai répondu à cette enquête avec plaisir et posé 2 questions sans réponses d'Embarcadero,

---

Si les questions tu les a posées lors de l'enquête c'est sûr tu n'auras pas de réponse rapidement. J'ai moi-même téléchargé une version starter pour "voir les différences" et du coup reçu cette enquête . A croire qu'il ne font pas de comparaison de fichier (pourtant le même mail, même user Embarcadero ça devrait se voir)

Citation:

---

s'il n'y avait pas ce forum (et des Sergio)

---

je me croyais unique :ptdr:

Citation:

---

Bref, dans mon cadre professionnel et familial, j'ai présenté à mes adorateurs de C++ des développement que j'avais réalisés en Delphi (cet antique langage... certes mais pas FMX et puis C et C++ datent aussi !).

---

Antique langage ... pas plus que C c'est une question de mode et de courage perso je reste pascal plutôt que C++ que j'ai longtemps pratiqué car j'ai horreur des -> le . c'est une touche en moins ;)
plus sérieusement RAD Studio (RX) c'est Delphi (ou plutôt pascal++) petit nom DX, mais c'est aussi C++ aka CX. Oui vous pouvez objecter que C++ est un parent pauvre de RAD Studio (évolution moins rapide) quoique j'ai dans l'idée qu'il rattrape petit à petit son retard. Un même EDI pour deux mes deux langages préférés ;)

Citation:

---

Je crois en effet que les diverses entreprises qui ont acquis Delphi, ont plus que négligé les développeurs VCL lors de l'introduction de FMX.

---

Je ne comprends pas bien la tournure de phrase.
VCL est uniquement pour le monde windows avec des contrôles (composants) natifs windows ou du moins les encapsulant.
FMX bon, bref, c'est une vision totalement différente.

A noter :
Testant la version starter, ce n'est pas avec cette dernière que la partie Livebindings est facile à maitriser : pas de concepteur visuel, c'est le gros :moinsser: que j'ai mis dans cette enquête.


Que la formation des développeurs VCL soit à faire pour migrer vers FMX, c'est sûr que ce n'est pas avec quelques webinaires que cela peut se faire (c'est peut être ce que tu voulais dire ?)

Citation:

---

il y a 2 aspects du produit Delphi qui ne sont pas à la hauteur :
1. La correction des bugs de Delphi
2. L'absence de support technique professionnel

---

Point 1. je suis en partie d'accord, en partie car la nouvelle politique semble être à nouveau aux hot fixes. Mais aussi parce que j'apprécie énormément ce que fait Dmitry Arefiev quand on lui signale un bug (via le forum EDN) à propos de Firedac : s'il s'agit d'un "vrai bug" il indique ce qu'il faut changer dans les sources et surtout où (une re compilation du paquet, la copie appropriée aux bons endroits et pff plus de bug). Bon c'est vrai, cette méthode a son défaut : ne pas écraser ces nouveaux paquets par une réinstallation! mais ce bug sera ensuite corrigé dans la future release et même peut-être lors d'un hot fixe s'ils se tiennent à ce nouvel engagement. Mais, c'est vrai une entreprise ne devrait pas avoir besoin d'un "programmeur métier" (enfin selon ta définition) obligé de regarder sous le capot .

Point 2. Je n'ai eu a utiliser que deux fois mes jetons de maintenance et ce à des années de différence, dans les deux cas la réponse n'a été différée le plus souvent que par le décalage horaire (pourquoi faut-il qu'ils dorment la nuit ?).

Citation:

---

Nous avons besoin d'un interlocuteur technique si possible dédié, si possible contractuel. Nous disposons de cela sur nos produits de développement. Chez PC Soft, nous pouvons même louer le service d'un ingénieur maison. Je cherche une solution équivalente sous Delphi.

---

Pour ce qui est d'un support technique français il y avait à ma connaissance deux groupes mais :oops: j'ai égaré les cartes, si je les retrouve je te les envoi.
Je ne connais pas assez Barnsten du moins autrement que la partie commerciale.

Citation:

---

sauf à être évidemment ces "Dieux De Delphi incollables" qui ne rencontrent pas ces vicissitudes et donc pas besoins

---

je suis loin de ne pas en rencontrer même si je suis d'Yeu (l'île) <= mauvais jeu de mot sur mon lieu de naissance mes chevilles enflent :roll:
mais j'ai des besoins "basiques" pour mes programmes de gestion ce qui explique peut être que allié à mon expérience je rencontre moins de problèmes

Fin de journée, tu excuseras les fôtes et disgressions
@+

Bonjour Serge,

Sur la forme, je m'y attendais un petit peu. C'est samedi... et les "vrais pros" ne rencontrent pas de problèmes ! Donc inutile d'insister : aucun problème ! A moins que conscients de ce problème, ils l'aient réglé et qu'ils souhaitent garder la confidentialité de leurs solutions. Ce qui est facile à admettre.

Mais je persiste. J'essaie de trouver des pistes.

Pour le sondage : oui, l'endroit est certainement mal placé. Mais le seul moment où j'ai eu un contact "officiel" avec Embarcadero c'est un message automatique me délivrant ma clé de débridage. Le reste c'est de la pub !

Sur le fond, en ce qui me concerne, ce n'est pas un problème de fierté déplacée ou non mais maintenant une simple équation économique pour pouvoir utiliser Delphi de manière profitable. Avoir 2 approches multiOS au lieu d'une seule actuellement est également un gage d'efficacité et d'optimisation des développements. Hormis mon intérêt personnel pour cet IDE, le côté professionnel a donc tout son sens.

Quand dans tes développements tu dépasses ton "target time", quand tes durées de flottement se mettent à filer et devenir totalement incontrôlées et absurdes, tu n'as plus aucune sécurité et tu n'es pas compétitif par rapport à l'utilisation et aux capacités d'autres plateformes de développement qui ont les mêmes OS cibles. En plus, cela détruit la sérénité et le plaisir de ton équipe qui a l'impression -et ce n'en est pas une- de courir après le temps. Certes, on apprend à travailler dans le stress mais je ne suis pas adepte de cette solution qui ne me semble absolument pas pertinente, certainement à cause de mon parcours personnel et de ma passion pour la programmation. Tu excuses le vocabulaire. J'ai enseigné cela longtemps... dans le cadre d'un cours de maths appliquées. Et appliqué, cela fonctionne superbement et contrairement à ce qu'on pourrait croire, c'est beaucoup plus facile à mettre en place avec une petite équipe qu'avec une grande... et même une mise en place "individuelle" est réalisable et induit une qualité de "fonctionnement" intéressante. Donc pour en revenir à ma recherche, tu intègres un coût supplémentaire parfaitement déterminé (un contrat annuel) dans le prix de tes développements, tu contrôles à nouveau des durées de flottement et tu atteins ton temps "cible". Et si tu disposes de plusieurs plateformes de développement, tes capacités d'adaptation à la demande augmentent.

Avec Delphi, je pourrais citer un nombre significatif de problèmes autant inexpliqués qu'inattendus que je n'arrive pas à résoudre. Deux horripilants pour moi :

1. Le copier-coller de texte avec des sources "étrangères" (issues de traitements de texte),
2. "Mon" problème FireDac sur une base mariaDB hébergée sur un serveur Linux. En Windows OK, en macOS non, même si le débugger ne signale rien et que le programme continue à s'exécuter comme si de rien n'était. Je prends uniDac (avec ou sans librairie intégrée), RAS sous les 2 OS avec FMX évidemment.

Pour le premier problème, sous Delphi, c'est visiblement un problème de gestion de l'encodage de la source. Testé en Qt, il n'y a pas de problème. Tu imagines, tu dis au Client :"Sous tel traitement de texte, vous n'encodez surtout pas en UTF-8 sinon le copier/coller est impossible avec le logiciel...":aie:

Le second se contourne évidemment (avec uniDac) et d'ailleurs ce serait une sécurité et un investissement doublement rentables.D'abord il contournerait mon bug m'épargnant des temps de "mise au point" infructueux importants et deuxième avantage, le coût modeste de cette ligne de composants est facilement amortie au moment du déploiement puisque je n'aurais pas besoin de libmysql et autres bibliothèques à joindre ou pire à déployer.

Pour tes problèmes avec FireDac, tu utilises une voie non officielle. Le jour où le gars te dit "Je suis occupé, je n'ai pas le temps...", ou le jour où le gars s'en va ou son poste est supprimé, tu mets combien de mois avant de "tisser un nouveau support" ? Cela je n'en veux pas. Je préfère payer pour diminuer mon "insécurité".

Avec un tel contrat, j'envoie tous mes codes y compris les clés d'accès à ma base à l'interlocuteur. Je lui laisse le temps évidemment de comprendre, et le temps de corriger le bug même si c'est long mais je "sais" que pris en compte, il sera corrigé.

Il semble que dans la sphère Delphi cela ne soit pas l'usage. C'est curieux car ce genre de contrat est gagnant/gagnant.

Bonne fin de WE. Cordialement AD.

Citation:

---

Envoyé par SergioMaster

car après plus de soixante-dix vues pas de réponses me laisse perplexe

---

Lorsque j'ai ouvert ce sujet (vers midi), il n'y avait qu'une ligne de texte qui à elle seule ne voulait pas dire grand chose. Il s'est pas mal étoffé à 15h05 ;)

Citation:

---

Envoyé par ApproxDev

1. Le copier-coller de texte avec des sources "étrangères" (issues de traitements de texte),

Pour le premier problème, sous Delphi, c'est visiblement un problème de gestion de l'encodage de la source.

---

Avec un Delphi non-Unicode alors.

Bonjour,

oui. J'ai perdu tout le texte que j'avais saisi et j'ai utilisé les MP pour demander à Sergio s'il y avait moyen de récupérer mon texte pourtant indiqué plusieurs fois comme auto-enregistré... mais pas "validé" (rendu public) encore. Bref à la seconde tentative, j'ai mis une ligne de texte certainement peu explicite pour les lecteurs que j'ai validée... et ensuite j'ai ressaisi ma prose sachant que cette fois en cas de fermeture intempestive je pourrais la récupérer.

En ce qui concerne le problème du copier/coller, j'en avais parlé ici :https://www.developpez.net/forums/d1...d-rtti-tvalue/

J'ai ré-abordé le sujet plus tard sur le forum, quelqu'un rencontrant le problème. Ce qui me gêne est que je ne rencontre pas le problème en Qt. On pourrait supposer que c'est une incapacité de Windows. Mais Qt démontre le contraire. Il faudrait que je retrouve mes codes et que quelqu'un(e) qui dispose d'une vraie XE10 les teste à nouveau. Ma vraie dernière version est une XE7, la starter étant... euh limitée. Donc je n'ai pas tenté avec cette dernière version.

Et justement pour en revenir à ma demande, j'aimerais bien investir dans une 10 mais je veux que les 2 conditions précisées ci-dessus soient remplies. Serge m'a envoyé 2 contacts en MP. Je m'en occupe dès demain.

Cordialement. AD.

ADD : j'ai retrouvé la discussion (et les sources y figurent) :https://www.developpez.net/forums/d1...-drop-notepad/

PS : j'ai demandé d'anonymer mon compte Enseignant quand j'ai quitté cette fonction d'où "l'Inivté". Et puis redevenir "simple membre" me convenait très bien car je commençais à "sévir" sur le forum Qt...

Ce qu'il faudrait déterminer est dans quel format ces données sont écrites dans le presse-papier puisqu'il ne semble pas y avoir de correspondance CF_TEXT/CF_UNICODETEXT.

Bonjour,

@Approxdev,
J'ai repris le code indiqué dans votre lien sous Delphi 10.2 Tokyo. Je reproduis le même comportement que celui que vous indiquez : un glisser/déposer depuis NotePad++ vers l'application fonctionne lorsque le fichier est en UTF-8 côté NotePad++ et renvoie "empty" lorsque le fichier est ANSI sous NotePad++.

Par contre, le comportement est identique lorsqu'on fait un glisser/déposer de NotePad++ vers Sublime Text.
Le glisser/déposer de NotePad++ vers VS Code ou Atom ne fonctionne pas (quelque soit l'encodage).
Le glisser/déposer de NotePad++ vers GBEPad (éditeur de fichiers texte que j'ai réalisé avec Delphi mais en VCL), fonctionne que l'on soit en UTF-8 ou ANSI.

Bonjour Gbegreg,

je propose le tutoiement réciproque. Donc la question est "qu'est-ce qu'on peut déduire de tes tests et des miens avec Qt... qui permettrait de résoudre le problème avec Delphi ?"

Toujours pour en revenir à la discussion initiale, au départ, je voulais simplement stocker certaines parties de mes scripts Web dans une base de données mariaDB pour les utiliser ultérieurement comme banque de données. Le modèle avait été maquetté en Windev (pour mettre en place l'ergonomie, la BDD,...) et comme je voulais au moins un accès Mac OS, j'ai "porté" en Delphi et suis tombé coup sur coup sur les 2 bugs : le DnD et l'accès à la base mariaDB en mac OS. :aie:+:aie:

Comme il s'agi(ssai)t d'un développement interne, peu pressé et que j'apprenais (j'apprends Qt) pas de problème. Mais, imagine cette demande par un Client. A priori, cela me semble plutôt simple. J'accepte le contrat, fixe des délais raisonnables et... mauvaises surprises. Grâce à Qt, j'ai contourné les problèmes sous les quolibets tu peux t'en douter, tout ce "petit" monde me regardant transpirer sur ce nouveau langage. Mais chacun son boulot. Ils ne sont pas là pour me former. Je mets un point d'honneur à me débrouiller sans eux ! En tout cas, cela n'a fait que renforcer ma frustration envers Delphi Firemonkey, le 3ème point d'achoppement étant la génération de pdf sous Windows [c'est là que c'est le plus flagrant] de textes HTML en gérant les entêtes, la pagination, les pieds de page. Je cherche toujours un composant permettant de générer ce type de texte, FastReport étant totalement à la ramasse si on le compare à Qt. Non, il faudrait un vrai générateur PDF. Ce dernier point est contournable : je peux compiler de manière static NCReport de Qt et bricoler une passerelle. C'est beaucoup de complication pour une autre insuffisance de Delphi.

Mais en Delphi, qui peut m'aider de manière sûre dans le cadre d'un développement professionnel (donc d'un contrat) pour surmonter les 2 premiers problèmes évoqués? Je me demandais quelle était votre démarche (celle des équipes de développement qui utilisent FMX) dans ce cas de figure ? On se replie sur un autre langage ? Moyennement admissible pour moi.

J'ai découvert par hasard à l'époque qu'il y avait en développement un plugin... Mais là ce sont des problèmes e droits d'utilisation. On remplace une insécurité par une autre. C'est pour cela que j'ai souscrit directement aux licences pro de Qt .

D'ailleurs je crois que pour soumettre ma demande aux 2 contacts transmis par Sergio, c'est l'exemple type que je vais utiliser. Pas grand chose de confidentiel, les 2 os cibles, problèmes inattendus mais tout à fait bloquant. J'apparente le premier à une insuffisance et le second à un bug.

Cordialement AD.

Bonjour,

j'espère que tu auras bon retour des liens envoyés.
pour revenir sur Maria DB, d'après le statut officiel la version 10.1 est maintenant acceptée
de là à te dire ce qui a été fait pour la partie MariaDB OSX : je n'en sais rien n'ayant pas de mac ;)
j'ai fait une petite recherche dans le forum de discussion EDN et suis "tomber" sur ce truc (Oct 3, 2014 donc XE6,XE7)

Citation:

---

Dear Embarcadero and Firedac developers

The current driver firedac for MSSQL or ODBC to run on mac requires UnixODBC and freetds for MSSQL. Have you notice that loading unixodbc and free tds requires a
lot of jumping through hoops, as OS X was set up to make such environment changes rare, and, by side effect or intent, rather difficult?

This means that for every mac osx installation you have to dedicate hours installing unixodbc and freetds for each mac flavor, use macports, homebrew etc. to make a distribution that the end user can install by himself is almost imposible.

If embarcadero delphi wants to really offer a portable solution for mac it must use the IODBC that comes with Apple shipped as part of OS X 10.2 through 10.8, or even better, the iODBC Frameworks, which libraries are binary duplicate to the dylibs though located differently in the filesystem.

Otherwise the OSX solution offered does not work for commercial installation , only for testing and for people that does not care to spend hours and hours tweaking their OSX system.

---

Peut-être était-ce là le hic :aie:
Il faudrait "fouiller" les notes de versions pour savoir ce qu'il en est aujourd'hui.

Pour ce qui est du copier coller (via le clipboard) il faudrait tester avec la démo http://docwiki.embarcadero.com/CodeE...pyPaste_Sample je tenterais (peut-être) en fin de journée

[Edit] Finalement, plutôt que de détruire des monstres pour me passer les nerfs, je viens de faire un test rapide. Bon, il a fallu modifier un petit peu le programme démo pour avoir un collé d'un texte entier dans un mémo (et donc ajout d'un mémo et d'une ligne sous la ligne 72 j'ai rajouté Memo1.lines.Text:=Value.ToString; )
Ensuite, si j'ai bien compris la manip, j'ai ouvert notepad++ , ouvert un nouveau fichier encodé en ANSI, mis quelques trucs dedans et fait un copier. Etait-ce ce qui'l fallait faire ?
toujours est-il que : nickel pour le Paste sous windows bien sûr du coup ai-je eu un doute ! étais-bien FMX : Oui
te restes à tester cette même démo (modifiée) avec un mac ;) ou m'expliquer que je me suis planté dans la manip (je n'avais pas suivi à l'époque)
puis à organiser cela via le dragdrop d'un fichier ANSI ou autre encodage "pour voir"

N.B. j'ai aussi (tu parlais de sources étrangères) fait un copié d'un texte sous OpenOffice : succès pour le collé

J'ai fait un petite essai avec cette histoire de drag&drop entre Notepad++ et FMX (et oui pour une fois).

Désolé de dire que le problème vient plutôt de Notepad++ ;)

J'ai dans un premier temps fait une copie de FMX.Platform.Win.pas et ajouté le support de CF_TEXT pour voir si ce format était récupérable :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

function TWinDropTarget.GetDataObject: TDragObject; var ... begin ...   FormatEtc.cfFormat := CF_TEXT; if FDataObj.GetData(FormatEtc, StgMedium) = S_OK then begin try { Lock the global memory handle to get a pointer to the data } str := PAnsiChar(GlobalLock(StgMedium.HGLOBAL)); Result.Data := str; finally { Finished with the pointer } GlobalUnlock(StgMedium.HGLOBAL); { Free the memory } ReleaseStgMedium(StgMedium); end; Exit; end; end;

---

Il l'est et avec ce bout de code, le drop fonctionne :P

Mais ça reste un emplâtre...

Delphi Unicode ne traite que la donnée au format CF_UNICODETEXT. Si la donnée est de type ANSI (CF_TEXT), l'OS (et non Delphi) convertit implicitement cette donnée pour la rendre compatible Unicode.
Seulement pour que la donnée puisse être convertie, il faut que la source spécifie son code-page, sinon comment savoir comment mapper ces 255 caractères ? Ceci se fait en spécifiant le LCID (l'identificateur de langue) à l'aide de CF_LOCALE. S'il est manquant, Windows va automatiquement le fixer à la langue d'entrée courante.

Le test suivant qui s'impose est donc de forcer le codage dans Notepad++ (menu Encodage -> Codage de caractères) et miracle, le drop fonctionne en Unicode (sans ma modif.).

Dès lors, on ne peut que supposer qu'à la place de laisser l'OS se débrouiller pour fixer le code-page par défaut, Notepad++ le fixe à zéro (ou un LCID inconnu) s'il n'a pas explicitement été défini rendant la conversion impossible.

Quant à Qt, on ne peut également que supposer qu'il traite les deux types de données mais bien évidemment en prenant le "risque" que le drop soit dans les choux (mauvais codage).

A noter que le copier/coller fonctionne correctement, ce qui étaye un peu plus l'idée d'une erreur de remplissage des données au drag de Notepad++.

Bonsoir,

@Andnotor : Effectivement je suis parti du fait que comme Qt gérait correctement le DnD avec NotePad++ comme source, le problème venait de Delphi. Je ré-étudierai cela si j'arrive à trouver une solution aux problèmes évoqués en début de discussion.

@SergioMaster : en ce qui concerne FireDac, je ne connaissais pas ces articles. Et comme je l'écrivais au-dessus :je ré-étudierai cela si j'arrive à trouver une solution aux problèmes évoqués en début de discussion mais en ouvrant 2 nouvelles discussions.

En tout cas, merci à tous pour votre aide.
Cordialement. AD.

Bonsoir,

@Approxdev, pas de problème pour le tutoiement :)
J'arrive un peu tard. Merci à Andnotor pour son investigation : je n'avais pas eu le temps de pousser plus loin mes investigations ce matin et ce soir, je constate qu'une réponse bien plus complète que ce que j'aurai pu faire a été donnée.

Pour répondre à certaines de tes questions, à mon niveau, je n'ai pas encore utilisé FMX au niveau professionnel mais ça va venir (il faut trouver les projets qui vont financer la migration VCL vers Firemonkey...). Je me forme de manière autodidacte à FMX depuis quelques temps mais plus pour des applications de loisirs (astronomie, jeux, 3D, mobile...).

Pour ce qui est du support, et comme indiqué dans un autre sujet, Barnsten a repris récemment le support des outils Embarcadero pour la France : l'avenir nous dira s'ils vont améliorer ce point.

Bonjour,

Citation:

---

Envoyé par ApproxDev

@SergioMaster : en ce qui concerne FireDac, je ne connaissais pas ces articles. Et comme je l'écrivais au-dessus :je ré-étudierai cela si j'arrive à trouver une solution aux problèmes évoqués en début de discussion mais en ouvrant 2 nouvelles discussions.

---

en fait si j'en crois ce blog Firedac ne supporte officiellement MariaDB que depuis 10.2 Tokyo. Cependant, je n'ai trouvé aucune information précise concernant les déploiements OSX ou Linux