Positionner le Débogueur sur le poste de développement à partir de conditions de production.

Lorsque le mécanisme de sécurité Wlangage est déclenché en production, il n'est pas toujours évident de parvenir à reproduire le même cas sur le poste de développement afin d'apporter les corrections nécessaires. Avant d'entreprendre un débogage à distance nécessitant une connexion au poste de l'utilisateur final, et d'être disponible au moment où l'erreur survient, il est possible d'utiliser un "Dump de débogage".

Rien de plus simple, grâce au lien "Enregistrer les informations pour le fournisseur de l'application (dump de débogage)" :

En effet, le lien permet d'obtenir un fichier d'extension wdump, qu'il suffit de récupérer sur le poste de développement. Une fois le fichier récupéré, un simple drag & drop au dessus du projet concerné permet de se retrouver dans le débogueur, au moment ou le mécanisme de sécurité a été déclenché, afin de mieux cerner le cas en consultant les variables, paramètres...

Il est également possible d'obtenir un dump par programmation, par exemple dans le cas où les déclenchements du mécanisme de sécurité sont traités par l'application :
http://doc.pcsoft.fr/fr-FR/?1000018834

Je profite de ce billet pour m'excuser auprès de ceux qui m'écrivent "ce blog est-il mort ?" ! Rassurez-vous il n'est pas mort. Mais comme tout le monde les "temps modernes" ne me laissent que très peu de temps pour partager, et prendre le temps pour des activités qui sortent d'un contexte purement professionnel.

Obtenir la liste de toutes les DLL utilisées par une application

Le code suivant peut être utile pour localiser toutes les DLL utilisés par une application, durant son exécution. Affichée à partir d'une fenêtre "à propos" ou de configuration avancée, cette liste peut permettre :
- de vérifier l'emplacement des modules réellement chargés,
- de vérifier les versions,
- de connaître les dépendances nécessaires.

sListeDLL est une chaîne
POUR TOUTE CHAINE sUneAppli DE ExeListeProcessus(exePID, exeNomCourt) SEPAREE PAR RC

SI ExtraitChaîne(sUneAppli, 2, TAB) ~= fExtraitChemin(ExeInfo(exeNom), fFichier+fExtension) ALORS
sListeDLL = ExeListeDLL(ExtraitChaîne(sUneAppli, 1, TAB))
FIN

FIN
Saisie1 = sListeDLL

Supprimer les signes cabalistiques dans le sujet des emails envoyés avec WINDEV.

Suivant la messagerie utilisée pour la lecture d'un email envoyé avec WINDEV, Outlook notamment, le sujet des emails peut ne pas avoir les bons caractères (accents remplacés...).

C'est le cas lorsque le message est envoyé avec l'appel suivant :

EmailEnvoieMessage("SessionSMTP")

Pour que le mail envoyé soit correctement lu dans ce cas, il faut modifier le code d'envoi, en donnant l'option EmailOptionEncodeEntête :

EmailEnvoieMessage("SessionSMTP", EmailOptionEncodeEntête)

Sans cette option, si le sujet du message est "c'est l'été", le message envoyé contient :

From:...
Subject: c'est l'été
To:...

Alors qu'avec l'option, il est codé différemment, et est mieux interprété par certaines messageries :

From:...
Subject: =?ISO-8859-1?Q?c'est_l'=E9t=E9=00?=
To:...

Déploiement en réseau des applications, comment modifier le lien entre chaque poste utilisateur et le serveur ?

Le déploiement avec mise à jour en réseau est extrêmement pratique, puisqu'il permet :
- d'avoir l'application en local sur chaque poste pour de meilleures performances,
- de ne mettre à jour que le serveur lors des modifications de l'application, afin qu'elle se propage automatiquement sur tous les postes.
Cette solution offre donc les avantages, sans les inconvénients d'autres possibilités de déploiement.

Le seul point délicat de cette solution, concerne le changement de serveur. En effet toutes les installations locales de l'application "pointent" vers le serveur en ayant son nom stocké dans un fichier de paramètres. De ce fait, si le serveur doit changer de nom, ou de ressource partagée, il est nécessaire d'intervenir sur le paramétrage de chaque poste afin de rétablir la possibilité de mise à jour automatique.

