Discussion :

[asenaici]

Bonjour,

Quelqu'un a-t'il déjà eu la situation suivante avec Delphi 10 Seattle et une vrai licence ?


1er test :
Lancement de delphi
Je charge un projet
Puis au bout de 2 ou 3 secondes, crash : il n'y a plus de delphi

2e test
Lancement de delphi
Création nouvelle application fiche vcl (il place une fiche)
enregistrement du projet : il enregistre la form puis le projet
Et là...crash : il n'y a plus de delphi


Si quelqu'un a un avis, je suis preneur.
Merci d'avance

[ShaiLeTroll]

Pas ce cas extrême.
En Seattle, cela arrive que lors de l'ajout d'une nouvelle unité provoque une erreur comme "Index out of Bounds" surtout quand l'éditeur contient beaucoup d'onglet.

Sinon, certains projets, surtout en XE2, des codes trop poussés avec des type imbriqué, générique ... cela provoquait des erreurs internes du compilateur obligeant à changer le code sinon l'IDE ne faisait plus correctement sa coloration syntaxique ni l'audit de code.

Et en D7, un projet infâme qu'un collègue avait la charge plantait comme ça, à cause de DataModule contenant 300 objets (à l'époque, avec la taille des écrans, tous coller les uns aux autres)

[asenaici]

Bonsoir,

merci des conseils mais pour l'instant, je n'ai pas d'autres choix que de supprimer les fichiers avec les extensions suivantes :
dproj, dproj.local, identcache, stat
Je supprime également tout contenu dans les dossiers __history et __recovery

Apparemment, ça fait l'effet puisque j'arrive ensuite à charger mon projet et tout refonctionne normalement !

Quand ça se produit, il n'y aucun message d'erreur : il se ferme tout seul comme un grand puis plus rien.

Je commence à comprendre : je pense que c'est un problème de ressources, très certainement un bug de cette version.

Crdt

[ShaiLeTroll]

Ayant aussi des ressources dans un projet D10, pas de soucis.

[Paul TOTH]

je n'ai pas souvenir de ce genre de choses bizarres.

est-ce qu'il y a des plugins ? sait-on jamais.

le seul cas un peu douteux que j'ai rencontré c'est après avoir placé des DLL dans le répetoire BIN de Delphi...il n'aime pas cela et si je me souviens bien les menu fichier/enregistrer et fichier/fermer sont inversés ou un truc stupide comme ça

tu peux aussi installer madExcept et l'utiliser dans un package de composants, il capturera les erreurs de l'IDE

[pprem]

La suppression de *.local et *.identcache permet d'éviter ce genre de choses sur de gros projets, notamment avec l'utilisation de TFrame en quantité ou avec des héritages de fiches qui parfois, si on a bidouillé les DFM / FMX à la main) peuvent poser problème de synchro entre les caches et le contenu des sources au chargement du projet.

Ce phénomène ne s'est plus reproduit depuis la 10.4 Sydney pour moi sur les projets qui le faisaient de temps en temps.

[ShaiLeTroll]

... notamment avec l'utilisation de TFrame en quantité ou avec des héritages de fiches qui parfois, si on a bidouillé les DFM / FMX à la main)

Pas besoin de bidouiller, les Frames, c'est pas terrible, l'héritage de la DFM Form\Frame c'est infâme !
Si je fais un héritage de TForm, il est sans DFM, juste un objet avec des fonctionnalités supplémentaires.
Si je fais une frame une form dockable avec une séparation strict entre le conteneur et contenant.

Et c'est mon cas depuis D6.
A l'époque cela rendait tout l'éditeur de fiche instable, et la maintenance, c'est une plaie.

Pire, combien de fois, j'ai vu un héritage de fenêtre, où l'on cachait la moitié des truc hérités dont certaines choses héritées d'une Frame en plus, un tas de code pour compenser un héritage incohérent.
C'est un truc à déconseiller car c'est un piège avec le temps.
Sans compter le message aussi quand on modifie un ancêtre avec un descendant ouvert, l'IDE panique !

[pprem]

Je ne te rejoindrais pas sur le "infâme", mais il est certain que j'ai un projet où on a légèrement abusé des héritages de tout un tas de choses pour se simplifier la mise en forme de certains éléments. C'est joli à voir, mais l'IDE a eu quelques soucis avec la complexité du truc. Heureusement LSP est venu à la rescousse et ne plante plus l'IDE quand ça bloque.

[asenaici]

Bonjour à tous et merci pour vos commentaires.
Tout ça est très utile.
Peut-être des plug-ins mais àa aurait du faire l'effect depuis longtemps...
Toutefois, en fin de compte, je constate que quand cela arrive :
- je remarque que sur un tdatamodule, il y a beaucoup d'objets
- finalement, la suppression du fichier .dproj suffit pour revenir à l'état normal (sans plantage)
et dans ce cas, j'ouvre le projet via le fichier .dpr et, bien sûr, après avoir sauvegardé le projet,
il recréé le fichier .dproj

Puis quand je réouvre le projet de manière normale (donc avec le dproj), si ça se plante, je supprime
à nouveau le dproj pour rouvrir le projet avec le dpr.

C'est tout ce que j'ai trouvé de mieux à faire.

Merci dans tous les cas pour vos précieux conseils.

Cordialement

[ShaiLeTroll]

Toutefois, en fin de compte, je constate que quand cela arrive :
- je remarque que sur un tdatamodule, il y a beaucoup d'objets

Et en D7, un projet infâme qu'un collègue avait la charge plantait comme ça, à cause de DataModule contenant 300 objets (à l'époque, avec la taille des écrans, tous coller les uns aux autres)

Conclusion, cela n'a pas trop changé entre D10 et D7 en plus de 15 ans entre les deux.
J'utilise aussi des TDataModule mais au plus j'ai rarement plus de 40 Query, en général, elles restent fermées mais certaines préparées pour une utilisation plus performante, surtout dans un contexte de forte utilisation, comme dans un programme Server.
J'ai utilisé des TDataModule surtout parce que l'on a défini au sein d'une équipe une méthode commune, moi j'étais plutôt à mette le SQL dans le .PAS ou dans des fichiers .SQL lié en .RC\.RES

Je te recommande d'appliquer le concept "Diviser pour régner" !
Par exemple, je sépare toute la partie Reporting (ReportBuilder, FastReport...) du reste car cela produit beaucoup d'objet et des DFM assez lourdes.
Dans certains cas extrêmes, un DataModule ne contenant que les SELECT, un autre DataModule ne contenant que les UPDATE\INSERT, aussi bien pour la lisibilité mais aussi pour gérer un objet Connexion différent par exemple pour un utilisateur DB n'ayant pas les mêmes droits ou alors cloisonner les données non validées encore plus que via les Transactions.

Evidemment, les DataModule sont multiples, regroupées par thème métier, séparer la partie technique du programme avec les partie plus business, ne pas non plus tout mélanger un DataModule pour la gestion des droits et des menus, un DataModule plutôt orienté Client, un autre pour les Commandes et le Stock, un autre ou plusieurs pour la BI\DataMining ... toujours dans l'idée de thématiser, cela facilite la compréhension du programme, cela aide la maintenance.

Et encore, un DataModule peut-être "caréner" pour être utilisé comme un objet avec méthode et propriété, plutôt lié en RunTime qu'au DesignTime.

[asenaici]

Messages bien reçus.

Merci pour les informations.

Bonne journée

Crdt