Aide à la saisie obligatoire !!!

Voici une fonctionnalité de la version 12 qu'il faudrait rendre obligatoire, par respect pour les utilisateurs des applications !

Un jour ou l'autre on se retrouve devant un champ, sans savoir où trouver l'information attendue. Dans le meilleur des cas une bulle d'aide est proposée, ou un bouton d'aide dans la fenêtre, mais il n'est pas rare de ne pas être assisté.

Alors que toute saisie respectueuse de l'utilisateur, devrait permettre instantanément de savoir de quoi il s'agit. Voici un exemple de mise en oeuvre de l'aide à la saisie avec WINDEV 12 (c'est également disponible pour les pages WEB des sites WEBDEV) :


Dès que le curseur est placé dans le champ, l'information d'aide s'efface progressivement avec un effet de fondu pour laisser place à la saisie.

Aucune programmation n'est requise, il suffit de fournir l'information qui guidera l'utilisateur dans la description du champ :

WINDEV 12 non documenté !

Deux fonctionnalités non documentées de WINDEV 12 découvertes après quelques minutes d'utilisation, certes avec l'aide du support, mais cela vaut un petit billet pour faire circuler l'information en attendant que la documentation rattrape la productivité des développeurs !

1. Recherche dans les styles et les options d'édition des champs, information sur le Blog du support. A vos claviers pour tester le Ctrl+F, il y en a peut être d'autres du même type à découvrir !

2. Afficher un PDF dans une image est enfantin :

IMG_TEST_PDF = fRepExe()+["\"]+"AideDépart.PDF"

Le positionner sur une page précise est ... tout aussi simple, à condition d'avoir trouvé la bonne propriété (ce que l'aide ne donne pas par défaut pour le moment) :

IMG_TEST_PDF..NuméroPage = 4

Au passage le support m'informe qu'à terme le champ image lorsqu'il est affecté avec un PDF, aura une gestion d'ascenseurs, de zoom. Le tout basé sur la technologie "Zéro code" chère à PC SOFT !

Compléter les appels aux navigateurs par un message d'information

Il n'est pas rare de lancer depuis une application le navigateur Web par défaut sur un site. Le traitement est de la forme :

LanceAppliAssociée("http://elianlacroix.blogspot.com")

Mais les configurations de plus en plus sécurisées peuvent bloquer cette ouverture du navigateur. L'action pourrait en effet être commandée par un programme malveillant...

Il est donc bon lorsque cette ouverture est ponctuelle de donner au passage un message d'information indiquant l'action, et la conduite à tenir en cas de difficulté. Ceci est d'autant plus vrai dans le cas d'une application dite "grand public".

Voici une illustration de ce mécanisme mis en place dans l'application Tomtom Home lorsque l'on tente de consulter la documentation d'un GPS fraîchement déballé :


Ainsi même si l'ouverture est impossible, l'utilisateur final n'est pas dérouté par un bouton sans aucun effet. L'ajout d'une minuterie sur le bouton peut être un plus, ainsi que d'une coche "ne plus afficher ce message".

Accélérer les traitements d'importation de données

Les temps de traitement pour des importations de données peuvent générer une attente importante si se cumulent des volumes importants, et des index nombreux. En effet, chaque ajout va nécessiter de mettre à jour les différents index correspondant aux données.

Une alternative permettant des traitements d'importations plus rapides, consiste à différer la mise à jour des index en s'appuyant sur le mécanisme de réindexation.

La phase d'importation se fait en utilisant la fonction "HEcrit" en lieu et place de "HAjoute". Elle permettra d'insérer les données à importer, sans aucune mise à jour des index. Cela permet un gain de temps, très significatif dans le cas d'un fichier ayant de nombreux index.

Une fois les données importées, il suffit d'utiliser la fonction "HRéindexe" qui va mettre à jour les index avec les nouvelles données. Dans bien des cas, cette méthode en deux temps est plus rapide qu'une importation traditionnelle avec la fonction "HAjoute".

Sur le même sujet :
Synthèse pour aller plus vite !
Accélérer le lancement des applications

Accélérer le lancement des applications

Par facilité on place régulièrement la fonction "HCréationSiInexistant" au début des applications pour s'assurer de la création systématique de tous les fichiers de données. Le piège, la base grandissante, est d'avoir une attente importante lors de cet appel, car il provoque une ouverture de tous les fichiers de données. Et l'ouverture initiale des fichiers fait partie des opérations les plus coûteuses en temps.

Il y a une solution, presque miracle, c'est l'option "hOuvertureDifférée" de la fonction :

HCréationSiInexistant("*", hOuvertureDifférée)

En effet, le but escompté est atteint, car tous les fichiers restent créés automatiquement. Mais pour les fichiers existants, l'ouverture ne sera pas faite immédiatement. Elle sera différée à la première utilisation effective du fichier. On comprend aisément le gain de temps très appréciable puisque :
- le temps d'ouverture des fichiers est réparti au fil de l'application,
- seuls les fichiers réellement utilisés seront ouverts.

Sur le même sujet :
Synthèse pour aller plus vite !
Accélérer les traitements d'importation de données

Contrôle lors du changement de volet d'un onglet

Le champ onglet est pourvu d'un code de modification, appelé lorsque l'utilisateur change de volet. Ce code permet d'exécuter des traitements concernant le volet qui vient d'être affiché. Il s'exécute lorsque le changement de volet est déjà fait.

Pour toutes sortes de raisons, il peut être utile d'exécuter un traitement lorsque l'utilisateur clic sur un nouveau volet, mais avant même que le nouveau volet ne soit affiché. Il faudrait pour cela un code de modification sur l'onglet, mais avant changement !

Ce code n'étant pas proposé par défaut, il est possible d'utiliser en lieu et place le code optionnel "Bouton gauche enfoncé" du champ onglet. En effet ce code est bien appelé avant même que le changement de volet ne soit effectif. Il permet donc par exemple de faire un contrôle de saisie sur le volet sélectionné avant le clic, pour si besoin interdire le changement de volet en inhibant l'événement.

