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.