API32 Windows et appel DLL

Bonjour,
Je voudrais, depuis mon programme principal lancer une fonction qui se trouve dans une dll en lui passant un paramètre.
Tout d’abord quand je ne passe pas de paramètre, je fais ceci et ça marche très bien :
1.- FARPROC dllEntryAdd1;
2.- hinstdll = LoadLibrary(lpchemindll);
3.- dllEntryAdd1 = GetProcAddress(hinstdll, dllEntrySet);
4.- dllEntryAdd1(); // ici ma dll chargée dans mon prog principal démarre correctement
Lorsque je veux passer un paramètre j’obtiens des erreurs de compil sur le prog ppal (donc sans rapport avec la présentation côté dll puisque je ne vais pas jusqu’au link) !
Lorsque je modifie uniquement la ligne 4 comme ci-dessous :
1.- FARPROC dllEntryAdd1;
2.- hinstdll = LoadLibrary(lpchemindll);
3.- dllEntryAdd1 = GetProcAddress(hinstdll, dllEntrySet);
4.- dllEntryAdd1(lpbuffer);
J’obtiens l’erreur de compile suivante : « Extra parameter » sur la ligne 4
Lorsque je modifie la ligne 1 et 4 comme ci-dessous :
1.- FARPROC dllEntryAdd1(LPTSTR); //ou encore : FARPROC dllEntryAdd1(char *p);
2.- hinstdll = LoadLibrary(lpchemindll);
3.- dllEntryAdd1 = GetProcAddress(hinstdll, dllEntrySet);
4.- dllEntryAdd1(lpbuffer);
J’obtiens l’erreur de compile suivante : « Lvalue required » sur la ligne 3
Lorsque je modifie les lignes 1, 3 et 4 comme ci-dessous :
1.- FARPROC dllEntryAdd1(LPTSTR); //ou encore : FARPROC dllEntryAdd1(char *p);
2.- hinstdll = LoadLibrary(lpchemindll);
3.- dllEntryAdd1(lpbuffer) = GetProcAddress(hinstdll, dllEntrySet);
4.- dllEntryAdd1(lpbuffer);
J’obtiens encore l’erreur de compile suivante : « Lvalue required » sur la ligne 3
Je sais bien que ce dernier exemple est farfelu.
Help per favor
Thanks

Salut,
FARPROC est un type de pointeur de fonction générique qui ne prend aucun paramètre et retourne un int. Pour les fonctions de la dll qui prennent des paramètres, tu dois définir le type de pointeur adéquat. Exemple pour une fonction qui prend un char* en paramètre:

Pour d'autres exemples, tu peux regarder parmi mes codes sources: Lecteur flash, Détecteur déconnexion etc.

Merci, je vais regarder ça dès demain

J’ai fait ça:

typedef INT (WINAPI* PMAFONCTION)(char* );
PMAFONCTION dllEntryAdd1;
dllEntryAdd1 = (PMAFONCTION)GetProcAddress(hinstdll, dllEntrySet);
iret=dllEntryAdd1(lpcheminlog);

et ça marche impeccable merci, sauf que maintenant j’ai un problème dans ma DLL,
mais peut-être vas-tu me dire que c’est normal :

Dans mon point d’entrée ci-dessus (dllEntryAdd1) de ma dll, je me contente de récupérer l’adresse lpcheminlog qui est l’adresse dans mon programme principal du chemin d’un fichier dans lequel ma dll écrira un peu plus tard et je fais passer cette adresse en variable globale de ma dll (Nomfichier = lpcheminlog) (Nomfichier est une variable globale). Je me contente ensuite toujours dans le même point d’entrée de ma dll de lancer un hook pour récupérer les touches du clavier et je reviens immédiatement dans mon programme principal qui lui contient la boucle Getmessage.
Il faut préciser que la callback de traitement des touches se trouve dans ma dll et c’est elle qui ira écrire dans le fichier dont le chemin est dans le programme principal et l’adresse de ce chemin en variable globale de ma dll.
Je tape une ou deux touches tout se passe bien, puis tout à coup la variable globale de ma dll (Nomfichier) perd l’adresse du buffer du programme principal qui contient le nom du fichier. Est-ce normal ? J’ai essayé de mettre Nomfichier en variable static mais ça ne change rien !
Faut-il que je recopie le chemin du fichier (et pas seulement son adresse) dans une variable globale de ma dll ?
Merci

Re-bonjour,
J'ai jeté un oeil sur ton développement: "Service Windows dans une DLL lancée par svchost.exe" et j'ai vu que tu te servais d'une variable globale: char buff[MAX_PATH] qui était initialisée dynamiquement et utilisée par les différentes fonctions de ta DLL. Sans avoir peut-être pour l'instant tout compris, il me semble que je fais la même chose, j'ai aussi dans ma DLL une variable globale nommée: char buffer[Tailmax] dans laquelle dès le premier appel de la DLL par le programme principal (1ère fonction de la DLL), je recopie le chemin complet d'un fichier log: "C:/....../log.txt" dont l'adresse est passée en paramètre dans ce buffer. Ce fichier est ensuite utilisé en écriture par une autre fonction de la DLL (fonction CALLBACK activée à chaque appui sur une touche par la boucle Getmessage du programme principal).
Ce que je ne comprends pas c'est qu'au début ça fonctionne, mais après très peu de temps, mes données globales sont réinitialisées (donc à vide pour le buffer en question) (un peu comme s'il fallait rafraîchir son contenu !) alors que dans ton développement ça n'a pas l'air de te poser de problème ? (après un nouveau test il semblerait: je commence à taper des touches alors que c'est une fenêtre quelconque du net qui est affichée, ça marche, je change de fenêtre du net et dès que je tape une nouvelle touche ça ne marche plus car le buffer a été réinitialisé) à noter cependant que ça marche dans 100% des cas si au lieu d'initialiser ce buffer dynamiquent je l'initialise en dur à la compile. Toutefois, je me pose des questions pour les autres variables globales de ma DLL dont je me sers pour communiquer entre les différentes fonctions. Je me pose aussi des questions sur les variables internes aux fonctions de la DLL déclarées en static, si tout est réinitialisé de temps en temps pourquoi pas celles-ci.

Complément d'info:
Pour mieux tester, je ne fais plus rien dans ma callback, je ne fais juste qu'imprimer par MessageBox le buffer pour voir à quel moment il disparaît, puis return immédiat sur CallNextHookEx.
En fait tant que je tape des caractères sur la fenêtre active de mon programme principal (ou ce qui est bizarre dans la fenêtre CMD de MSDOS) mon buffer ne disparaît pas, dès que je tape des commandes sur d'autres fenêtres actives que ces deux premières fenêtres mon buffer disparaît (je sors des MessageBox vides). Mais lorsque je reviens sur une des deux premières fenêtres, mon buffer réapparaît un peu comme s'il y avait plusieurs versions de DLL qui tournaient.
Il doit y avoir un truc que je n'ai pas compris...