Imprimer une image en gardant le choix de l'imprimante dans l'aperçu...

En créant un aperçu d'une image avec les fonctions "iAperçu", "iImprimeImage" et "iFinImprime", la fenêtre d'aperçu obtenue ne permet pas la sélection de l'imprimante. C'est pourtant bien utile notamment pour les applications qui s'exécutent depuis des postes portables qui changent régulièrement d'imprimante.

Une astuce permettant d'obtenir une impression d'image avec le choix de l'imprimante, consiste à utiliser un état créé par l'éditeur d'états, plutôt qu'une impression programmée.
Il suffit ensuite de lancer l'aperçu avec la fonction "iImprimeEtat", et l'aperçu sera pourvu du choix de l'imprimante. L'état sera on ne peut plus simple, avec un champ image affecté par un paramètre de l'état, paramètre recevant le nom de de l'image à afficher à l'ouverture de l'état.

Eviter les oublis avec les règles

Les projets ont toujours des traitements, ou des champs, qui doivent se comporter de façon uniforme, ou provoquer d'autres actions obligatoires au domaine d'application.

Dans la précipitation quotidienne, il n'est pas rare de faire un oubli, préjudiciable en temps par la suite puisqu'il faut revenir sur le traitement ou l'interface, dans le pire des cas après un signalement de l'utilisateur final.

Il y a une fonctionnalité que j'avais initialement sous-estimée, baptisée "règle métier" qui limite grandement les risques d'oublis. En effet, elles permettent d'indiquer pour des champs ou fenêtres, des actions obligatoires, qui seront automatiquement rappelées pendant les phases de développement qui suivront.

Une illustration en image maintenant que l'information circule en vidéo :

Toujours plus d'informations !

Le site de PC SOFT propose de nouvelles sources d'informations à ne pas négliger pour ne pas passer à côté de fonctionnalités précieuses (cf. prochain billet sur les règles métiers).

Tout d'abord un nouveau blog "Technologies et Marchés" de l'équipe commerciale, mais contenant surtout de l'information technique (tous les blogs).

D'autre part des vidéos en grande quantité pour présenter bon nombre de fonctionnalités. Sans rentrer dans le détail, elles permettent de découvrir de nombreux principes, qu'il est ensuite facile de mettre en œuvre grâce à la simplicité des éditeurs. On retrouve même ces vidéos sur Youtube !

Synthèse pour aller plus vite !

Voyant apparaître sur les forums des demandes de conseils pour optimiser les accès aux données, j'ai regroupé ici les principaux éléments de réponse, et méthodes à employer. L'optimisation des accès est primordiale, surtout lorsqu'ils sont faits au travers d'Internet qui n'offre pas les débits d'un réseau local.

Privilégier les sélections par des requêtes :
Il est préférable d'effectuer les sélections de données au travers de requêtes. En effet, par opposition à des accès enregistrement par enregistrement, elles vont permettre de "ramener" sur le poste client les données sélectionnées, par "paquets" réseau bien remplis. Des lectures enregistrement par enregistrement vont au contraire générer du trafic avec à chaque fois peu de données. De plus la lecture d'un enregistrement impose de récupérer toutes ces rubriques, alors que la sélection d'une requête peut être affinée en ne prenant que les rubriques utiles à un moment donné. Ceci est d'autant plus vrai si la connexion se fait par Internet.

Optimisation des requêtes :
Le menu "Requête / Optimiser la requête" accessible en édition d'une requête doit finaliser la phase de création d'une interrogation. Il permet d'ajouter si besoin les clés dont la requête aura besoin pour un maximum de rapidité.

Statistiques des index à jour :
Les clés dans le fichier sont importantes, à condition que les statistiques des index soient régulièrement mis à jour (surtout après des ajouts en grand nombre).

Rester raisonnable :
La facilité avec laquelle on programme et accède aux données, le tout généralement dans l'urgence, provoque parfois une négligence de l'évaluation de ce que l'on demande. Chaque enregistrement à une taille bien précise, chaque interrogation va ramener un ensemble d'enregistrements, donc un volume précis. Il faut tenir compte, surtout en accès via Internet, de ce volume, afin d'évaluer avec le débit minimal si l'application ne demande pas trop par rapport à ce qu'elle peut recevoir.

Client/Serveur :
Privilégier un accès aux données au travers du moteur Hyper File Client/Serveur, il va permettre de soulager grandement le travail de chaque poste client, et donc de gagner en performances. Les procédures stockées vont offrir également des gains. Typiquement, un long calcul statistiques pourra être fait en "différé" de l'application, permettant à un utilisateur d'avoir un résultat immédiat en remplacement d'une attente.
Son mécanisme de "Log" pourra également permettre un suivi très fin des interrogations en vue de rechercher notamment des abus d'une station, ou d'un traitement.

Analyseur de performances :
Lorsque l'on a encore des attentes, il faut exécuter l'analyseur de performances qui va permettre de les localiser très précisément. Une fois que l'on sait où passe le temps, il devient possible de voir comment l'influencer (dans un programme uniquement à mon grand regret).
Cas particulier pour l'attente du matin, il faut garder dans un coin de tête le possible trouble que peut engendrer la restauration du système.

Ce billet n'a rien d'exhaustif le sujet étant si vaste, je tenterai de le compléter régulièrement. Mais pas trop vite tout de même, car il est temps pour moi de prendre quelques jours de repos en cette période estivale !

Sur le même sujet :
Accélérer le lancement des applications.
Accélérer les traitements d'importation de données

Attente au matin lors de la mise à jour d'un fichier ...

Description surprenante d'un utilisateur final :

Tous les matins le premier enregistrement d'une commande prend du temps, les suivants sont immédiats !?

Surprenante, car c'est plutôt au fur et à mesure que l'on "charge" la machine tout au long de la journée qu'elle ralentit, plutôt qu'à son démarrage. Et pourtant, cela peut se produire avec les postes XP configurés par défaut et utilisant une base Hyper File.

