PureBasic

Et avec +12 ?

STOP ! REMETS +16 !

Et explique-moi qu'est-ce que tu entends par "elle semble fonctionner" ???

Bah elle fonctionne si elle est appelé une fois (et encore aléatoirement)

C'est ce qu'il faut! On n'utilisera cette fonction API qu'UNE fois pour allouer la mémoire pour chaîne et désormais "réallouer" avec le pointeur obtenu ici (SPtr). Donc tu vois le message "MESSAGE DE LA DLL OK" s'afficher sous VB6 et, en plus désormais, on peut contrôler le pointeur puisqu'il devient accessible (SPtr)!

Par contre, quand tu me dis "aléatoirement", ça veut dire quoi?
Tu obtiens quel type de plantage? Quelle erreur?

En gros, ma question c'est: est-ce qu'un appel simple (du dernier code posté pour tester) sous VB de la fonction DLL PB fonctionne impeccable? Ou est-ce que cet appel simple bugue aussi? Et si jamais il bugue, quelle(s) erreur(s) apparaî(ssen)t sous VB?

(appel simple = juste tester le code que j'ai posté et qui appelle une fois la DLL)

(Ne t'inquiète pas pour le reste, AttachProcess et autre, j'y reviendrai pour expliquer, vu que tout est écrit noir sur blanc, rien n'est oublié)

Sous VB la fonction fonctionne parfaitement si elle est appelée une fois dès qu'elle est appelée 2 fois (ou plus) le programme plante totalement sans message d'erreur.

Sous VB2008 Express aucune erreur mais la fonction ne marche tout simplement pas.

Donc un appel simple fonctionne mais sous VB6 seulement. Ce genre de fonctionnement à appel unique va vite me poser des problème avec certaines fonctions, je préfèrerais éviter ça.

Rectification : Le programme en VB2008 Express ne renvoyait pas d'erreur mais était rester dans les processus avec 1.7 Go de RAM consommé.

Merci pour ces infos.

NY152 a écrit :je préfèrerais éviter ça.

(Sous-entendu les bugs)
>> Sans problème, on est bien d'accord à ce sujet. D'ailleurs, j'ai préféré te demander de faire d'autres tests (plusieurs appels sous VB) quite à alourdir la communication avec des tests et des découvertes de bugs plutôt que de te dire que c'était tout bonnement bon, une fois la fonction API trouvée. C'est ainsi qu'on a l'impression de "tourner en rond" depuis environ une page, autour de cette méthode de retour de chaîne. Mais on va bien finir par planter le clou correctement.

Tu viens de m'apprendre que VB2008 et VB6 ne récupèrent pas de la même manière la chaîne de retour. On va reporter la recherche de VB2008 et se pencher d'abord sur ce qui marche. Ce doit être cette valeur (+X) dans la macro qui diffère pour VB2008.

Ce qui est sûr c'est que dans InitWinamp(), il faudra rajouter un argument d'entrée pour que l'application VB client indique s'il tourne sous VB6 ou VB2008. A la limite, si tu connais une fonction ou une constante qui retourne la version du compilateur utilisé, on s'en servira à titre de commodité.

Pour revenir à VB6, c'est étrange qu'elle ne s'exécute pas une deuxième fois (boucle de 2). ça semble short, surtout si toi tu arrives à créer un couple de codes (VB)/(DLL PB) qui lit à l'aise tout un dossier de fichiers. Si tu peux me poster l'intégralité de ces deux codes (VB et PB) en pm ou dans ce sujet, peut-être (qui sait?) je décèlerai une subtilité qui mettra en lumière cette différence. Tu parles d'une question de délai avec les fonctions de Winamp. Je ne pense pas que ce soit spécialement ça avec Winamp, mais ton idée qu'un délai soit à respecter n'est pas du tout à laisser au placard: on va bien voir. De mon côté, je soupçonne que sous VB, le retour de chaîne est récupéré de diverses manières selon le contexte de l'appel de la fonction (ex: hors/dans une boucle), mais ça n'est qu'une hypothèse, là aussi, on va bien voir.

Si l'API d'allocation fonctionne parfaitement au moins une fois, c'est a priori tout ce qu'il nous faut pour tester maintenant la réallocation et la libération définitive de l'espace pour cette chaîne.

Voici donc les 3 fonctions. J'ai fait une erreur qui t'a conduit à ne pas retrouver la réallocation (Tu avais écrit "ReAllocString n'existe pas"). C'est SYSReAllocString_() (J'avais oublié le préfixe "Sys")

1) SysAllocStringByteLen_() >>> A n'utiliser qu'une seule fois dans InitWinamp() pour allouer l'espace pour chaîne et récupérer le pointeur de cet espace.

2) SysReAllocString_() >>> A utiliser dans les autres fonctions PB qui retourneront une chaîne à VB. La réallocation se fait grâce au pointeur détecté dans InitWinamp() avec SysAllocStringByteLen_()

3) SysFreeString_() >>> A n'utiliser qu'une seule fois dans CloseWinamp() pour libérer l'espace pour chaîne alloué.

VB6:
DLL PBBon j'espère que je ne me suis pas planté.
J'attends ta réponse pour ce test, et le couple de code VB/PB sur l'affichage d'un dossier.

