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

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

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

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 !

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

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

en gros ca sert a rien

dans mon expérience, l'emploi du Call diminue les possibilités de bugs (faudra surtout que je retrouve un bon exemple )
 
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

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".

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.

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 )

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 (no offence hein )

 
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  

Integer est par défaut byval, relis tes bouquins
 
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 !)

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

 
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.

bah y'a un truc qui m'échappe alors
 
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)

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 )
 
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

faudrait déjà que je sois au boulot
 
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

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

 
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

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

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
 
EDIT: faudrait tester avec un objet

j'ai testé en effet:
 

 
pis ceci:
 

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

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

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

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

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

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 :
 

 
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 :
 

 
Vive la gestion bordelique des objets avec une default value, et la gestion des byref et byval implicites
 
 
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

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

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

 
"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

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

bin et s'il teste en ASP ou en VBScript?

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".

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