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