Discussion :

[Invité]

Bonjour,

Introduction

Je commence à m'habituer à FMX avec encore beaucoup d'hésitations et donc à "percevoir" le produit. J'ai cherché pendant 10 minutes quelle unité il fallait insérer dans le uses pour utiliser les couleurs pré-déclarées telles que claBlack... (System.UIConsts)... Ce qui prouve, je suppose, que je ne sais pas utiliser correctement l'aide... Pourtant un Lazarusien a l'habitude de chercher .

Je commence à réaliser (basculer) l'équivalent de mes composants Lazarus. J'en suis à mes boutons graphiques. Je déplore évidemment l'absence de TImageList mais on fera sans... car j'ai vu une solution alternative. L'approche de "substitution" m'a semblé pour le moins complexe... J'allais écrire "invraisemblable". On va rester dans la modération. Manque de pratique sans doute.

Mais d'une manière générale, j'en suis au stade -que j'espère dépasser- de trouver l'environnement trop "contraignant", trop sophistiqué.... J'aime les IDE simples, dépouillés à la Delphi 7. Néanmoins, j'ai noté la question pour évaluation plus tard : Que m'apporte une telle sophistication en terme de productivité ? Par exemple les styles ? Quelle est leur ré-employabilité réelle ? Quel apport dans une Form comparé à la réalisation puis à l'utilisation d'un composant personnalisé ? Quelle est la limite de ce type de développement ? Par exemple, on trouve de nouveaux boutons stylisés (Ecriture penchée, fond de couleurs différentes...) mais je n'ai rien vu d'aussi sophistiqué que ce que l'on trouve en VCL (sans style). Là encore, jeunesse du produit ou complexité exponentielle avec les exigences ? Exemple de ce que je ne peux pas transposer actuellement de Lazarus vers FireMonkey : les boutons 5 états de Windev (mode "9 images" inclus)...

Enfin mes composants transposés "compilent" en XE4 et sont installables.

Mon problème : les ancres

Comment gérer l'alignement de plusieurs objets dans un TLayout utilisé comme ancêtre. En Lazarus, il m'est très facile de placer un objet par rapport à un autre, l'autre n'étant pas nécessairement le parent. Par exemple un TLabel centré horizontalement sur un TImage contenus (les deux) dans un TPanel (cf component.png). L'exemple est simple, et on pourrait certainement utiliser des références uniquement au Parent pour résoudre ce problème. Il est volontairement simple pour comprendre mon approche habituelle. Dès que le problème se complique un peu, le positionnement d'objets de "même niveau" les uns par rapport aux autres procure une souplesse et une simplicité inégalées. Comment fait on-cela en Delphi FMX ?

L'aide existe, est utilisable, mais ne m'a pas permis de résoudre mon problème.

FMX.Controls.TControl.Anchors
Spécifie comment le contrôle est ancré à son parent

et http://docwiki.embarcadero.com/Libraries/XE4/fr/FMX.Types.TAlignLayout... Cela semble plus complet que Lazarus mais malheureusement c'est moins facilement fonctionnel.

alHorzCenter : Le contrôle est centré horizontalement dans la zone client du parent, et se redimensionne afin de remplir la hauteur de son parent. La largeur du contrôle n'est pas affectée. Si un autre contrôle, épinglé sur le bord, occupe déjà la partie de la zone parent, le contrôle se redimensionne afin de remplir la hauteur restante de son parent. Les ancrages sont définis sur [akTop,akBottom].

et

System.UITypes.TAnchors Description
Embarcadero Technologies ne possède pas d'informations supplémentaires pour le moment. Veuillez nous aider à documenter cette rubrique en utilisant la page Discussion !

Je cherche pour commencer à réaliser un centrage horizontal (ou vertical) simple (ie sans redimensionnement) d'un objet dans son parent. J'ai cherché une solution dans http://docwiki.embarcadero.com/RADStudio/XE4/fr/Strat%C3%A9gies_des_dispositions_FireMonkey. Et là, pas mieux... Cela parle peut-être à un Delphien mais pas à moi. En réalité, cette complexité est dûe au fait que seul le parent est utilisé comme référence. Si les objets d'un même parent pouvait être interfacés entre eux, la simplicité et la puissance seraient au rendez-vous. Là, je veux bien supposer que la dernière y est mais quid de la simplicité ?

