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.