[BIDE] Question con : utilité des call en VBScript

[BIDE] Question con : utilité des call en VBScript - VB/VBA/VBS - Programmation

Marsh Posté le 15-01-2004 à 11:16:10    

en Vbscript (asp) est ce que c utile d'utiliser call pr appelerles procedures ? si oui pourquoi ?


Message édité par Profil supprimé le 15-01-2004 à 12:19:04
Reply

Marsh Posté le 15-01-2004 à 11:16:10   

Reply

Marsh Posté le 15-01-2004 à 12:47:04    

j'ai pas bossé lontemps en VB. Mais sauf erreur c'est lorsque l'on veut appeler dans un event depuis un autre
 

Code :
  1. Button1_Click()
  2. {
  3. // code
  4. }
  5. maFonction()
  6. {
  7. // code
  8. }
  9. Form_load()
  10. {
  11. // appelle de fct
  12. maFonction() ;
  13. // appelle d'event
  14. Call Button1_Click()
  15. }


 
Permet donc de simuler le click sur le button.  
 
A tester toutefois

Reply

Marsh Posté le 15-01-2004 à 13:06:00    

Et sans, ça donne quoi ? Si ça marche, pas besoin...
 
En vieux VBasic 2 et 3, on pouvait faire  
Call Fonct(A%, B$, C& )
ou
Fonct A%, B$, C&
ce qui n'aidait pas la relecture.
 
Up !

Reply

Marsh Posté le 15-01-2004 à 13:23:20    

Voici une utilisation significative de call dans le premier exemple :
http://www.ddj.com/documents/s=150 [...] /jan00.htm

Reply

Marsh Posté le 15-01-2004 à 13:29:21    

carbon_14 a écrit :

Et sans, ça donne quoi ? Si ça marche, pas besoin...
 
En vieux VBasic 2 et 3, on pouvait faire  
Call Fonct(A%, B$, C& )
ou
Fonct A%, B$, C&
ce qui n'aidait pas la relecture.
 
Up !


c'est toujours le cas en VB6 ;)
(et c'est bien chiant d'ailleurs :/²)


---------------
"I wonder if the internal negative pressure in self pumping toothpaste tubes is adjusted for different market altitudes." John Carmack
Reply

Marsh Posté le 15-01-2004 à 13:56:36    

en gros ca sert a rien :D

Reply

Marsh Posté le 15-01-2004 à 14:00:43    

mr_mat a écrit :

en gros ca sert a rien :D

:jap:


---------------
"I wonder if the internal negative pressure in self pumping toothpaste tubes is adjusted for different market altitudes." John Carmack
Reply

Marsh Posté le 15-01-2004 à 14:21:11    

dans mon expérience, l'emploi du Call diminue les possibilités de bugs (faudra surtout que je retrouve un bon exemple [:joce])
 
Je pense qu'on avait eu un problème avec une fonction qu'on appelait sans call (et donc sans parenthèse et sans récupérer la valeur de retour). Le comportement n'était pas normal mais je plus à quel niveau exactement :/


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 15-01-2004 à 18:42:40    

Quand on l'utilise systématiquement, ça permet de savoir que c'est un appel à une Function ou Sub, c'est plus lisible (rigoureux), ça peut aider à faire la "doc" des fonctions utilisées : suffit de chercher tout ce qui suit un "call".

Reply

Marsh Posté le 15-01-2004 à 19:51:33    

Nan mais serieusement, lisez le lien que j'ai indiqué. Dans certains cas, il est possible d'ommetre le Call et ca change fondamentalement le comportement de l'appel au niveau des passages de paramètres par reference.

Reply

Marsh Posté le 15-01-2004 à 19:51:33   

Reply

Marsh Posté le 16-01-2004 à 02:04:36    

yep, et contrairement à drasche, je dirais que l'emploi de Call est source de bugs !
 
Sub testALaCon(a as Integer)
   do while a > 0
      msgbox(a)
      a = a - 1
   loop
End Sub
 
Dim a as Integer
a = 3
 
testALaCon a
MsgBox("Valeur après appel normal : " & a)
call testALaCon(a)
MsgBox("Valeur après appel call : " & a)
 
Et là, on voit que a est modifié lors de l'éxécution avec un call ! Assez moyen non ?
 
