Comment puis-je vérifier que les propriétés liées aux composants ne sont pas "perdues"?

Question

J'utilise Delphi 2007. Parfois, les propriétés liées aux composants sont perdues. Il s'agit généralement de propriétés d'action et de fichiers lookupdatasets. J'ai quelques fois eu quelques corrections de bugs d'urgence et envoyé une version aux clients avec un résultat quelque peu catastrophique à cause de cela :-) Tout le monde sait un moyen de vérifier que les propriétés qui sont censées être définies sont vraiment définies, ou d'une manière pour empêcher cela de se produire?

Answer 1

Vous avez reçu plusieurs bonnes réponses sur la façon de détecter quand cela se produit (voté en haut). Mais une façon d'empêcher cela (parfois) est de s'assurer que vous avez ajouté toutes les unités référencées à votre RMR. Si vous ouvrez un formulaire, par exemple, qui contient des composants qui référencent d'autres composants sur un module de données et que ce module de données n'a pas été ajouté au projet DPR /, il est presque certain que l'IDE supprimera ces références. supprime les références qu'il ne peut pas déterminer sont valides. Si, en revanche, le module de données est dans le DPR, alors l'IDE sera capable de le trouver, et il est moins probable qu'il supprime les références en premier lieu

Malheureusement, il arrive encore de temps en temps temps, de sorte que vous devez toujours prendre les mesures de précaution détaillées dans les autres réponses. Mais cela améliorera les choses, si vous ne le faites pas déjà.

Answer 2

Vous pouvez affecter de telles valeurs dans le code, évidemment.

Plus important encore, vous devez différencier chaque fichier avant de passer à sourcecontrol. Toujours.

Assurez-vous que vos fichiers dfm sont de type texte et non binaire. Ensuite, il sera facile de voir les changements indésirables avant l'enregistrement/validation.

Différant tout a arrêté beaucoup de gaffes potentiels pour moi.

Un système de construction et de test automatique vous donnera également une certaine confiance dans ce que vous livrez.

Answer 3

Vous voulez un moyen de vérifier si les valeurs sont définies correctement. Eh bien, vous pouvez utiliser des tests unitaires pour cela. Il suffit d'initier un formulaire, comparer les propriétés et fait.

La comparaison des dfm est également une bonne méthode mais elle ne prend pas en compte les changements dus aux changements de valeurs par défaut ou aux modifications du code.

Answer 4

Créer un projet de test dunit. Exécuter le test avant la publication. Sonner toutes les cloches lorsque le test échoue.

Answer 5

Lorsque vous ajoutez un formulaire, un module de données ou un cadre à un projet, l'EDI insère un petit commentaire "tag" après le nom de l'unité dans le fichier dpr. D'après mon expérience, si pour quelque raison que ce soit cette étiquette n'est pas présente, l'IDE est plus enclin à perdre des références de composants inter-modules. Je soutiens de tout coeur l'idée de toujours voir les différences avant chaque validation au contrôle de version, si vous utilisez tel chose.

Answer 6

Je déteste dire cela, mais le contrôle de code source peut aider dans ces situations. Même avec une correction de bogue d'urgence, vous devriez tout vérifier dans un dépôt de code source (Perforce est mon favori personnel). Dans une petite correction, vous pouvez voir par quels fichiers ont changé si vous avez des changements que vous n'attendez pas.