Le fautif : la restauration du système de Windows car elle pense que les fichiers NDX (index Hyper File) sont des fichiers systèmes à sauvegarder. De ce fait, après chaque démarrage du poste, si une modification est demandée sur un fichier Hyper File ("HModifie", "HAjoute", "HSupprime"...), une sauvegarde du fichier est faite et peut donc être coûteuse en temps suivant sa taille. Plus généralement, sont concernées toutes les actions qui provoquent une modification de l'index. En revanche la simple consultation n'a pas d'incidence sur la restauration du système.

La solution consiste à indiquer au mécanisme de restauration du système qu'il doit ignorer les fichiers d'index de votre application. Pour cela une clé de registre est mise à disposition par Microsoft. Il suffit donc d'aller insérer une valeur dans cette clé avec la fonction "RegistreEcrit".

La clé de registre est la suivante : HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\BackupRestore\FilesNotToBackup
Il faut insérer une valeur texte dont le nom est une chaîne quelconque, par exemple le nom de votre application, et la donnée le chemin à exclure.

La copie d'écran ci-contre donne une illustration, et ce lien donne une page de détail sur un site Microsoft.

Echec de visualisation des pages d'une aide CHM

Surprise après le déploiement d'une application déployée sur un serveur (aucun fichier sur les postes des utilisateurs à part un raccourci) : les aides au format CHM présentaient une erreur de "Navigation vers la page Web annulée".

Renseignement pris auprès du support, rien de plus normal avec un Windows XP à jour : ce n'est pas autorisé !!! Sécurité Microsoft oblige, les .CHM doivent être en local pour une visualisation directe. Il est cependant possible de passer outre cette "sécurité", en suivant les recommandations de cet article :
http://support.microsoft.com/default.aspx?scid=kb;fr;902225

Mon état est devenu fou, il ne voit pas mon paramètre !

"Tranche de vie", avec un long moment perdu à ne pas réussir à passer un paramètre à un état. Malgré un iImprimeEtat(NomEtat, Paramètre), j'avais systématiquement le message "on attendait 1 paramètres, on en a reçu 0".

Après de longues minutes à chercher, j'ai finalement trouvé mon erreur dans la description de l'état, ou par mégarde les bornes "min" et "max" étaient cochées je ne sais plus pour quelle raison. Le bon code d'appel de l'état avec des bornes et un paramètre aurait du être iImprimeEtat(NomEtat, ValeurBorneMin, ValeurBorneMax, Paramètre).

J'espère que ce billet pourra dépanner quelqu'un, un jour, ce qui me permettra de me sentir moins seul sur pareil bêtise !

Identifier les emails entrants qui sont des réponses aux précédents emails sortants

Il est de plus en plus fréquent de devoir implémenter un suivi des emails dans les systèmes d'information, par exemple pour qu'une réponse soit directement dirigée vers le bon collaborateur.

L'exemple WD Suivi Email de la LST 68 donne le principe de base, en utilisant la variable Email.Référence. Mais j'ai eu besoin d'aller plus loin pour le cas ou l'on souhaite récupérer directement l'identifiant du dernier message que l'on a envoyé. En effet, le champ Email.Référence empile les identifiants des différents messages, il peut donc être utilise de faire un parcours en sens inverse de son contenu pour trouver l'identifiant du dernier message envoyé. D'autre part dans la structure des emails on peut trouver directement l'identifiant du dernier message, dans une section "In-Reply-To".

Voici donc deux fonctions permettant de parvenir au résultat attendu, n'hésitez pas à les réutiliser si elles répondent à vos attentes !

FONCTION ChercheRéférence(_SourceEmail)

// Recherche dans le code source d'un email reçu en paramètre
// s'il s'agit d'une réponse à un message envoyé précédemment
// On recherche d'abord la balise In-Reply-To, puis dans les
// références (en partant de la fin)
// MESSAGEID_DOMAINE est une constante du projet contenant
// le domaine donné lors de l'envoi des messages (partie droite du @)

sReference est une chaîne
sListeRéférence est une chaîne

sReference = :InReplyTo(_SourceEmail)

SI Position(sReference, MESSAGEID_DOMAINE, 1, SansCasse) ALORS
// Une référence a été trouvée, elle est renvoyée.
RENVOYER sReference
SINON
// Pas de "InReplyTo" dans ce message, on va regarder les références de l'email en partant de la fin.
SI Email.Référence <> "" ALORS
// On supprime les espaces entre les références pour les parcourir
sListeRéférence = Remplace(Email.Référence, " ", "")
POUR TOUT CHAINE sReference DE sListeRéférence SEPAREE PAR "><" DEPUISFIN
// On teste si la référence en cours nous appartient
// Si oui, on a retoure car c'est la plus récente et donc celle que l'on veut.
SI Position(sReference, MESSAGEID_DOMAINE, 1, SansCasse) ALORS
RENVOYER SansEspace(Remplace(Remplace(sReference, ">", ""), "<", ""))
FIN
FIN
// Pas de référence trouvée si on arrive jusque là
RENVOYER ""
SINON
// Par de référence non plus (nouveau message ou réception d'un Webmail qui ne les fait pas suivre)
RENVOYER ""
FIN
FIN

FONCTION InReplyTo(_SourceEmail)

// Retourne le In-Reply-To d'un email dont on reçoit
// le source complet en paramètre (par exemple Email.Source)
// Le In-Reply-To trouvé correspond à l'identifiant d'un email
// envoyé précédemment

sInReplyToBalise est une chaîne = RC+"In-REPLY-TO:"
sInReplyTo est une chaîne
nPosInReplyTo est un entier

nPosInReplyTo = Position(_SourceEmail, sInReplyToBalise, 1, SansCasse)

SI nPosInReplyTo > 0 ALORS
sInReplyTo = ExtraitChaîne(_SourceEmail[[(nPosInReplyTo+Taille(sInReplyToBalise)+1) A ]], 1, RC)
RENVOYER SansEspace(Remplace(Remplace(sInReplyTo, ">", ""), "<", ""))
SINON
// L'info n'est pas trouvée
RENVOYER ""
FIN