Sinon, si mes souvenirs sont bon, Call permet de lancer un appel à une fonction assychrone sans attendre le résultat, mais je suis pas sûr de moi (c'est peut-être plutôt le Call qu'on a avec le langage Batch sous DOS :D)

Reply

Marsh Posté le 16-01-2004 à 09:32:22    

MagicBuzz, tu le fais exprès ou quoi? Ton paramètre est déclaré ByRef là (ça a toujours été comme ça en VB6) donc le comportement est parfaitement logique. C'est dingue comment t'arrive encore à m'épater [:joce] (no offence hein ;))


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 16-01-2004 à 09:35:52    

MagicBuzz a écrit :

yep, et contrairement à drasche, je dirais que l'emploi de Call est source de bugs !
 
Sub testALaCon(a as Integer)
   do while a > 0
      msgbox(a)
      a = a - 1
   loop
End Sub
 
Dim a as Integer
a = 3
 
testALaCon a
MsgBox("Valeur après appel normal : " & a)
call testALaCon(a)
MsgBox("Valeur après appel call : " & a)
 
Et là, on voit que a est modifié lors de l'éxécution avec un call ! Assez moyen non ?
 
Sinon, si mes souvenirs sont bon, Call permet de lancer un appel à une fonction assychrone sans attendre le résultat, mais je suis pas sûr de moi (c'est peut-être plutôt le Call qu'on a avec le langage Batch sous DOS :D)


 
Tu viens de montrer la bonne utilisation des appels de fonction en VB : en appelant depuis un call, c'est normal que le parametre est modifiable car tu n'as rien spécifié et donc le parametre est passé par référence (ByRef).
J'ai lu dans "Hardcore VB", de Microsoft Press de TOUJOURS utiliser les Call, car ca permet d'avoir un code propre et surtout, c'est plus rapide car VB sait directement qu'il s'agit d'un appel vers une sub/function.
 
 
MAJ : erf ! grilled  :p


Message édité par karlkox le 16-01-2004 à 09:36:36
Reply

Marsh Posté le 16-01-2004 à 10:25:37    

drasche a écrit :

MagicBuzz, tu le fais exprès ou quoi? Ton paramètre est déclaré ByRef là (ça a toujours été comme ça en VB6) donc le comportement est parfaitement logique. C'est dingue comment t'arrive encore à m'épater [:joce] (no offence hein ;))


Integer est par défaut byval, relis tes bouquins :p
 
La preuve, l'appel normal, sans call, ne modifie pas la variable (ou alors on n'a vraiment pas les mêmes versions de VB !)

Reply

Marsh Posté le 16-01-2004 à 10:35:42    

je rêve ou quoi? :heink:
 
tout est byref par défaut, ya pas d'exception qui tienne :heink: (sauf celle mentionnée sur la page postée par Kristoph)


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 16-01-2004 à 10:44:23    

Code :
  1. Option Explicit
  2. Public Sub Main()
  3.     Dim b As Byte
  4.     Dim i As Integer
  5.     Dim f As Boolean
  6.     Dim l As Long
  7.     Dim d As Double
  8.     Dim s As Single
  9.     Dim c As Currency
  10.     Dim ch As String
  11.     Dim v As Variant
  12.     Dim dtm As Date
  13.     Debug.Print b, i, f, l, d, s, c, ch, v, dtm
  14.     GetValues b, i, f, l, d, s, c, ch, v, dtm
  15.     Debug.Print b, i, f, l, d, s, c, ch, v, dtm
  16. End Sub
  17. Public Sub GetValues(b As Byte, _
  18.                      i As Integer, _
  19.                      f As Boolean, _
  20.                      l As Long, _
  21.                      d As Double, _
  22.                      s As Single, _
  23.                      c As Currency, _
  24.                      ch As String, _
  25.                      v As Variant, _
  26.                      dtm As Date)
  27.     b = 1
  28.     i = 1
  29.     f = True
  30.     l = 1
  31.     d = 1.1
  32.     s = 1.1
  33.     c = 1.25
  34.     ch = "string"
  35.     v = "blabla"
  36.     dtm = #10/20/1972#
  37. End Sub


 