Autre approche très délicate semble-t-il : les TStringGrids

Cela fera l'objet d'une autre discussion. Pour l'instant, je cherche de la documentation. Mais visiblement le codage est très différent de la VCL/LCL et certaines des méthodes que je veux implanter sont non documentées et les moteurs de recherches relativement muets.

Suite des commentaires

Sinon, que de plantages... Tout de suite en quittant Delphi (cf quit.png)... C'est la plupart du temps des problèmes d'affichage. Des Forms dans l'IDE qui deviennent noires (noir sur fond noir). Un petit resize à la souris rend le noir sur fond blanc ce qui me permet de revoir mes objets... Je ne parle pas du projet compilé mais de l'utilisation de l'IDE. C'est peut-être lié à mon 64 bits, à l'utilisation d'un Dual-Screen ? Par contre d'autres, comme celui-ci apparu juste après l'ouverture de Delphi lors de la déclaration d'un nouveau composant (cf ou.png), ne sont pas des problèmes d'affichage. Delphi s'est gelé.

Pas de nouvelles de mes déclarations de bugs (reçues pas reçues, validées, en cours de traitement ?)... Rien à voir avec le bugtracker de Lazarus et le confort des patchs quotidiens...

Mes impressions sont à la baisse... mais pas définitives. J'ai un avis très réservé sur les styles, le livebinding... C'est simple au départ, puis rapidement compliqué. L'approche est très "propriétaire" (ie propre à Embarcadero)... Et à mon avis, d'autres approches sont aussi productives et efficaces... et moins contraignantes. Bref, je ne vois pas réellement l'apport de ces méthodes. Et là, j'ai une impression bizarre de déjà vu... Ce type d'aide au développement, on met le doigt dedans... et on subit au fil des versions -que l'on ne peut plus quitter... et pour cause- le meilleur... et le pire. En résumé, au niveau simplicité, j'ai vu mieux et au niveau fonctionnalité, j'ai vu mieux aussi... surtout si on lie les 2 !

Il me reste 30 jours pour affiner mon approche et m'adapter au mieux au produit. Merci pour une éventuelle réponse sur les ancrages. Cela m'arrangerait bien... Sinon on va faire des calculs pour les positionnements.

Ressources

• INNOVA Solutions : FireMonkey is Different [http://www.innovasolutions.com.au/delphistuf/ADUGVCLtoFMXConv.htm]
  Contient notamment VclToFmxConvert.zip - Zip of Code and Executable The file includes the latest executeable and source code. Il y a les sources mais dans mon cas le paquet ne s'installe pas. Il me manque "fmx161.bpl". (cf package.png). Est-ce un moyen d'empêcher l'installation de paquets tiers dans les versions Trial ou un paquet créé en XE2 qui nécessite une bibliothèque (ou un paquet) abandonnée en XE4? Je ne sais pas.

Bon WE. Cordialement. Gilles

[Invité]

Bonjour,

Suite et fin

Finalement, je renonce. Hormis les problèmes déja signalés ci-dessus, je n'arrive pas à mettre en oeuvre la cross-compilation MacOs X. Mais je ne jette pas la pierre à Delphi dans la mesure où je constate de gros problèmes avec Lazarus dans cet OS. Cela me conforte simplement dans mon opposition à la cross-compilation (en Desktop, pour le reste tablette/smartphone, tant qu'on ne fera pas tourner un IDE dessus, on ne pourra pas faire autrement). Je reste persuadé que pour réaliser des applications client riche (/lourd ?... bref des applications "traditionnelles" pour PC), un IDE doit "tourner" sur ses plate-formes cibles... comme Lazarus, C++/QT... Je sais que c'est contesté. Et je n'affirme pas que cela soit infaisable. Cependant, j'ai longuement essayé : aucun de mes tests de cross-compilation "DeskTop" d'applications de bonne envergure n'a été satisfaisant... Par contre, ils m'ont imposé une perte de temps invraisemblable.

Conclusion

Objectivement (ie les faits)