Si vous faites un copier/coller du code dans votre éditeur, utilisez ensuite le menu "Code ... Réindentation automatique" afin d'avoir le code correctement affiché.

Pourquoi le code de modification d'un champ s'exécute à l'ouverture d'une fenêtre ?

Dans l'ordre normal des choses, l'ouverture d'une fenêtre provoque l'enchaînement des traitements suivants :
- code de déclaration des globales de la fenêtres,
- code d'initialisation successives des différents champs,
- et enfin le code d'initialisation de la fenêtre.

Alors qu'elle peut être l'option qui provoque l'exécution du code de modification d'un des champs, avant le code d'initialisation de la fenêtre ?

C'est l'option "Mémoriser la valeur" du détail de la description des champs. En effet, j'ai bataillé un moment pour trouver pourquoi j'avais un onglet dont le code était appelé de la sorte. C'est comme tout, une fois qu'on le sait, cela devient simple et évident. En effet, comme le système restaure un choix de l'utilisateur de l'application, il exécute également le code qui avait été provoqué par ce choix.

Installation MSI ou CAB ? Localisation Framework ?

Les combinaisons d'installations d'une application WINDEV MOBILE sur un périphérique mobile sont nombreuses, il n'est pas évident de s'y retrouver au départ :
- Utiliser le Framework PC SOFT non renommé,
- Utiliser un jeu de DLL renommées,
- Utiliser un Framework commun renommé.
Le tout à combiner avec le type d'installation retenue : via un fichier MSI ou un fichier .CAB.

Pour faire un bon choix, il faut avoir les réponses aux questions suivantes qui vont dépendre du domaine d'activité, du matériel (...) :
- l'installation sera-t-elle faite sur un mobile directement, sans connexion à un PC ?
- le mobile dispose-t-il d'un espace de stockage important (carte mémoire additionnelle) ?
- plusieurs applications devront-elle être installées ?

Avec ces réponses, il est facile de s'orienter vers le choix le plus adapté, sachant qu'il s'agit de toute façon de compromis :

- installation sur mobile sans connexion à un PC ?
Dans ce cas il faut générer une installation en .CAB qui sera copiée sur le mobile (et automatiquement supprimée après exécution). Dans le cas contraire, un MSI sera préférable car exécuté au travers d'un installeur Microsoft avec lequel l'utilisateur est généralement familiarisé.

- le mobile dispose d'espace avec une carte additionnelle ?
Dans ce cas il est préférable d'utiliser un jeu de DLL renommées, unique pour l'application. De cette manière un .CAB unique sera créé facilitant l'installation. Dans le cas contraire, il faut limiter l'espace occupé en ayant un unique Framework sur le mobile. Si une seule application doit être installée, on garde un jeu de DLL renommées, unique pour l'application. Par contre s'il faut installer plusieurs applications, on retient le choix :
-- utiliser le Framework PC SOFT non renommé pour placer le Framework directement dans le mobile,
-- ou utiliser un Framework commun renommé pour placer le Framework directement sur une carte mémoire.
Dans ces deux cas, 2 fichiers .CAB sont générés : un pour l'application, l'autre pour le Framework.

J'espère que ce résumé pourra donner quelques orientations...

"Mobilité" en nouveau sujet

Quelques jours passés en Suisse le mois dernier, de nouveaux matériels répondants maintenant à des attentes réelles des utilisateurs, et une bonne promo à "1 euro de plus" comme PC SOFT en a le secret, ont eu raison de moi : me voilà tout fraîchement équipé d'un Smartphone (QTEK) HTC S710.

L'occasion donc d'ajouter une nouvelle catégorie dans le Blog : la mobilité ! J'espère prochainement vous faire partager mes premières astuces et conseils, mais il va falloir que je découvre auparavant ce "nouveau monde" ou l'ergonomie doit être sans cesse la priorité du Développeur !

Il ne faut pas se fier aux idées reçues, ces petits concentrés de technologies ne sont plus des gadgets !

Ndlr : ne vous méprenez pas en ce qui concerne la Suisse, j'ai simplement pu y observer une utilisation bien plus fréquente de ce type d'équipement qu'en France. Rien à voir avec ce qui pourrait fâcher un douanier !

Obtenir une représentation hexadécimale d'une chaîne de caractères alphanumérique

Petite astuce lorsque l'on doit donner une forme hexadécimale à une chaine : utiliser la fonction "NumériqueVersChaine" qui permet la conversion simple d'une valeur décimale en hexadécimale. Exemple :

sChaine est une chaîne = "Bonjour, 27 juin 2007"
sChaineHexa est une chaîne

POUR i = 1 A Taille(sChaine)
sChaineHexa += NumériqueVersChaîne(Asc(sChaine[[i]]), "2X")
FIN

Info(sChaineHexa)

Une application directe, visualiser le Hash d'un fichier par exemple, car sans conversion de ce type la valeur contient des signes cabalistiques peu lisibles.

Pourquoi le fond d'une fenêtre ne change pas avec la propriété ..ImageFond ?

Pour le déploiement des applications, il faut garder dans un coin de tête que les éléments (fenêtres, états, images ...) de la bibliothèque sont prioritaires à ceux localisés sur disque.

Exemple type, dans une application on propose à l'utilisateur de changer l'image de fond de sa fenêtre principale. Pour cela, on a dans le code de déclaration des globales de la fenêtre :

MaFenêtre..ImageFond = ComplèteRep(fRepExe())+"ImageFond.jpg"

Il suffit de changer l'image "ImageFond.jpg" du répertoire de l'exécutable pour personnaliser l'image de fond de la fenêtre. Mais attention, cela ne fonctionne que si dans l'application aucune image "ImageFond.jpg" n'est utilisée par ailleurs. Dans le cas contraire, l'image utilisée par l'application est incluse dans la bibliothèque, elle est prioritaire, et une nouvelle image "ImageFond.jpg" dans le répertoire de l'exécutable est tout simplement ignorée.

