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".