• IDE : Des plantages trop nombreux sur mon appareil. Je sais bien que c'est une nouvelle release, mais comment font les programmeurs qui sont obligés de migrer avec XE4 pour bénéficier notamment des nouvelles possibilités au niveau des tablettes et autres smartphones ? C'est vraiment agaçant. Mon poste est stable. Lazarus 1.0.8 (64 bits), Windev 18 (32 bits), le dernier C++/QT... y tournent sans problème particulier.
• FireMonkey : Au niveau des besoins pour développer des applications client riche, c'est largement incomplet... et à 2 niveaux:
  
  1. Cela manque de composants
  2. Les méthodes implantées dans les composants sont souvent insuffisantes.

  Le cas le plus représentatif est la TStringGrid. Les ressources dont je dispose et les méthodes de développement imposées ne me permettent pas (dans la majorité des cas) ou me permettent de manière très (vraiment très) compliquée de m'approcher de ce que je réalise en Lazarus.

Mon ressenti

C'est très simple. Bien que cela ne soit pas vraiment ma tasse de thé je préfère(rais) autant développer en C++/QT qu'en FMX. Je reconnais mal (c'est presqu'un euphémisme) "mon" Delphi et surtout pour le prix d'une telle "complexification" à outrance avec des méthodes "propriétaires", j'en veux (voudrais) pour mon argent... et tout de suite. Un regret est de ne pas avoir pu tester l'accès à mes bases de données (pgSQL). Je crois que j'ai désormais suffisamment "expérimenté" pour pouvoir décider. Je reste un Lazarusien convaincu parce que je l'estime supérieur en Desktop à FMX, parce que le plus Delphiste des 2 dans l'esprit que je m'en fais, c'est Lazarus... et parce que finalement ce dernier n'a pas plus de défauts (voire beaucoup moins) que XE4/FMX. Je me sers tous les jours de Lazarus, il ne plante jamais ! J'ai déjà émis cette réflexion et je la maintiens : Si on compare Delphi (même 7) à Lazarus en Windows (ie VCL), ce qui fait pencher la balance vers Delphi, c'est sa bibliothèque tierce de composants. Maintenant en FMX, elle n'existe pas. A ce niveau, on se retrouve dans la situation de Lazarus. Alors la perception est très différente.

Durant mon test de plusieurs jours pendant mes vacances, ma sympathie envers XE4 s'est peu à peu affadie à l'épreuve des problèmes rencontrés, y compris à l'analyse des solutions trouvées... quand je les ai trouvées. La conclusion s'impose à moi en ce qui concerne XE4/FMX : bien que ce langage soit toujours du Pascal, ses approches (unités, méthodes, propriétés) me sont devenues souvent étrangères. Fréquemment, les choix retenus (les ancrages par exemple) me semblent curieux et désagréables, comparés aux solutions d'autres IDE/langages (même si pour le cas des ancrages je crois que Delphi a toujours proposé cette solution... et justement avec FMX, on aurait peut-être pu vérifier le ratio simplicité/performance et s'inspirer ailleurs. Je ne fais pas une fixation sur les ancrages... mais c'était le point de départ de ma question). Je désinstalle XE4... mais compte tenu de l'évolution du produit, de mes besoins, de mes connaissances et de mes capacités, je crains de ne plus être capable de m'y "réadapter" un jour. Mon coeur et ma raison s'accordent sur mon premier choix : plus que jamais je soutiens Lazarus. Donc, place à la nouvelle génération que je souhaite nombreuse pour Delphi.

Cordialement. Gilles

[Andnotor]

Une chose est sûr, tu aimes écrire !
Mais le problème est que dès qu'une intervention dépasse dix lignes, ça me rebute et je ne la lis pas

[Invité]

Bonjour,

C'est un moyen de penser calmement et de mettre au clair mes idées, de les organiser, les confronter, les hiérarchiser, les développer... Ecrire me facilite cette activité. Certains préférent le yoga... Je crois que dans ma génération, les "matheux" -mais pas qu'eux- aiment écrire... Cela rend toujours suspicieux mes élèves... tous très adeptes du "texto". C'est vrai que la technologie "commerciale" dont il découle (le SMS) a imposé des messages courts. Cela tombe bien, prolixes comme sont souvent leurs propos. Sans désobligeance aucune, je crois que je n'envahirai plus le forum Delphi pendant un certain temps.