Colonne combo d'une table, syntaxe de récupération de la valeur donnée par "gLien" au chargement

Lorsqu'une colonne combo d'une table est chargée par programmation avec "ListeAjoute", et que chaque élément a un identifiant donné avec "gLien", la récupération de cet identifiant n'est pas immédiate.

D'abord il ne faut pas cocher l'option "retourner la valeur spécifiée avec la fonction gLien" dans le détail de la description de la colonne combo.

Ensuite il faut utiliser dans le code la syntaxe suivante :

Info(NomTable.NomColonneCombo[NuméroLigne][NomTable.NomColonneCombo[NuméroLigne]])

Sans cette syntaxe, la récupération de l'information donnée au chargement avec "gLien" n'est que partielle.

Ndlr : ne pensez pas que j'ai trouvé cette syntaxe par moi-même, il s'agit d'une information obtenue du support !

Comment stopper un sablier récalcitrant ?

Pour faire patienter un utilisateur, l'utilisation d'un sablier est parfaitement adaptée. Mais dans la "vie" d'une application, un traitement simple au départ s'enrichie au fil du temps, fait appel à des composants, dialogues avec d'autres applications ... bref au final, il y a quelque part un Sablier(Vrai) qui persiste et ne veut plus s'enlever même avec un Sablier(Faux) dans le traitement.

Voici une méthode de contournement permettant de s'assurer de la disparition définitive d'un sablier laissé par un traitement.

Il faut créer une procédure globale "StopSablier", qui contiendra uniquement un appel de Sablier(Faux). Les automatismes de procédure feront le reste, comme le montre la copie d'écran du billet. Pour résumer, avec un seul appel de la procédure dans le code, on va appeler 3 fois Sablier(Faux), on est ainsi certain de reprendre le curseur de souris standard !

Pas forcément élégant, mais radicalement efficace !

Définir l'instruction suivante pour déboguer 10 fois plus vite !

Pendant longtemps le passage au Débogueur d'un code permettait :
- de suivre l'exécution en pas à pas (F7),
- de repérer le traitement à corriger,
- faire la correction,
- relancer un test pour s'assurer du résultat en ayant donc à refaire tout le processus permettant d'arriver au traitement...

Mais maintenant il y a le bouton que je surnomme le "bouton magique du Débogueur", qui permet de définir l'instruction suivante, tout en débogant. Il facilite en effet considérablement la mise au point et permet :
- de suivre l'exécution en pas à pas (F7),
- de repérer le traitement à corriger,
- faire la correction, et immédiatement rexécuter le code juste avant cette modification !!! Il n'est plus nécessaire de relancer le test et donc de refaire tout le processus permettant d'arriver au traitement.

Il est même possible de changer une fenêtre sous l'éditeur, et de réexécuter son ouverture. Mais là les cas d'usage sont moins fréquents.

Migrer une analyse vers une autre base de données...

Les forums contiennent souvent des sujets de la forme "comment migrer mon analyse" en Oracle, en SQL SERVER, MYSQL...

J'avais évoqué ce sujet dans un précédent billet, il n'y a aucune migration à faire au niveau des descriptions de fichiers pour utiliser une base de données ou une autre ! Si dans l'analyse un fichier est décrit en Oracle, sa description peut être appliquée en Hyper File, SQL SERVER ou tout autre base pour laquelle on dispose d'un provider OLE DB ou d'un accès natif.

La clé du mécanisme : les fonctions "HOuvreConnexion" et "HChangeConnexion".

Peu importe le type indiqué dans l'analyse, à tout moment le programme peut :
- appeler "HOuvreConnexion" pour ouvrir une connexion vers une base de données,
- puis appeler "HChangeConnexion" pour associer les tables de l'analyse, à cette nouvelle connexion.

C'est donc un mécanisme à garder dans un coin de tête, bien plus rapide que de se lancer dans des modifications de l'analyse, générations ...

Jauge en lieu et place du sablier lors de l'exécution d'une requête, la "soluce" !?

Les utilisateurs ne supportent pas les écrans figés avec un sablier, pourtant imposés lorsqu'une requête importante doit être exécutée.

Afin d'afficher une jauge durant le traitement d'une requête, il faut bien récupérer en premier lieu le nombre d'enregistrements à traiter avec la fonction "HNbEnr", et cette dernière fige l'application avec le sablier tant que toute la requête n'est pas exécutée dans sa totalité.

Et bien cela n'est plus vrai, après consultation des dernières nouveautés !!!

La fonction "HNbEnr" a été dotée d'une option "hNonBloquant". Elle permet de connaître immédiatement après l'appel de la requête, le nombre d'enregistrements déjà récupérés. Il est donc possible de débuter le traitement de la requête par son parcours, tout en affichant une jauge certes approximative, mais une jauge. Au fur et à mesure du parcours, si la propriété "..ExécutionTerminée" retourne faux, il est possible de réajuster la jauge avec le nombre d'enregistrements récupérés en rappelant "HNbEnr".

Tous ceux qui aiment observer les utilisateurs de nos applications, savent déjà que le traitement sera jugé plus rapide, du moment qu'une progression est visible !

Extraire sur disque des fichiers contenus dans une bibliothèque ?

J'ai longtemps pensé que cela n'était pas possible, et pourtant ... astuce découverte sur le forum WIN DEV, elle mérite d'être connue j'espère pouvoir la relayer par ce billet !

Je remercie son auteur que je cite (presque) directement :

- Faire un fichier Hyper File avec une rubrique mémo binaire,
- Ajouter les fichiers que l'on veut pouvoir extraire dans le mémo binaire,
- Inclure ce fichier (.fic, .ndx, .mmo) dans l'exécutable,
- dans le code indiquer que pour ce fichier il faut le rechercher dans la bibliothèque :
HChangeLocalisation(Fichier, hWDL)

Et voila.

Il suffit de rechercher dans le fichier Hyper File l'enregistrement qui contient le fichier que l'on souhaite extraire, puis de l'extraire avec :
HExtraitMémo(Fichier,MemoFichier,"C:\chemin...\FichierDestination")