La solution initlib / closelib ne peut pas avoir cours pour mon code. En effet je dois pouvoir avoir à des fonctions qui me donne des information en temps réelle sur la lecture donc la méthode n'est pas applicable. Et par "Je préfère éviter ça" je parlais du fait de n'avoir qu'un appel sur une fonction alors que je dois pouvoir l'appeler quand bon me semble (la fonction de la position dans le morceau). Pour ce qui est de VB2008Express, je ne m'en sert que pour les erreurs, je ne développe pas avec (le style frameworks j'adhère pas)

Je t'envois le code tout à l'heure pour que tu vois ^^

NY152 a écrit :La solution initlib / closelib ne peut pas avoir cours pour mon code.

Je ma mal exprimaé ! InitLib() et CloseLib() n'existeront pas! La ligne de code de InitLib() (« SPtr = SysAllocStringByteLen_(" ", 1) » la fonction API que l'on a testé et retesté un bon paquet de fois!) sera à insérer dans Init_Winamp(). Et Init_Winamp() reste à exécuter une seule fois. Idem pour CloseLib(), où son code est inséré dans Close_Winamp().

A la limite, tu me parlais de AttachProcess() et DetachProcess() plus haut: on pourra essayer de fourguer le code de InitLib() dans AttachProcess() et le code de CloseLib() dans DetachProcess() si vraiment la vue de ces lignes ailleurs te fait gerber!

La seule fonction API qui sera appelée à chaque retour de chaîne vers VB6, c'est SysReallocString_(). C'est elle, et uniquement elle. Il faudrait vraiment que cette dernière soit lente et inadaptée.

En gros, le schéma d'exécution de la DLL pour retourner 2 chaînes diverses, c'est comme ça:

[Alloc] -> [Realloc1] -> [Realloc2] -> [Libération]

Et non:

[Alloc1] -> [Realloc1] -> [Libération1] -> [Alloc2] -> [Realloc2] -> [Libération2]

Pour VB2008, c'est comme tu veux. Le but c'est quand même qu'on débugue le gros code que tu m'as transmis. Donc, si on s'épargne de deux tests avant de commencer ça, moi ça ne me dérange pas!

Bon, j'attends quand même ton code, tu vas sûrement m'apprendre quelque chose que je n'ai pas saisi sous VB avec celui-ci... Ma petite macro ASM manque sûrement d'une seconde valeur...

En attendant, si j'ai pu te rassurer, est-ce que le dernier test fonctionne parfaitement ou crashe-t-il parfaitement ?!?

J'y pense tu parle du code de scan de fichier (enfin c'est plus de la gestion de chaine pour la DLL) mais en fait ce code je l'ai déjà mit et il fonctionne (même très bien en boucle et tout)

NY152 a écrit :Je me suis amusé à faire 3 fonctions :

Code : Tout sélectionner

ProcedureDLL.I RetourneRepertoire(Chemin$)
Protected Repertoire.S
Repertoire=GetPathPart(Chemin$)
ProcedureReturn SysAllocStringByteLen_(Repertoire,Len(Repertoire))
EndProcedure

ProcedureDLL.I RetourneFichier(Chemin$)
Protected Fichier.S
Fichier=GetFilePart(Chemin$)
ProcedureReturn SysAllocStringByteLen_(Fichier,Len(Fichier))
EndProcedure

ProcedureDLL.I RetourneExtension(Chemin$)
Protected Extension.S
Extension=GetExtensionPart(Chemin$)
ProcedureReturn SysAllocStringByteLen_(Extension,Len(Extension))
EndProcedure

J'ai fais une boucle sur le dossier Windows, ça n'a jamais planté.

Je commence à me demander si les fonctions de Winamp ne sont pas trop lente dans le sens "libération" du terme.

EDIT :

On m'a dit que les DLL Windows devait avoir ce code en plus du reste :

Code : Tout sélectionner

ProcedureDLL AttachProcess(Instance)
EndProcedure
ProcedureDLL DetachProcess(Instance)
EndProcedure
ProcedureDLL AttachThread(Instance)
EndProcedure
ProcedureDLL DetachThread(Instance)
EndProcedure

Je pense qu'elle servent à déclarer/libérer tout le toutim mais sans vraiment avoir creusé la chose, je m'abstiendrais de dire une bêtise lol

Des qu'on applique ce modèle aux fonction de la DLL pour les plugins ça coince. En fait les fonctions des plugins ont été écrites en PB pour PB et ça doit être ça qui coince.

1) Je t'ai posté ce couple de codes VB/PB, et tu ne me donnes pas les résultats: ça marche ou ça plante?

VB6: DLL PB 2) Ensuite, comme tu peux le voir, je mets 2 codes: VB et PB. Quant à toi, pour l'affichage de l'intégralité d'un dossier, tu ne me remets que le code PB! Si je n'ai pas le code de Visual qui va avec, je ne risque pas de comprendre ce que tu m'as dit!

Désolé j'avais omis le code VB En gros juste une petite boucle. J'ai testé ça sur un répertoire qui contenait plus de 3000 fichiers ça n'a pas planté ^^

Pour le résultat du code que tu as mis je ferais un edit dans quelques minutes.

EDIT : Ton code plante.

NY152 a écrit :Pour le résultat du code que tu as mis je ferais un edit dans quelques minutes.

Ah, ok, je croise les doigts pour que ça marche...

Pour ton code en VB, en me disant que ça marche, tu me mets sur le cul...

Ollivier

Ben oui comme je disais plus haut, je pense que les crash sont plus liés au fonctions eux même à leurs retours.