Mais en commentaire à votre propos, oserais-je affirmer qu'il ne me semble pas facile d'apprendre, de se former, voire de s'informer dès qu'on -comment disent-ils déjà ?-... "déconnecte" au bout de 10 lignes. Et même, difficile de penser en seulement 10 lignes. Un peu réducteur cette extrême simplification non ? Les résumés de résumés deviendraient suffisants ? Je perçois notre décalage...

Remarquez, 10 lignes d'une longueur infinie... c'est de trop : une seule suffit !

Plus sérieusement, dans le cas précis, j'émets des critiques. La moindre des choses, c'est qu'elles puissent être contestées... dans les faits. Et pour ce faire, il faut qu'elles soient étayées.

Bon "pont" si vous le faites. Cordialement. Gilles

[skywaukers]

Bonsoir,

Bonjour,

C'est un moyen de penser calmement et de mettre au clair mes idées, de les organiser, les confronter, les hiérarchiser, les développer... Ecrire me facilite cette activité. Certains préférent le yoga... Je crois que dans ma génération, les "matheux" -mais pas qu'eux- aiment écrire... Cela rend toujours suspicieux mes élèves... tous très adeptes du "texto". C'est vrai que la technologie "commerciale" dont il découle (le SMS) a imposé des messages courts. Cela tombe bien, prolixes comme sont souvent leurs propos. Sans désobligeance aucune, je crois que je n'envahirai plus le forum Delphi pendant un certain temps.

Mais en commentaire à votre propos, oserais-je affirmer qu'il ne me semble pas facile d'apprendre, de se former, voire de s'informer dès qu'on -comment disent-ils déjà ?-... "déconnecte" au bout de 10 lignes. Et même, difficile de penser en seulement 10 lignes. Un peu réducteur cette extrême simplification non ? Les résumés de résumés deviendraient suffisants ? Je perçois notre décalage...

Remarquez, 10 lignes d'une longueur infinie... c'est de trop : une seule suffit !

Plus sérieusement, dans le cas précis, j'émets des critiques. La moindre des choses, c'est qu'elles puissent être contestées... dans les faits. Et pour ce faire, il faut qu'elles soient étayées.

Bon "pont" si vous le faites. Cordialement. Gilles

On ne peut pas vous reprocher d'être bavard, mais là tout de même vous jetez des pierres un peu "gratuitement" sur Delphi. On passe sur l'approche différente VCL/FMX, elle peut vous perturber, ne pas vous convenir, souffrir également de sa jeunesse. Mais vous renoncez à priori suite à une incapacité de faire tourner votre programme sur Mac. Par contre je ne vois nul part dans votre message quelle est cette difficulté ?
Parce que ce doit être un problème surmontable à mon avis. Personnellement je fait de la cross-compilation depuis XE2 sur Mac (et aujourd'hui j'ai fait ma première toute petite application IOS), je n'ai jamais rencontré de difficultés. Ou plutôt si, avec XE4 j'ai était obligé de désactivé le pare-feu de mon MacBook, avec XE2 et XE3 ce n'était pas nécessaire, bon. J'ai aussi un petit réseau donc le déploiement sur mac et/ou simulateur ios est plutôt très long, et heureusement qu'on peut mettre l'application au point sur Windows même pour ios, ce qui est quand même très pratique. Bon à condition de ne pas utiliser les api IOS bien sûr et on ne bénéficie pas non plus du rendu final, mais au moins on peut déboguer fonctionnellement l'application, il ne reste plus que les "détails" visuel à retravailler en étant obligé de déployer à chaque modif. Sans vouloir troller j'ai pour le moment beaucoup moins de problème sur macos avec Delphi qu'avec Lazarus.

Bonne continuation.

@++
Dany

[Invité]

Bonjour,

je ne jette pas de pierres gratuitement sur Delphi. Je détaille. Je questionne. J'argumente quand je n'arrive pas à mettre en oeuvre.

Vous mettez en avant iOS : je n'en parle pas. Je ne teste pas. Je ne connais pas. "Cela" ne m'intéresse pas. Je vous parle de FireMonkey utilisé pour développer des applications lourdes donc pour Win, linux (32 et 64 bits) et macOS 32 bits. Malgré toutes les publicités que je reçois, je ne peux pas développer... pas plus d'ailleurs que des composants à la hauteur de VCL ou LCL. Mais il est vrai que c'est une version Trial. Seulement je ne vais peut-être pas investir dans une faisabilité hypothétique avec la version Entreprise ou professionnelle.