Voici les solutions possibles, de la plus avantageuse à la plus contraignante :

- réinstallation complète de l'application en "push"
Sur le serveur le programme WDADMINEXE.EXE permet de déployer l'application sur les postes utilisateurs. Donc si le réseau le permet, une première possibilité consiste à déployer à nouveau l'application sur tous les postes. De cette manière sur chaque poste le lien vers le nouveau serveur sera mis à jour.

- réinstallation complète de l'application sur chaque poste :
Cette seconde solution vise à obtenir le même résultat que précédemment, en installant à nouveau l'application sur chaque poste. Le fichier de paramètre est ainsi remis à jour, par contre cette solution impose de repasser sur tous les postes pour relancer l'installation du serveur.

- modification du fichier de paramètre de chaque poste :
Le fichier de paramètre utilisé par se mécanisme ne nomme WDUPDATE.NET, il est placé dans le répertoire de l'exécutable sur chaque poste. C'est un fichier de type ".INI", il est donc possible de le modifier depuis l'application elle-même à l'aide de la fonction "AppliChangeParamètre" (ou "INIEcrit"). Il est donc envisageable avant le changement de serveur de faire une dernière mise à jour de l'application, qui sera capable via le code du projet de corriger le WDUPDATE.NET. Une fois la mise à jour prise par chaque poste, il sera possible de changer le serveur, puisque la version locale de l'application aura maintenant l'emplacement du nouveau serveur.

Applet Java et exécutable Win32 générés depuis un même projet, comment supprimer les erreurs de compilation "La fonction n'a pas d'équivalent dans le framework WL/Java" ?

Lorsqu'un projet contient deux configurations, l'une permettant de créer un exécutable Windows, l'autre permettant de créer une applet Java, tous les codes sont compilés en permanence, quelque soit la configuration en cours. Ainsi même si la configuration de projet chargée et celle de l'exécutable Windows, les erreurs de compilation de la forme suivante peuvent remonter :

La fonction n'a pas d'équivalent dans le framework WL/Java

L'utilisation de la fonction "EnModeTest" ne permet pas d'éviter la compilation. La solution pour éviter cette compilation systématique : le "code-cible conditionnel". Il suffit dans le code utilisant une fonction non disponible en Java, de dérouler le menu "Code / code-cible conditionnel". L'interface propose alors de sélectionner les codes à ajouter, et divise le code en sections. Il est ainsi possible d'avoir un code compilé dépendant de chaque plateforme cible. Illustration avec un bouton faisant appel à un état :

Où paramétrer l'utilisation d'un serveur proxy pour utiliser les fonctions FTPEnvoie, FTPRécupère ?

Les fonctions FTP* du WLangage reposent directement sur le API FTP de Internet Explorer. Si un proxy doit être utilisé, il faut donc le configurer directement dans les options de Internet Explorer, et non pas avec la fonction Proxy du WLangage.

Voici en image l'emplacement du réglage dans Internet Explorer :

Exception pour confirmer la règle, il y en a toujours une, la fonction "FTPCommande", contrairement à "FTPRécupère" ou "FTPEnvoie", permet d'adresser directement le serveur FTP, sans passer par les API de Interner Explorer. Elle est obligatoire si le serveur FTP n'est pas accessible au travers de Internet Explorer.

Exporter les données d'un champ table vers Excel sans limitation sur le nombre de lignes.

Lors de l'utilisation de l'option automatique "Exporter vers Excel" d'un champ table, ou de la fonction "TableVersExcel", l'extension "XLS" est proposée par défaut. Le fichier Excel créé a donc le format des versions de Excel antérieures à la version 2007. Ces versions sont limitées à 65 536 lignes dans une feuille.

Pour exporter les données sans aucune limitation, il faut que format du fichier Excel créé soit en version 2007. Il faut pour cela préciser lors de l'exportation une extension "XLSX", au lieu de "XLS".