Discussion :

[yvslms]

Bonjour - Quelques soucis sur la XE3 restés pour l'instant sans réponse de la part d'embarcadero.
- pas de compatibilité ascendante directe : la recompilation d'un projet XE2 tel quel (même une fiche vide) entraîne une série d'erreurs d'édition de liens.
- la compilation 64 bits ne fonctionne que sur une machine distante (même sous win64). (Idem sans doute sous Delphi).
- la réécriture de FMX2 est certes plus performante mais a entraîné la perte de la gestion des textures par répétition de motifs sur un TModel3D. Il n'est donc plus possible d'afficher correctement la plus-part des modèles dae venant de banque d'images.
D'autres utilisateurs de C++ Builder passé en XE3 peuvent-ils me le confirmer ?

Yves

[ShaiLeTroll]

pas de compatibilité ascendante directe : la recompilation d'un projet XE2 tel quel (même une fiche vide) entraîne une série d'erreurs d'édition de liens.

Mon responsable à passer 3 Packages, 40 Exe et 80 DLL sous XE3 sans ce problème, il en a même profiter pour ajouter des Variables d'Env pour assouplir la disposition des fichiers

- la compilation 64 bits ne fonctionne que sur une machine distante (même sous win64). (Idem sans doute sous Delphi).

tu évoques l'Update 1 car le XE3 d'origine n'est pas 64Bits, qu'est-ce que ce la "compilation sur une machine distante", je connaissais le débogage distant mais pas la "compilation distante" sauf avec un Bureau à distance évidemment

Pour FMX\FMX2, de telles difficultés étaient prévisibles, il faut la considérer comme une nouvelle lib, avec ses lacunes de jeunesse malgré ses 5 ans d’existence sous VGScene\DXScene, Embarcadero ayant repris en main le développement, ils améliorent la bibliothèque, modifie à leur façon certaine parties qu'ils n'avaient pas eu le temps de changer, presser par une date de livraison et que certains enrichissements complexifient l'architecture objet de FMX et c'est peut être lié aussi à des contraintes multi-plateforme qui pousse à des sacrifices !

En tant que pro, j'ai l'habitude d'être très critique avec la nouveauté, mon patron n'a pas d'argent à perdre, laissons les autres qui ont le temps (libre ou le budget) pour essuyer les plâtres

Je pense à des professionnels qui ont investis du temps de développement dans un projet FMX 3D démarré en XE2, et que lors de la mise à jour sur XE3, cela ne fonctionne plus, c'est rageant car l'on a payé pour que cela ne fonctionne plus et on repayera pour corriger le code !

Pour un amateur, c'est frustrant, mais cela n'occasionne pas de perte financière autre que la licence

les projets pro ont une forte inertie, un changement de cap n'est pas toujours évident à cause des taches en cours de spec, réal, test... et tout simplement exploité par des milliers d'utilisateurs qui ne peuvent pas attendre 3 ans une nouvelle version et donc oblige une alternance naturelle entre VCL et FMX

J'aimerais bien savoir quels sont les profils d'utilisateur de FMX ?
Amateur\Pro en 90/10, 50/50 ou carrément l'inverse et que donc certains pros ont bcp plus d'audace que mes boss !

Pour le TModel3D, alimente le QC avec un projet démo en XE2 et un autre en XE3 pour leur montrer le problème, si personne ne leur signale, ils ne pourront pas le corriger, ou te dire, que c'est comme ça maintenant et débrouille toi (en gros refaire ton modèle DAE pour qu'il soit conforme à ce que supporte le TModel3D)

La 3D est tout de même une problématique loin des priorités pour un développeur Delphi\C++Builder dont le logiciel fait de la compta, facturation et autre métier un peu chiant !

Si tu as une licence et compte DN, pense que tu as droit à "3 cas de suivi", où ils peuvent regarder ton problème avec un plus d'attention que la QC

[yvslms]

Mon responsable à passer 3 Packages, 40 Exe et 80 DLL sous XE3 sans ce problème, il en a même profiter pour ajouter des Variables d'Env pour assouplir la disposition des fichiers

Le problème est uniquement sous FMX : probablement du à la réécriture partielle en FMX2. Pas de pb en VCL.