voilà Magic, essaie ceci avec et sans Call, tu verras que TOUS les types sont modifiés. Purée je me demande même pourquoi je me suis donné la peine de cette démonstration, j'étais sûr de mon fait!  Et ça marche aussi si je déclare GetValues comme une fonction.


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 16-01-2004 à 10:54:13    

:heink: bah y'a un truc qui m'échappe alors :heink:
 
question : et avec une fonction, c'est aussi en byref ? (parcequ'à la base, j'utilise rarement les sub donc c'est possible que je me soit planté, mais je reste sur mon derrière quand même, j'étais sûr de moi)

Reply

Marsh Posté le 16-01-2004 à 10:56:41    

vivivi les fonctions aussi, j'ai essayé les 3 possibilités (bon ici dans mon sample je renvoyais pas de valeur mais j'en ai tapé une pour être complet quoi :o)
 
donc:
FuncName param1, param2
Call FuncName(param1, param2)
Value = FuncName(param1, param2)
 
Le ByRef par défaut est opérationnel dans les 3 cas, tu peux copier/coller mon code dans un projet et essayer :)


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 16-01-2004 à 10:58:33    

faudrait déjà que je sois au boulot :sweat:
 
j'attends un livreur pour me remplacer mon 22" qui a grillé, et il commence à me gonflé ! je bosse à 1h de paris mois, y'en a marre, j'aimerais au moins avoir le temps de bouffer à midi :fou:

Reply

Marsh Posté le 16-01-2004 à 14:01:59    

KarLKoX a écrit :


 
J'ai lu dans "Hardcore VB", de Microsoft Press de TOUJOURS utiliser les Call, car ca permet d'avoir un code propre et surtout, c'est plus rapide car VB sait directement qu'il s'agit d'un appel vers une sub/function.
 


j'ai fait un petit test pour vérifier tes dire, j'ai appelé la fonction suivante 100 000 000 fois:

Code :
  1. Private Sub incremente(ByRef i As Long)
  2.   i = i + 1
  3. End Sub


 
temps d'éxécution lors d'un appel de type "call incremente(i)": 0,94 secondes.
temps d'éxécution lors d'un appel de type "incremente i": 1,12 secondes.
 
le gain n'est franchement pas énorme quand on sait que mon programme de test passe son temps à appeler une fonction.
 
 
P.S. à noter que "incremente (i)" ne fonctionne pas.
 
 
EDIT: finalement après avoir refait les tests plusieurs fois, il semblerait que cette différence viennent plutot des aléas des tests. Après avoir fermé tout ce qui bouffait du CPU, j'arrive à des temps égaux pour les 2


Message édité par mareek le 16-01-2004 à 14:15:25

---------------
"I wonder if the internal negative pressure in self pumping toothpaste tubes is adjusted for different market altitudes." John Carmack
Reply

Marsh Posté le 16-01-2004 à 14:13:25    

Je vois le genre, c'est peut-être ce qui a induit MagicBuzz en erreur: une fonction appelée avec parenthèses et un seul paramètre, là effectivement, ça se passe comme du ByVal.
 
Edit: testé et approuvé.  C'est nul de leur part quand même [:kiki]


Message édité par drasche le 16-01-2004 à 14:13:50

---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 16-01-2004 à 14:16:31    

drasche a écrit :

Je vois le genre, c'est peut-être ce qui a induit MagicBuzz en erreur: une fonction appelée avec parenthèses et un seul paramètre, là effectivement, ça se passe comme du ByVal.
 
Edit: testé et approuvé.  C'est nul de leur part quand même [:kiki]


Ben les parenthèse sont en fait un opérateur qui renvoit la valeur de ce q'ui y a entre parenthèse donc cette erreur s'explique [:spamafote]
 
EDIT: faudrait tester avec un objet


Message édité par mareek le 16-01-2004 à 14:16:45

---------------
"I wonder if the internal negative pressure in self pumping toothpaste tubes is adjusted for different market altitudes." John Carmack
Reply

Marsh Posté le 16-01-2004 à 14:28:20    

j'ai testé en effet:
 

Code :
  1. Private Sub Inc(ByRef x As Long, ByRef y As Long)
  2.     x = x + 1
  3.     y = y + 1
  4. End Sub


 