Message d'origine.

Ajout de descriptions de tables MYSQL dans une analyse provoque une erreur MSVCRT.DLL ou WDHF

Rien de pire qu'une action que l'on utilise couramment, et qui sur un poste ne daigne pas s'exécuter. J'ai rencontré ce cas avec l'importation d'une table MYSQL dans une analyse. Après le listage des tables de la base MYSQL, un des messages suivants était affiché :

Une erreur système inattendue est survenue.
Si cet incident se produit de manière systématique
Module MSVCRT.DLL...

Ou :

Erreur interne à la DLL WDHF

L'origine de la panne ? Une version de LIBMYSQL.DLL qui ne convenait pas à WINDEV.
Le problème a donc disparu en installant un MYSQL et en récupérant sa LIBMYSQL.DLL standard. Précédemment il s'agissait d'un MYSQL installé avec par EasyPHP.

Pourquoi la taille d'un fichier Hyper File n'est pas réduite après un lot de suppressions ?

L'appel en série de la fonction "HSupprime()" ne provoque pas la diminution de la taille du fichier. Ceci est valable pour le fichier de données (.FIC) et pour son mémo (.MMO).

Déroutant au premier abord, mais normal en creusant un peu. En effet, pour le système de fichiers (FAT32, NTFS...) l'allocation d'un espace ou sa restitution est coûteuse en temps. Il n'y a qu'à voir la différence de temps entre un copier/coller par l'explorateur, et un couper/coller du même volume. De ce fait en cas de suppression, la taille initiale est conservée, il y a simplement un "marquage" des enregistrements laissés libres par les suppressions. Les ajouts ultérieurs viendront réutiliser ces espaces vides.

Si après une suppression importante on souhaite récupérer l'espace disque correspondant, il est possible d'exécuter la fonction "HRéindexe" avec compression : là tout l'espace est restitué.

A noter que par un parcours séquentiel du fichier sur les numéros d'enregistrements, on peut passer sur les enregistrement marqués à réutiliser (cf. fonction "HEtat").

A noter d'autre part que ce mécanisme met clairement en évidence le fait qu'il ne faut jamais baser un traitement, encore moins une liaison, sur un numéro d'enregistrement puisqu'il n'est pas fixe.

Récupération d'un variant provenant d'une DLL ActiveX...

Lorsqu'une procédure WLangage est appelée par une DLL en passant un variant en paramètre, une "gymnastique" est nécessaire pour récupérer l'information renvoyée par la DLL. Cela vaut bien un billet, pour gagner un peu de temps, car en tout premier lieu on aurait tendance à écrire l'entête de la procédure avec :

PROCEDURE AppeléeParDLL(RecupValeur est un variant)

Pourtant avec cette déclaration le message suivant sera obtenu lors de l'exécution :

"Un élément de type ne peut pas être converti vers le type variant"

La bonne déclaration, puis syntaxe de récupération du paramètre est la suivante :

PROCEDURE AppeléeParDLL(RecupValeur)

varRecupVariant est un Variant = RecupValeur
VariantConvertit(varRecupVariant, wlChaîne)
Info(varRecupVariant)

A noter que l'appel de la procédure "AppeléeParDLL" en réponse à la DLL ActiveX est initialisé avec la fonction "AutomationEvénement".

Le numéro d'enregistrement des fichiers et des requêtes.

Lors du parcours d'un fichier, on peut connaître la position physique de l'enregistrement dans le fichier avec la fonction HNumEnr(). A partir de ce numéro, il est possible par la suite d'effectuer un accès direct à l'enregistrement avec la fonction "HLit", ou une modification avec "HMofifie(,)".

Par contre lors du parcours du résultat d'une requête, cette même fonction "HNumEnr" donne un numéro d'enregistrement dans la requête, mais pas celui de l'enregistrement d'origine dans le fichier. Pour avoir le numéro de l'enregistrement du fichier, il est possible d'utiliser la variable d'état "H.NumEnr" après une lecture dans la requête. On peut ainsi envisager après une lecture d'un enregistrement du résultat d'une requête, de modifier directement l'enregistrement correspondant dans le fichier avec "HMofifie(,)".

Attention par contre à l'utilisation du numéro d'enregistrement pour accéder aux données. Cette technique convient à un instant donné dans l'application. Par contre il ne faut pas utiliser ce numéro d'enregistrement par exemple pour lier des enregistrements. En effet, la position physique d'un enregistrement dans un fichier est modifiée lors d'opérations de maintenance. Pour les liaisons, l'utilisation de l'identifiant automatique est la meilleure solution.

Copier un menu contextuel d'une fenêtre à une autre ?

Les menus contextuels n'étant pas proposés dans le volet de l'éditeur ou la zone Kouglof, il faut donc "ruser" pour récupérer un menu contextuel d'une fenêtre vers une autre. L'astuce est la suivante :
- dans la fenêtre contenant le menu contextuel, créer un bouton,
- associer ce bouton au menu contextuel,
- copier/coller ce bouton vers la fenêtre qui doit recevoir ce menu ...
et c'est fait ! La fenêtre dans laquelle le bouton a été copié contient maintenant le menu. Le bouton peut être supprimé.

Plus qu'une ligne de code : One-liner

En clin d'oeil au billet "Pour quelques lignes de code en moins", je pousse le bouchon un peu plus loin avec un programme WIN DEV qui n'a plus qu'une ligne de code, ou "one-liner". Il s'agit de remplacer dans un fichier le caractère de code ascii 10 par un traditionnel "retour-chariot" ou RC. Les adeptes auront reconnus un fichier provenant de Linux devant être transformé pour faciliter son utilisation sous Windows !

fSauveTexte(Remplace(LigneCommande(), fExtraitChemin... (LigneCommande(), fExtension), ...
"New"+fExtraitChemin(LigneCommande(), fExtension)),...
Remplace(fChargeTexte(LigneCommande()), Caract(10),RC))