Je n'ai pas évoqué les problèmes de cross-compilation puisque le problème n'avait plus lieu de l'être : j'ai renoncé.

Maintenant si je peux me permettre d'être direct : je vais me désinscrire des listes marketing d'Embarcadero. Je ne veux plus que l'on me prenne pour un imbécile..., un "pigeon"... Visiblement, c'est un produit que mes capacités et mon expérience ne me permettent pas d'appréhender voire même d'utiliser. J'ai lu récemment que leurs représentants commerciaux étaient nommés "Evangelist". C'est un terme mal adapté et inquiétant que l'on réserve à des associations très particulières. Il ne faudrait pas glisser de la niche... Pour reprendre leur vocabulaire, j'ai destiné de rester "profane"... et de garder ma liberté de penser... et d'énoncer de simples faits.

Maintenant si vous avez un petit peu de temps, et si vous connaissez Windev, essayer de faire un composant bouton graphique de type neuf images en FireMonkey qui tourne(ra) sous Win et Mac... C'est le sujet de ma question. Une fois ceci fait, nous pourrons comparer le code, les méthodes, les approches si vous le voulez avec son équivalent que j'ai réalisé en Lazarus sous Win, Mac et Linux. C'est aussi simple que cela. J'ai essayé. Aussi bien en Lazarus qu'en Delphi. Lorsque Lazarus a posé problèmes, je les ai soulevés.

Si vous avez plus de temps, je vous propose de réaliser des TStringGrids un peu élaborées : multiselect non contigu, tris multiples (xxx ASC, yyy DESC), gestion du multiligne.... Alors là c'est le délire... pour moi. Si vous fouillez un peu dans le forum Lazarus, vous verrez que c'est faisable et que cela fonctionne et que le code est relativement simple (après coup ).

Jamais sur le Forum Lazarus, je n'ai recensé d'interventions de prédicateurs [on va utiliser le vocabulaire (con)sacré ] mais simplement des programmeurs qui m'ont aidé ou ont corrigé le produit. Il y a des choses à ne pas dire. Vos propos sont censé faire pression sur moi ? Quel est le problème ?
Les bugs ? Vous avez es copies d"écran. Mes propos, j'ai différencié la partie objective que j'ai détaillée de mes impressions ? Où est la faute votre Honneur?

Je vous laisse entre Vous. Delphi ne me concerne définitivement plus pour les raisons que j'ai évoquées. Je ne dis pas qu'il n'est pas bon (lisez les mots ont un sens pour peu qu'on ne les interprète avec un prisme... sectaire ? Delphi n'est pas adapté à mes besoins malgré ce que sous-entend la manière dont il est présenté... qui elle semble parfaitement compatible à mes besoins.

Comme c'est la 3ème tentative, (excusez, j'ai "sauté" une version), voila, j'en reste là. C'est un avis parmi d'autres qui j'en suis sûrs en sont satisfaits. Mais même minoritaire, dans notre pays, on a le droit de s'exprimer en respectant les règles. C'est ce que j'ai fait.

Je vous souhaite une bonne continuation.
Cordialement Gilles

[skywaukers]

Bonjour,

Je vous cite :

Finalement, je renonce. Hormis les problèmes déja signalés ci-dessus, je n'arrive pas à mettre en oeuvre la cross-compilation MacOs X.