pis ceci:
 

Code :
  1. Call Inc(x, y) ' les deux sont retournés incrémentés
  2. Inc x, y ' idem que ligne précédente
  3. Inc (x, y) ' Erreur de syntaxe, c'est mal
  4. Inc x, (y) ' x sera retourné incrémenté, mais pas y qui est passé par valeur grâce à l'astuce des parenthèses (il s'agit donc d'un override)


 
j'ai demandé à un collègue qui a un peu plus d'expérience que moi et qui m'a confirmé tout ça.


Message édité par drasche le 16-01-2004 à 14:28:52

---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 16-01-2004 à 14:44:16    

Faut dire surtout que souvent je passe des fonctions, ou alors des constantes à mes requêtes donc à partir de là :D

Reply

Marsh Posté le 16-01-2004 à 14:48:34    

'fin maintenant je sais pourquoi un appel sans Call avec un seul paramètre passe à la compile et pas plusieurs paramètres :whistle:


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 16-01-2004 à 14:52:53    

mareek a écrit :

EDIT: faudrait tester avec un objet


j'ai testé: runtime error (object doesn't support this property or method)
 
je m'en doutais un peu [:joce]


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 16-01-2004 à 15:36:59    

donc call sapuduku :D
 
moi je préfère les syntaxes génériques, au moins on peut pas se planter :D

Reply

Marsh Posté le 16-01-2004 à 15:42:23    

sinon, en parlant des objets et tout ça, je pense à un truc qui peut être très pratique, mais aussi dangereux si on fait pas gaffe.
 
Quand on bosse avec des rs ADO en VB, on fait généralement :
 


Dim nom
Dim prenom
Dim rs
 
set rs = CreateObject("ADODB.RecordSet" )
set rs.ActiveConnection = cnx
 
rs.Open("select nom, prenom from user" )
 
do while not rs.EOF
   nom = rs("nom" )
   prenom = rs("prenom" )
   Label1.Text = Label1.Text & "Nom: " & nom & " - Prenom : " & prenom & vbCrLf
   rs.MoveNext
loop
 
rs.Close
set rs = Nothing


 
Ceci marche aussi !!! C'est un peu magique, et plus lisible... Par contre faut faire gaffe parceque c'est pas du tout le même fonctionnement que l'autre :
 


Dim nom
Dim prenom
Dim rs
 
set rs = CreateObject("ADODB.RecordSet" )
set rs.ActiveConnection = cnx
 
rs.Open("select nom, prenom from user" )
set nom = rs("nom" )
set prenom = rs("prenom" )
 
do while not rs.EOF
   Label1.Text = Label1.Text & "Nom: " & nom & " - Prenom : " & prenom & vbCrLf
   rs.MoveNext
loop
 
rs.Close
set rs = Nothing


 
Vive la gestion bordelique des objets avec une default value, et la gestion des byref et byval implicites :D
 
 
PS: oui, je sais, ça n'a aucun rapport avec le sujet initial, c'était juste pour parler du joyeux bordel de la syntaxe de VB :)


Message édité par MagicBuzz le 16-01-2004 à 15:48:35
Reply

Marsh Posté le 16-01-2004 à 15:49:54    

En parlant du joyeux bordel, on voit que les méthodes des objets, même quand elles sont de type "sub", acceptent les () lors de l'appel, alors que c'est impossible pour une sub normale :D

Reply

Marsh Posté le 16-01-2004 à 16:03:49    

MagicBuzz a écrit :

donc call sapuduku :D
 
moi je préfère les syntaxes génériques, au moins on peut pas se planter :D


bin non :o
 
d'ailleurs on peut utiliser la même astuce avec un call:
 

Code :
  1. Call Inc((i))


 