Le code se trouve dans le code du projet, aucune interface n'est requise pour ce "convertisseur". Une copie du fichier dont le nom est reçu en ligne de commande est créée, avec remplacement du "Caract(10)" par un "retour-chariot". La copie garde le nom et l'emplacement d'origine, seul un "New" est ajouté au nom, juste avant l'extension.

Pour quelques sourires de plus : améliorer l'accessibilité de la Loupe.

Au petit matin dans les bouchons, il y a deux attitudes. Coller le pare choc de son prédécesseur en se jurant, une main crispée sur le volant et l'autre sur le klaxon, que personne ne vous volera une place. Ce mode de conduite permet de s'assurer un gain de temps pouvant aller jusqu'à 3 secondes, pour l'arrivée au feu suivant 75 mètres plus loin. A l'inverse, il est possible de toujours laisser une distance de sécurité raisonnable avec son prédécesseur, afin de permettre aux autres usagers de prendre leur place dans le trafic. Cette attitude permet de récolter le sourire d'autres conducteurs, soulagés d'enfin trouver une âme charitable tolérant un changement de file, l'accès ou la sortie d'une place de parking... J'opte personnellement pour cette seconde attitude. Pour une journée efficace, la récolte quotidienne de 3 s/km (1) me semble une bonne moyenne.

Un bonus de sourires (2) peut être obtenu en ajoutant un "plus" à une application existante, avec un coût de programmation quasiment nul.

Cas typique, une table fichier permet de rechercher un enregistrement via la loupe. La plupart des recherches se font via une même colonne de la table (numéro de commande, de téléphone, adresse email de plus en plus souvent ...). L'opérateur arrive sur sa fenêtre de recherche, vient cliquer sur la Loupe pour entamer une nouvelle recherche. C'est le genre d'opération que l'utilisateur final peut faire 50 fois dans la journée dans bien des applications.

Pour le "bonus sourires", ajoutez un tri automatique sur la colonne qui est la plus utilisée, et forcer dès l'ouverture de la fenêtre le "focus" sur la table en question. Il suffit d'insérer les appels des fonctions "TableTrie" et "EcranPremier" dans le code d'initialisation de la fenêtre. Le résultat : l'utilisateur dès l'ouverture de sa fenêtre de recherche peut immédiatement entamer la saisie d'une valeur, le passage en saisie dans la loupe de la colonne triée devenant ainsi automatique.

Un détail diront certains. Oui, mais je peux vous assurer qu'une personne ayant pendant des mois eu à faire cette recherche en allant cliquer sur cette loupe, va gagner un grand confort d'utilisation et vous faire de grands sourires le jour ou vous lui permettrez d'éviter ce clic en plus !


(1) s/km : sourires obtenus par kilomètre parcouru à moins de 10 km/h.
(2) rassurez-vous, si vous vous êtes reconnus dans la première attitude au volant, il en faut pour que les garagistes aient encore à changer des embrayages ;-), cela n'empêche pas d'aimer les sourires des Utilisateurs de vos applications !

64 Bits, mais à tous les étages

La création d'applications 64 bits peut être nécessaire pour répondre à certaines exigences de mise en exploitation.

Le passage d'une application existante en 64 bits, se fait simplement via la coche d'une option dans la description du projet. Mais attention tout de même, si c'est très simple dans une application constituée d'une unique bibliothèque, s'il y a au contraire de nombreux composants la tâche est plus importante. En effet, si l'application est compilée avec la compatibilité 64 bits activée, les composants qu'elle utilise devront également être générés avec la compatibilité 64 bits. Il faut donc penser à cocher l'option de compatibilité 64 bits dans les composants.

Rassurez-vous, l'éditeur vous indique par un message d'information la présence d'un composant qui ne serait pas à jour (ci-contre).

L'activation de la compatibilité 64 bits n'a que très peu d'effets sur les traitements. Les modifications à effectuer vont concerner les types des variables du WLangage, notamment dans les appels de fonctions des API Windows. En effet, une déclaration "est un entier système" doit être faite en lieu et place de déclarations avec "est un entier sur x octets". Là également c'est l'éditeur de code qui indique après une compilation les changements à faire, il n'est pas nécessaire de "fouiller" son code.

Il peut également être nécessaire d'ajouter des variables intermédiaires, car les fonctions du WLangage ne retournent pas des "entier système". C'est par exemple le cas de la fonction "Dimension" qui ne peut donc pas être donnée directement à la fonction "API" si la compatibilité 64 bits est active. Sur ce dernier point, PC SOFT proposera sans doute des évolutions, car cet ajout pourrait être évité.

Pour la phase finale de création de l'exécutable, il est bien d'avoir recours à une nouvelle configuration de projet. Elle permettra via un unique projet de générer un exécutable 32 bits et un exécutable 64 bits. Elle permettra également si besoin la création de composants, de Web services, le tout en une seule opération par le menu "Atelier / Génération multiple".

A savoir avant de déployer sous Windows Vista...

Après, au fil des bêtas, les incertitudes sur les fonctionnalités qui seraient actives ou non par défaut, Windows VISTA est devenu une réalité. Le voile est levé, plus aucun incertitude ne subsiste l'UAC est active par défaut.

L'UAC, ou pour les initiés User Account Control, est une des fonctionnalités majeure de Windows VISTA. Elle doit permettre de redonner au système la sécurité qui faisait défaut aux précédentes versions.
Lorsqu'elle est active, et que le programmeur ne tient pas compte de ses spécificités, un panneau d'information avec l'icône ci-contre sera fréquemment donné à l'utilisateur final qui risque d'être dérouté. En effet par défaut les privilèges sont restreints, il faut jusqu'à 7 clics par exemple pour supprimer un raccourci sur le bureau.

Ainsi par défaut un message relatif à l'élévation des privilèges peut être affiché régulièrement. N'ayant qu'une expertise limitée sur le sujet, je n'aurai pas la prétention de vous décrire les méandres de ce mécanisme. En revanche un article Microsoft détaille ce qu'il faut absolument connaître de l'UAC avant d'aborder Windows VISTA. Je vous encourage donc vivement à le consulter.

