Discussion :

[ApproxDev]

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 . 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 ) et l'obligation d'utiliser un Mac (j'adore le Mac -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.

[SergioMaster]

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)

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)

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

je me croyais unique

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

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 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 ?)

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

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

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
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
@+

[ApproxDev]

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

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.

[Andnotor]

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

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.

[ApproxDev]

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

[Andnotor]

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.

[gbegreg]

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.