tu évoques l'Update 1 car le XE3 d'origine n'est pas 64Bits, qu'est-ce que ce la "compilation sur une machine distante", je connaissais le débogage distant mais pas la "compilation distante" sauf avec un Bureau à distance évidemment

Il s'agit bien de l'update1 et du "débogage distant" évidemment. Mais avez-vous testé le compilo 64 bits et dans quelles conditions ?

J'aimerais bien savoir quels sont les profils d'utilisateur de FMX ?
Amateur\Pro en 90/10, 50/50 ou carrément l'inverse et que donc certains pros ont bcp plus d'audace que mes boss !

Beaucoup d'utilisateurs sont pro tout en étant développeur à temps partiel. Delphi et C++ Builder offrent une facilité d'utilisation et une productivité pour des personnes dont le développement intervient en double compétence notamment dans les secteurs scientifiques.

Pour le TModel3D, alimente le QC avec un projet démo en XE2 et un autre en XE3 pour leur montrer le problème, si personne ne leur signale, ils ne pourront pas le corriger, ou te dire, que c'est comme ça maintenant et débrouille toi (en gros refaire ton modèle DAE pour qu'il soit conforme à ce que supporte le TModel3D)

TModel3D n'est malheureusement pas compatible avec grand chose pour l'instant. C'est juste une collection de TMesh. Il faut travailler à ce niveau.

La 3D est tout de même une problématique loin des priorités pour un développeur Delphi\C++Builder dont le logiciel fait de la compta, facturation et autre métier un peu chiant !

Beaucoup de choses sont déjà possibles avec cet outil dans les secteurs scientifiques et techniques. Pour les comptables c'est effectivement de la décoration (à part le multi-plateforme).

Si tu as une licence et compte DN, pense que tu as droit à "3 cas de suivi", où ils peuvent regarder ton problème avec un plus d'attention que la QC

Effectivement, je n'ai été en contact qu'avec Arrow pour l'instant.

Merci pour ta réponse.

Cordialement.

[ShaiLeTroll]

Le problème est uniquement sous FMX : probablement du à la réécriture partielle en FMX2. Pas de pb en VCL..

Ah, Ok tu fais tout en FMX, nous on a que de la VCL, il est déjà un peu capricieux

"débogage distant" évidemment.

Je voulais être certains que l'on parle de la même chose, tu veux dire que le débogage local ne fonctionne pas en FMX64 mais que le "débogage distant" fonctionne, c'est hallucinant !

Idem sans doute sous Delphi

En général, Delphi est BEAUCOUP plus stable que C++Builder !

Mais avez-vous testé le compilo 64 bits et dans quelles conditions ?

Je suis encore sous XE2, mon responsable est le seul de l'équipe en XE3, je crois qu'il a regardé cela pour les DCOM car un DCOM 32 sur OS64 semble être isolé dans sa propre session et les différents clients ne partagent pas la même instance, je peux pas t'en dire, le DCOM je ne maitrise pas du tout

Mais il est prévu de remplacer DCOM par DataSnap, on a aussi des Services Windows, pour le moment, on impose un Serveur 2008 R1 au client, sinon notre logiciel ne fonctionne pas sous R2 ou 2012

[yvslms]

Je voulais être certains que l'on parle de la même chose, tu veux dire que le débogage local ne fonctionne pas en FMX64 mais que le "débogage distant" fonctionne, c'est hallucinant !
En général, Delphi est BEAUCOUP plus stable que C++Builder !

Ayant RAD XE2 j'ai testé sous Delphi le problème est le même !
Je dois donc oublier qq chose !
La manip (aussi bien sur Builder que sur Delphi donc) :
Gestionnaire de projet > Plateforme cible > clic droit > Ajouter une plateforme > Windows 64 > "Rendre active la plateforme" sélectionnée
Le code compile mais à l'exe le message : "Impossible de trouver le programme ...\Win64\nom de l'appli.exe"
Le répertoire Win64 n'est effectivement pas créé.
Par contre le répertoire Win32 est bien créé avec du code 32 bits !
Egalement en suivant très précisément l'exemple donné ici :
http://blogs.embarcadero.com/davidi/2012/12/20/42150/
le problème est le même

[ShaiLeTroll]

Vérifie tes chemins de tes différents configuration Release\Debug que cela soit bien un truc genre "...\$(Platform)\$(Config)\"