Si besoin dans un tout premier temps, notamment pour le Développement, il est possible de désactiver l'UAC. Plus généralement, les fonctionnalités de VISTA peuvent être activées ou désactivées via ce mode opératoire.

Bon à savoir, exemples revus à profusion...

Le DVD de la LST 66 contient en plus des exemples de la LST elle-même, une série d'exemples des précédentes versions ou LST, revus et améliorés.

En voici la liste un peu "brute", mais un Ctrl+F permet de rechercher un sujet qui vous intéresse :

WD Arbres en saisie, WD Calcul statistiques Hyper File, WD DerniersDocuments, WD Ecran Tactile, WD Fenêtres furtives, WD FileImpression, WD GANTT, WD Glossaire, WD JournalEvenement, WD ListeGraphique, WD ModeleImpression, WD PartageMemoire, WD Pays du Monde, WD photocopieur, WD Saisie assistée de répertoire, WD Saisie Email, WD Scanner, WD Select RTF, WD Table Etendue, WD Active Directory DotNet, WD JaugeFTP, WD Lecteur RSS, WD MotDePasse, WD ProxyPOP3, WD Threads FTP, WD VisuTIF, WD WMI DOTNET, WD APISystemes, WD Appels JAVA, WD Arbre Doublons, WD ContrôleADistance, WD ExtractionMIME, WD GroupwareCS, WD Impression de Tree View, WD Licence, WD ListeChaînée, WD Masque de saisie avancé, WD Onglets glissants, WD Paramètres Impressions, WD Persistance, WD Serveur RMI, WD Trace Socket, WW_DiagrammeGANTT, WW_ImagePass, WW_VitrineAWP, WW_ChangementCSS, WW_FlashParametrable, WW_Fraimes, WW_MapArea, WW_MiseEnEvidence, WW_ReassortXML, Pocket GANTT, Pocket Clavier Virtuel, Pocket ExtractionMIME, Pocket MotDePasse, Pocket Persistance, Socket Unicode.

Ndlr : je fais ce billet car je n'avais pas vu ce contenu lors de l'installation de cette LST, je me dis du coup pour me rassurer que je ne dois pas être le seul !

Accélérer les applications sur les configurations limitées, ou en TSE

Si les applications sont toujours plus agréables de part leur aspect et leur richesse fonctionnelle, elles sont forcément plus gourmandes en ressources.

Il arrive donc que des configurations ne suivent plus, soit en raison des caratéristiques d'une station, soit en raison d'une limitation des ressources dans un contexte TSE.

Une astuce à connaître dans pareil situation, consiste à "jouer" de la propriété "..AffichageActif". Pendant toute la durée d'un traitement important (remplissage de champs, calculs...), il sera possible de "débrayer" l'affichage qui est généralement le plus couteux en temps.

Si cela n'est pas suffisant, la création d'un rapport "WPF" avec les fonctions "AnalyseurDébut" puis "AnalyseurFin" permet généralement de repérer le(s) traitement(s) à optimiser avec l'analyseur de performances (appelé également Profiler).

Une interface personnalisée en quelques clics avec l'opacité des champs...

S'il y a bien un domaine dans lequel il est difficile de progresser lorsque l’on n’a pas la science infuse, c'est bien celui des interfaces !

Heureusement, les gabarits font une grosse partie du travail, en permettant d’avoir d’emblée une interface agréable, comme le montre l’image ci-contre avec une fenêtre au look Vista exécutée sur mon poste XP.

Mais avec quelques clics en plus, il y a moyen de se différencier du gabarit standard. En effet, l’opacité des champs permet d’apporter une touche esthétique supplémentaire. Il suffit de placer sous les champs une image piochée dans le catalogue. Une image en rapport avec le contenu de la fenêtre est vivement recommandée, ou une image type "splash screen" également proposée dans le catalogue.

Une fois l’image en place, il suffit de jouer sur son opacité, ainsi que sur celle des champs par-dessus pour obtenir un effet tout a fait convenable, et surtout sans passer par un outil de retouche d’image qui aurait nécessité de jouer de la transparence avec différents calques !

Voici un exemple de résultat, certes de piètre qualité car en cherchant une image d’une taille plus adaptée il aurait été possible de faire bien mieux, toujours en quelques clics.

A noter en astuce que le modifieur est très utile dans ce type de manœuvre pour par exemple changer l’opacité de plusieurs champs à la fois. D’interface austère, il est cependant parfaitement adapté à la manipulation des propriétés des champs de l’interface.

Pour quelques lignes de code en moins...

Je profite de ce premier billet de l'année 2007 pour souhaiter une excellente année à ceux qui me lisent, régulièrement ou non !


Il n'est pas rare d'empiler des SI ... SINON ... FIN pour des affectations de variables, de paramètres... Il en résulte un "code à rallonge", qui même avec l'enroulé de l'éditeur code reste long à manipuler. Typiquement, l'affectation des paramètres d'une requête, lorsque certains ne doivent pas être pris en compte, exemple :

SI ChampNom <> "" ALORS
Req.ParamNom = ChampNom
SINON
Req.ParamNom = NULL
FIN

SI ChampDNaissance <> "" ALORS
Req.ParamDNais = ChampDNais
SINON
Req.ParamDNais = NULL
FIN

..

HExecuteRequete(Req)
FichierVersTableMémoire(Req, TableSélection)

L'alternative se nomme "instruction conditionnelle monoligne" (cf entrée d'aide "Condition, Instruction ?"). Beaucoup de vocabulaire pour un principe tout simple : affecter une variable par une valeur, ou par une autre, en fonction d'une condition. L'écriture ci-dessus est ainsi simplifiée à l'extrême tout en restant lisible, une fois l'habitude acquise :

Req.ParamNom = ChampNom <> "" ? ChampNom SINON NULL
Req.ParamDNais = ChampDNais <> "" ? ChampDNais SINON NULL
..
HExecuteRequete(Req)
FichierVersTableMémoire(Req, TableSélection)