"i" sera passé ByVal quoi q'il arrive avec cette méthode.
 
 
J'ai bien noté pour ta démo. Le premier exemple prend les valeurs à chaque itération et le second prend directement les objets avant l'itération (plus qu'à lire la valeur). Perso j'aime pas trop exploiter les propriétés par défaut, je préfère tout mettre explicitement (VB passe du temps à savoir quelle propriété il doit sortir quand tu ne le fais pas toi-même)
 
J'ai pas compris ta dernière phrase par contre :??:


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 16-01-2004 à 19:28:48    

MagicBuzz a écrit :

sinon, en parlant des objets et tout ça, je pense à un truc qui peut être très pratique, mais aussi dangereux si on fait pas gaffe.
 
Quand on bosse avec des rs ADO en VB, on fait généralement :
 


Dim nom
Dim prenom
Dim rs
 
set rs = CreateObject("ADODB.RecordSet" )
set rs.ActiveConnection = cnx
 
rs.Open("select nom, prenom from user" )
 
do while not rs.EOF
   nom = rs("nom" )
   prenom = rs("prenom" )
   Label1.Text = Label1.Text & "Nom: " & nom & " - Prenom : " & prenom & vbCrLf
   rs.MoveNext
loop
 
rs.Close
set rs = Nothing


 
Ceci marche aussi !!! C'est un peu magique, et plus lisible... Par contre faut faire gaffe parceque c'est pas du tout le même fonctionnement que l'autre :
 


Dim nom
Dim prenom
Dim rs
 
set rs = CreateObject("ADODB.RecordSet" )
set rs.ActiveConnection = cnx
 
rs.Open("select nom, prenom from user" )
set nom = rs("nom" )
set prenom = rs("prenom" )
 
do while not rs.EOF
   Label1.Text = Label1.Text & "Nom: " & nom & " - Prenom : " & prenom & vbCrLf
   rs.MoveNext
loop
 
rs.Close
set rs = Nothing


 
Vive la gestion bordelique des objets avec une default value, et la gestion des byref et byval implicites :D
 
 
PS: oui, je sais, ça n'a aucun rapport avec le sujet initial, c'était juste pour parler du joyeux bordel de la syntaxe de VB :)


Tu ne types pas tes variables et après tu t'étonne que ce soit le bordel :pfff:


---------------
"I wonder if the internal negative pressure in self pumping toothpaste tubes is adjusted for different market altitudes." John Carmack
Reply

Marsh Posté le 16-01-2004 à 19:38:01    

bin et s'il teste en ASP ou en VBScript? [:spasafote]


Message édité par drasche le 16-01-2004 à 19:38:17

---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 16-01-2004 à 20:17:17    

drasche a écrit :


bin non :o
 
d'ailleurs on peut utiliser la même astuce avec un call:
 

Code :
  1. Call Inc((i))


 
"i" sera passé ByVal quoi q'il arrive avec cette méthode.
 
 
J'ai bien noté pour ta démo. Le premier exemple prend les valeurs à chaque itération et le second prend directement les objets avant l'itération (plus qu'à lire la valeur). Perso j'aime pas trop exploiter les propriétés par défaut, je préfère tout mettre explicitement (VB passe du temps à savoir quelle propriété il doit sortir quand tu ne le fais pas toi-même)
 
J'ai pas compris ta dernière phrase par contre :??:


Bah simplement le fait que met "set" devant une affectation, quand il s'agit d'un objet avec une valeur par défaut, fait se comporter l'appli différement, sans pour autant faire le moindre warning.
Cette solution est en elle-même intéressante, mais je trouve que faire un peu plus de différence entre les deux syntaxe n'aurait pas été du luxe, car là on peut se retrouver avec un comportement "anormal" et avoir un mal de chien à trouver pourquoi. Je sais pas si d'autres langages permettent de faire ça aussi "implicitement". En C par exemple, à partir du moment où tu bosse par référence (donc pointeur) la façon de récupérer les informations contenues dans le pointeur demande un syntaxe bien spécifique, on trouve tout de suite l'erreur. Alors que là bah nan :)
 
En fait, mes exemple sont mauvais. Prends la seconde syntaxe, et vire les "set".
 
Ca va très bien marcher, sauf qu'il va t'afficher les première valeurs autant de fois qu'il y a de lignes dans le rs. On peut y passer des heures avant de s'appercevoir qu'on a oublié le mot clé "set".

Reply

Marsh Posté le 16-01-2004 à 20:18:12    

drasche a écrit :

bin et s'il teste en ASP ou en VBScript? [:spasafote]


Yep, je fais très rarement du VB, pratiquement que de l'ASP, langage dans lequel si on type les valeurs, on a une erreur d'interprétation [:spamafote]

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed