Discussion :

[vadim]

Bonjour à tous,

Un souci est m'apparu avec Delphi XE10 Seattle depuis deux semaines environ. Avant, tout allait bien.
Il se produit lorsque je charge un projectGroup. Je travaille sur l'un des projets et si je veux en activer un autre dans le même projectgroup, systématiquement
l'EDI se fige, un message d'erreur apparaît : l'EDI ne répond pas, le programme doit s'arrêter. Très désagréable, très répétitif, chronovore etc etc.

Agacé, j'ai bien sûr de suite désinstallé Delphi Seattle et l'ai réinstallé de A à Z. Hélàs , rien n'y fait. Il continue de se bloquer et "planter" sans arrêt si dans un projectgroup je veux changer de projet actif

Il y a aussi la fenêtre de "récupération de fichier" qui s'affiche sans raison à chaque lancement de Delphi et a chaque chargement de projet. Le message est vide et s'il n'a récupéré aucun fichier je ne vois pas ce que
cette fenêtre obtempestive vient me casser les pieds.

Dernière chose, delphi se coince également très souvent en signalant un "Stack overflow, veuillez redémarrer le programme" ....

Je soupçonne un souci de mauvais paramétrage de Seattle(?)
Quelqu'un at'il déjà vu ce problème qui rend l'outil quasiment inutilisable.

Merci d'avance
Vadim

[ShaiLeTroll]

En Seattle avec groupe de projet (4 exe, 2 service, VCL, 64 bits) : aucun soucis.
Delphi 10 Seattle Version 23.0.22248.5795

As-tu des fichiers en commun entres les projets, pas des simples unit mais des DFM ?
FMX ou VCL ?
la palette change selon FMX ou VCL, le passage de l'un à l'autre pouvait soit être lent soit dupliquer des icones

supprime tous les __history et __recovery

[vadim]

Merci beaucoup pour cette piste.

J'ai bien vérifié.
En fait je suis toujours sur des projets Delphi 32 bits. Le tout sur sur une machine W 7 64 bits. Les erreurs de l'EDI n'apparaissaient jamais avant mon premier message.
J'ai bien effacé les _recovery et _history Ca va mieux en effet, en supprimant TOUS les _history et _recovery dans la totalité des programmes et des composants impliqués.

En fait il y a deux cas où apparaîssait l'erreur "stack owerflow" et "l'application doit se fermer" lorsque je changeais de projet dans un projetgroup :

1er cas : deux applis de dessin (courbes, graphes et points sur un canvas) Aucun dfm commun entre les programmes, en revanche, il y a un objet que j'ai créé en commun sur les deux
et quand il s'instancie il pointe sur un canvas de panel que ce soit dans l'une ou l'autre appli.

2e cas : Il s'agit d'un tout autre ensemble d'applications partageant en effet des "datamodules" des dfm et des composants communs.

Le FMX n'est utilisé dans aucun des cas. Cela ne se produisait pas avant avec Seattle sur la même machine.

En tout cas, merci pour l'info qui me révèle des points que j'ignorais.

Et puis : "On apprend en se plantant"

Bien Cordialement
Vadim