Page 1 sur 1

Treads et parametres des procedures

Publié : sam. 24/avr./2010 18:57
par Backup
la doc dit :
L'argument '*Valeur' de CreateThread() est passé comme argument de la procédure appelée. Il est très important de ne pas modifier le nombre de paramètre de cette procédure, qui doit toujours rester à 1.
1 d'un point de vue programmation , je ne comprends pas cette limitation...
puisqu'on peut mettre 1 parametre , pourquoi pas plusieurs ??


2 pourra t'on compter voir sauter cette limite ??
je trouve carrément dommage de ne pas pouvoir utiliser une procédure avec autant de paramètres que l'on désire !

bref ça ressemble a du threads au rabais non ? :)

Re: Treads et parametres des procedures

Publié : sam. 24/avr./2010 22:42
par Le Soldat Inconnu
Moi, je mets toujours un paramètre bidon et je communique avec des variables globales. A l'inverse de toi, je le virerais bien, moi, ce paramètre :mrgreen:

Re: Treads et parametres des procedures

Publié : dim. 25/avr./2010 0:13
par nico
Ce n'est pas modifiable, je crois que ça vient de l'API Window qui n'en accepte qu'une.

Tu peux toujours passer l'adresse d'une variable structurée et là no limite.

Re: Treads et parametres des procedures

Publié : dim. 25/avr./2010 10:10
par Backup
nico a écrit : Tu peux toujours passer l'adresse d'une variable structurée et là no limite.
ha oui ! bien sur .... :)

j'espere juste que Tailbite va accepter ....
Moi, je mets toujours un paramètre bidon et je communique avec des variables globales

je suis dans le cadre d'une librairie (tailbite), et malheureusement les variables globales ne marche pas , avec les thread c'est comme si elles restaient vide !

si je met global (a la dll) et que je transmet mes variables en passant par une procedure
comme ça ; ben ça marche pas !

*******************toto.Lib (Tailbite)*******************
global a,b,c,d ; global a la librairie
procedure xxx(a,b,c,d$)
;trucmuche
endprocedure

proceduredll toto(a,b,c,d$)
Thread = CreateThread(@xxx(), *Valeur)
endprocedure
******************************************


*************** mon prg appellant apres avoir tailbité la lib ci dessus****************

toto(1,2,3,"coucou")

***********************************************
ne donne rien , c'est comme si les variables etaient vides !

je ne peux pas non plus mettre les variables en shared
parce que tailbite plante , il considere que les variables sont deja declaré ...(meme si je retire le global du debut de la lib !!)


bref ! d'un point de vue propreté du code, je vais essayer la methode a Nico
(si j'y arrive :lol: )

ps : je vais reprendre ton exemple :

Code : Tout sélectionner

Structure test
  a.l
  b.l
EndStructure

Procedure essai(*test.test)
  *test\a=10
  *test\b=11
EndProcedure

essai(@valeur.test)

Debug valeur\a
Debug valeur\b

:)

Re: Treads et parametres des procedures

Publié : dim. 25/avr./2010 11:21
par Le Soldat Inconnu
Rien n'empêche de lancer ton thread via une procedure classique, en gros tu appelle une fonction de la lib qui lance un thread interne à la lib, comme ça, tu fais ce que tu veux :mrgreen:

Re: Treads et parametres des procedures

Publié : dim. 25/avr./2010 12:49
par Geo Trouvpatou
Salut.

Voici un code non-fonctionnel :lol: , si ça peut faire avancer le chmilblick.
J'ai testé en faisant une vrai DLL et pas en faisant une lib mais je crois que dans les 2 cas c'est tailbit qui est utilisé.

Code DLL

Code : Tout sélectionner

;Global a,b,c,d$ ; global a la librairie

Structure sBidon
      a.i
      b.i
      c.i
      d$
EndStructure

;/
Global VarStructure.sBidon


;*******************toto.Lib (Tailbite)*******************
Procedure xxx(parametre.i)
      ;trucmuche
;       MessageRequester(d$, "Valeur : "+ str(a))
;       MessageRequester(d$, "Valeur : "+ str(b))
;       MessageRequester(d$, "Valeur : "+ str(c))
      
      MessageRequester(VarStructure\d$, "Valeur : "+ str(VarStructure\a))
      MessageRequester(VarStructure\d$, "Valeur : "+ str(VarStructure\b))
      MessageRequester(VarStructure\d$, "Valeur : "+ str(VarStructure\c))
EndProcedure

