L'exécution "Go" d'un projet en test depuis l'éditeur de WINDEV, est globalement identique à l'exécution obtenue après compilation du projet, lorsque l'exécutable est lancé. En effet, le test "Go" depuis l'éditeur et l'exécutable compilé reposent sur le même framework d'exécution, la différence est le nom du processus :
- WDTST.EXE lorsque le test est fait depuis l'éditeur de WINDEV (WDTST64.EXE si test 64 bits),
- ou le nom donné à l'exécutable lui-même après compilation.
Quelques cas particuliers peuvent conduire à une différence de résultat après compilation, voici les principaux :
- vérifier le paramétrage du mode test, dans le volet "Projet" du ruban, groupement "Mode test" (raccourci Shift+Ctrl+F9). En effet, il permet de faire des tests "Go" depuis l'éditeur, en modifiant les conditions d'exécution : compte utilisateur, répertoire courant, manifeste, ligne de commande... Un jour ou l'autre on tombe dans le piège d'avoir fait un test avec une modification de ces réglages, sans revenir à la configuration standard. Ainsi l'exécutable généré par la suite pourra avoir une réaction différente du mode test (ligne de commande différente, recherche d'un fichier faussée par l'utilisation d'un répertoire courant différent, droits manquants car l'utilisateur Windows n'est plus le même ...).
- vérifier les expressions évaluées dans le débogueur. Le passage d'un traitement en pas à pas permet de tester des variables, des fonctions WLangage... Ces traitements exécutés peuvent avoir un impact sur le résultat de l'exécution. Exemple extrême, un appel de HLit* dans les expressions à évaluer a une incidence sur le code en cours si il parcours la base de données ! Une fois l'application compilée, les expressions du débogueur ne sont plus évaluées, un résultat peut donc être différent.
Dans ce cas précis, la différence de résultat s'observe entre le test, et le test via le débogueur.
A noter concernant les expressions du débogueur, qu'une réinitialisation complète est possible en supprimant le fichier de paramètres \<nom-projet>\<nom-projet>.env.
- rechercher les appels de la fonction "EnModeTest". Il arrive parfois de conditionner un code qui finalement devient nécessaire à tous les traitements, même après compilation. L'oubli de "EnModeTest" n'est pas rare, et peut également provoquer une différence de résultat avec l'exécutable compilé.
- contrôler la localisation et utilisation du Framework WINDEV. Dans l'assistant de création de l'exécutable, les étapes relatives au Framework d'exécution permettent d'indiquer l'emplacement dans lequel le framework sera utilisé, ainsi que les DLL qui pourront être chargées. En mode test tout le Framework est chargé de façon systématique, mais l'exécutable ne chargera que la partie demandée. Si une fonctionnalité entière ne donne pas le résultat attendu, ou qu'une DLL est manquante, il s'agit très probablement d'une erreur à l'étape de configuration du Framework lors de la création de l'exécutable.
- contrôler le contenu de la bibliothèque des éléments intégrés à l'exécutable (étape "mise en bibliothèque" de l'assistant de création de l'exécutable). Si une application doit lire et/ou écrire un fichier à un emplacement précis d'un disque, le fichier ne doit pas être inclus dans l'exécutable.
- effectuer un essai de compilation en désactivant le JITc (appel de ModeExécution(DésactiveExécutionOptimisée) au début du projet).
- vérifier les traitements de modification des champs appelés implicitement lorsque la persistance des données est utilisée (champs avec la coche "Mémoriser la valeur")
Concernant l'accès aux données de l'application, des différences peuvent également se produire dans le cas de l'utilisation d'une base HFSQL Classic, ou d'un fichier en accès direct (txt, .ini...). En effet dans le cas du test, les données sont localisées par défaut dans le répertoire de génération de la configuration courante. Avec l'exécutable compilé, les données doivent être dans le dossier des données de l'utilisateur Windows, à moins qu'elles ne soient dans l'exécutable (non modifiables dans ce cas). En cas de difficulté sur la localisation des données utilisées, un " Trace(NomFichier ..Répertoire)" peut rapidement lever toute ambiguïté, tout comme une localisation explicite des données avec HChangeRep. Concernant les performances, surtout dans le cas d'un projet contenant d'un nombreux éléments, il est conseillé de forcer directement l'accès aux données sur le disque avec HChangeLocalisation("*",hDisque).
En cas de différence persistante de résultat d'un exécutable, après vérification de ces différents points, un débogage de l'exécutable lancé et/ou un audit dynamique s'imposent afin de suivre en pas à pas le traitement, comme on le fait traditionnellement depuis l'éditeur en mode test en phase de développement. Là la différence finit toujours par ressortir, généralement assortie d'un "bon sang mais c'est bien sûr" !
Mise à jour 17/9/2020
Il y a également une différence de performances entre le mode test "Go" et l'application compilée, un billet dédié a été ajouté pour cet aspect.
|