Pour les problèmes déjà signalé, je veux bien admettre que MFX n'est pas à certains niveaux au même stade d'évolution que VCL (et je dis bien à certains niveau, parce que essayez de faire des animations et de la 3d avec la VCL, je pense que vous allez "ramer" un peu plus qu'avec FMX). Encore que, comme j'ai pu le dire lors d'autres sujets autour de FMX, il vaut mieux arriver avec un esprit non emprunt de la logique VCL, parce que la philosophie est différente, et si on retrouve bien sûr le côté pose-boutons de la VCL, dès qu'on gratte on s'aperçois que ce n'est pas la VCL. Il y a du moins bien (le côté nombre de composants tiers, su à la jeunesse de la plate-forme, qui ne pourra grandir que si on s'obstine un peu à l'utiliser, sinon elle connaitra le même sort que Kilyx, et Delphi aussi du coup vue que win32, ben c'est un peu mort). Il y a du mieux aussi : vous critiquez les live-binding, je trouve au contraire que c'est un gros plus par rapport à la VCL. Ne pas avoir une petite palette de composants liés aux données, mais pouvoir lier n'importe quel composant à n'importe quel autre (parce que là on n'est même pas limité aux datasource) je trouve que c'est une avancée certaine !! Et en plus depuis XE3 on peut le faire visuellement (avant c'était quand même assez galère à faire, il faut le reconnaitre).

Bon par contre dire que vous n'arrivez pas à mettre en œuvre la cross-compilation, je veux bien l'entendre, mais on aimerait savoir pourquoi ? Surtout dans la mesure où de mon expérience personnelle je n'ai jamais rencontré de problème particulier en suivant la procédure (hormis le nouveau pb du pare-feu). Et si je parle d'IOS ce n'est pas pour le mettre en avant, mais pour appuyer au contraire le fait que la cross-compilation est bien possible à mettre en œuvre puisque là on déploie sur le mac mais cela s'exécute dans le simulateur IOS). On peut aussi déployer sur le device, mais là j'ai pas testé (et payer 99$ à Apple pour tester je doute que je le fasse, on verra si je développe quelque chose de plus intéressant ou si cela intéresse ma boite, ce qui est probable puisqu'il semble qu'IOS ait été choisi par la maison mère ).
Donc oui pour le coup, la "goutte" qui vous fait renoncer n'est pas très argumentée.

@++
Dany

[Invité]

Ecoutez Dany,

je propose d'en rester là.

La cross-compilation fonctionne sous iOS. Heureusement sinon je ne sais pas comment vous feriez pour développer à moins de faire tourner Delphi (l'IDE) directement sous iOS.

Pour le problème vers MacOS, je n'ai pas de copies d'écran donc difficile d'appuyer mes dires surtout sur votre forum. J'en suis resté au stade des hypothèses. J'ai écrit : "je n'ai pas réussi". Encore une fois, on va dire que je ne suis pas adapté au produit. De plus, je le redis : je n'utilise pas la cross-compilation de manière usuelle. J'ai testé longuement en Lazarus... pour me faire une idée... avant de rejeter cette méthode. Et comme la cross-compilation n'est pas nécessaire en Lazarus, pas nécessaire en QT/C++ pour le développement de mes applications Desktop... et que, comme vous le savez, les tablettes et autres Smartphones ne font pas partie de mon univers de développement, je ne prétends pas avoir une expertise sur la question.

Dans la mesure où vous ne rencontrez pas de problème, les utilisateurs du forum savent à qui s'adresser.

Enfin, il n' a pas de "goutte". Relisez ma participation au forum Delphi... Une succession de mises en oeuvre, de compte-rendus, de questionnements, de discussions. J'ai même essayé une approche SmartPhone... pour me rendre compte . C'est là que j'ai redécouvert Delphi et comme j'étais nulb avec, j'ai ressorti mon C++/QT pour me rendre compte... Et lui aussi avait évolué..ouah ! Voilà pourquoi j'évoquais mon rapport avec cette plate-forme
comparée à Delphi. Je me suis procuré aussi un Windev 18 pour voir ce qu'on faisait actuellement en terme d'IHM et de composants graphiques... Re-ouah.
Tout n'est pas rose :http://www.developpez.net/forums/d77...s-avec-windev/ Là encore, c'est un peu long.

Je pense prendre le recul nécessaire : Delphi XE4 plante, je précise que c'est peut-être lié à mon 64 bits [mais aussi je précise qu'avec d'autres IDE installés, il ne plante pas]. Pour la programmation, je précise le problème, comment j'aimerais procéder et sollicite de l'aide après parcours d'une tonne de docs éparpillées... Et là encore, j'accepte d'entendre que le programmeur n'est pas au niveau...

Quelque soit l'approche, j'en tire la même conclusion et pour ne plus céder aux sirènes [je suis crédule], je fais rayer mon nom des listes marketing d'Embarcadero et de ses représentants en France. Lire votre forum me suffira.

Bonne journée.
Cordialement. Gilles