ProcedureDLL toto(a.i,b.i,c.i,d$)
;ProcedureDLL.i toto(a.i,b.i,c.i,d$)
;ProcedureDLL toto(*sBidon.VarStructure)

      VarStructure\a = a
      VarStructure\b = b
      VarStructure\c = c
      VarStructure\d$ = d$

      
      ;xxx(parametre.i) ; Fonctionne renvoi les MessageRequester
      
      CreateThread(@xxx(), *Valeur) ; Fonctionne que si l'on met un callDebugger :(

      ;ProcedureReturn Thread
      
EndProcedure
;******************************************
Code uilisant cette DLL

Code : Tout sélectionner

EnableExplicit

Prototype toto(a.i, b.i, c.i, d$)

If OpenLibrary(0, "DLLDobro.dll") 
      
      Global TestDobro.toto
      
      TestDobro.toto = GetFunction(0, "toto") 
      
      TestDobro(1,2,3,"coucou")
      
      CallDebugger ; Pas besoin de ça si on utilise simplement la fct : xxx(parametre.i) dans la DLL.
      
      CloseLibrary(0)
      
Else 
      Debug "DLL non trouvée..." 
      End 
EndIf
Alors chose étonnante, si dans la DLL, dans la procédure "toto" on active xxx(parametre.i) et que l'on désactive CreateThread(@xxx(), *Valeur)
Alors dans le programme pas besoin de CallDebugger, cela affiche bien les MessageRequester avec les bonnes valeurs.

Par contre si dans la DLL, dans la procédure "toto" on active CreateThread(@xxx(), *Valeur) et que l'on désactive xxx(parametre.i)
Alors dans le programme on a besoin de CallDebugger, pour que cela affiche les MessageRequester et ses bonnes valeurs.

Apparemment un Thread dans une DLL ça n'aime pas beaucoup.
Mais c'est peut-être un début de piste.

Dommage que Gnozal ne soit pas dans le coin, il avait l'air de connaître ce genre de chose.
Tu peux peut-être le MP (<- Ça n'est pas cochon).

Au passage Dobro, suite à ce que tu avais dit dans la doc à revoir pour CallFunction, je viens de m'apercevoir que dans la doc english de la 4.50 il y avait écrit ceci :
Return value

Result - The result of the function that has been called.

Note: This function is not very flexible and does not handle string/float/double/quad parameters or string/float/double/quad returns. The use of: prototypes is now strongly recommended.
Bye.

Re: Treads et parametres des procedures

Publié : dim. 25/avr./2010 14:13
par Backup
probleme Résolu ! (en utilisant quand meme un thread dans ma lib :D )

je donnerai la solution que j'ai choisi plus tard !!

mais il n'empeche que ma suggestion tiens toujours a propos des threads !

Re: Treads et parametres des procedures

Publié : mar. 04/mai/2010 17:07
par Geo Trouvpatou
Dobro a écrit :je donnerai la solution que j'ai choisi plus tard !!
Que de temps passé depuis le 25 avril :mrgreen:.

Re: Treads et parametres des procedures

Publié : mar. 04/mai/2010 18:36
par Backup
Geo Trouvpatou a écrit :
Dobro a écrit :je donnerai la solution que j'ai choisi plus tard !!
Que de temps passé depuis le 25 avril :mrgreen:.

que crois tu ? que je n'ai pas trouvé la soluce ?

je l'utilise dans ma librairie sur le Midi !
ou certaines de mes fonctions utilisent un thread...

si je n'ai pas donné la soluce depuis , c'est simplement que j'ai plus envie de la donner !
apres tout , j'en donne deja assez des soluces ;)

Re: Treads et parametres des procedures

Publié : mar. 04/mai/2010 19:23
par Geo Trouvpatou
Ouhhh t'es de mauvais poil ce soir (Je dis ça à propos d'une chose que tu m'as dite sur un autre post).
Ça fait suffisamment de temps que je suis ici pour savoir que je n'ai pas affaire à un mekkiTruc de programmeur qui sait tout sur tout et code mieux en pb que Fred lui-même.

Je sais que si tu dis avoir trouvé, alors c'est que c'est le cas.

Pour ma part dans le but de tenter de t'aider j'ai quand même passé une bonne 40aine de mn à essayer de trouve une soluce.
Bien évidemment aussi pour ma pomme, parce qu'ayant l'intention plus tard de créer une DLL, j'essaie de faire des exemples de tous les cas de figure possible dont je pourrais avoir besoin.
Une proc qui renvoit une String, un entier, qui active une proc qui ne renvoit rien etc.

Et ce problème je pourrai bien le rencontrer un jour.

Maintenant si tu écris : je donnerai la solution que j'ai choisi plus tard !!, c'est pour cela que je relançais le post.

Maintenant si tu as changé d'avis, ben tant pis pour moi.

Bye.

Re: Treads et parametres des procedures

Publié : mer. 05/mai/2010 16:56
par Geo Trouvpatou
Dobro a écrit :la doc dit :
L'argument '*Valeur' de CreateThread() est passé comme argument de la procédure appelée. Il est très important de ne pas modifier le nombre de paramètre de cette procédure, qui doit toujours rester à 1.
1 d'un point de vue programmation , je ne comprends pas cette limitation...
puisqu'on peut mettre 1 parametre , pourquoi pas plusieurs ??

2 pourra t'on compter voir sauter cette limite ??
je trouve carrément dommage de ne pas pouvoir utiliser une procédure avec autant de paramètres que l'on désire !

bref ça ressemble a du threads au rabais non ? :)
D'après la dernière doc in English, passer plusieurs paramètres dans un Thread c'est possible :

Code : Tout sélectionner

Structure Person
      Name$
      Age.b ; <- Si une personne à plus de 127 ans, on est foutu :)
      Phone$
EndStructure

Procedure Thread(*Parameters.Person)
      
      ; Display the parameters
      ;
      Debug *Parameters\Name$
      Debug *Parameters\Age
      Debug *Parameters\Phone$
      
      MessageRequester("Info", "Nom : "+ *Parameters\Name$ + chr(13)+chr(10) + "Age : "+ str(*Parameters\Age) + chr(13)+chr(10) + "Téléphone : "+ *Parameters\Phone$)
      
      ; Once we don't need them anymore, use ClearStructure() to ensure than every dynamic 
      ; objects (if any) are correctly cleared, and release the dynamic memory block
      ClearStructure(*Parameters, Person)
      FreeMemory(*Parameters)
      
EndProcedure

Procedure Toto(*Parameters.Person, name$, age.i, phone$)
      ; We use a dynamically allocated block, so even if we call it from a procedure, it will
      ; still work. The memory block will be freed by the thread, when 
      ;
      *Parameters.Person = AllocateMemory(SizeOf(Person))
      *Parameters\Name$ = name$
      *Parameters\Age   = age
      *Parameters\Phone$ = phone$
      
      CreateThread(@Thread(), *Parameters) ; Send the thread a pointer to our structure
      
      Delay(4000)
EndProcedure


Define.Person John
Toto(@John, "John", 17, "01-01-01-01-01")

Define.Person Toto_le_haricot
Toto(@Toto_le_haricot, "Toto le haricot", 24, "02-02-02-02-02")
Bye.

Re: Treads et parametres des procedures

Publié : mer. 05/mai/2010 17:23
par Backup
lorsque je demandais a passer plusieurs parametres je parle de pouvoir faire :

Code : Tout sélectionner

CreateThread(@Thread(riri,fifi,loulou,donald,picsou,gontrand_bonheur,Géo_Trouvetou))
en passant par une structure , on ne donne qu'un paramètre ! celui de l'adresse de celle ci ;)

c'est un peu comme si sur la fonction rgb(r,v,b) , on ne puisse pas passer les 3 paramètres;
on a toujours le choix de passer directement la valeur de la couleur a la place de la fonction rgb()

pour éviter la complication, je préfère encore passer par les globals , c'est plus simple

Re: Treads et parametres des procedures

Publié : jeu. 06/mai/2010 15:54
par Geo Trouvpatou
Je comprends mieux ta demande et effectivement cela simplifierait énormément la chose.

Maintenant au passage quand je disais dans mon 1er post : "Voici un code non-fonctionnel", et bien il s'avère qu'il est tout à fait fonctionnel et qu'il ressemble énormément à l'exemple de la doc anglaise (Suis plutôt fier de moi :D ).
Je dirais même qu'il fonctionne mieux, puisque dans mon tout dernier exemple si tu veux incruster ça dans une Dll et j'imagine dans une lib, il faut déclarer la structure dans la Dll et dans le code qui utilise cette Dll.
Alors qu'avec mon 1er exemple, le fait d'avoir Globalisé "VarStructure.sBidon" quand on utilise le code de cette Dll, plus besoin de definir à nouveau la structure à l'extérieur.

Donc à défaut d'avoir ta solution Top-secrète :lol:, si un jour ce type de cas de figure m'arrivait, ben j'opterai pour ma soluce (Zut pas de smiley qui te tire la langue).

Et donc comme toi je dis : "je préfère encore passer par les globals , c'est plus simple"

Bye.