exemple :
 
Dim Tab(7) as Integer
 
[...]
 
truc = UneFonction (Tab)
 
_____________________________________________
Function UneFonction (MonTableau(7) as integer)
[...]
End Function
_____________________________________________
 
Les parties en gras sont celles qui me dérangent, qu'est-ce que je dois mettre à la place pour que ça marche ?

avec dim ca passerai peut être ?

dsl pour le double topic : un modo a déplacé un ancien topic mal placé

ptain chuis fatigué moi je tape n'imp
 
je voulai dire avec ()  
montableau() as type
 
enfin je dis ca mais j'en sais rien j'ai fait très peu de vb mais bon y a des langages ou ca marcherai quoi

bon en fait j'ai réussi à feinter pour pas avoir à passer ce tableau en paramètres ...

arrête de feinter, et utilise mon code, il marche très bien, et il fait ce que tu veux.

lol non c bon merci

g lu le truc de magicbuzz en gros c comme je disasi c juste que qd tu declare ta fonc au lieu de mettre montableau(7) tu met montableau() et ca passe il retrouve la taille tout seul il est intelligent vb

+1 avec mr_mat

(qu'est-ce qu'il faut pas lire)
 
 
sinon, +1 avec tout le monde

bah sinon tu passes les paramètres en variant et c'est bon...

ou comment être sûr de ne pas se casser la tête, voilà bien une réflexion typique de pur programmeur VB

drasche > fait pas ta timorée. je te rappelle qu'en C tu passerait un pointeur à la place et zou

en C je programmerais pas de la même façon qu'en VB, je me suis ramolli avec le temps

 
Tu sais quoi j'aime pas ce langage et pourtant j'en bouffe toute la journée au taf. Bah je vais te dire un truc , que ce soit propre ou pas , c'est plus simple de laisser le type en variant.

je prends la chose autrement, j'aime pas VB non plus et j'essaie d'optimiser autant que je peux pour diminuer la sensation de lenteur, alors j'emploie le variant le moins possible

Je comprend ton point de vue...en même temps, je ne vois pas pourquoi utiliser les variant "ralentit" l'appli...que ça la rende plus lourde ok mais sinon je vois pas...quoiqu'il en soit quand t'as une interface graphique bien lourde, je suis pas sur que la taille des objets en mémoire ait un gros impact sur la vitesse d'éxécution...

Le Variant influe sur la vitesse en ce sens que VB doit déterminer son type sous-jacent avant de bosser avec. Il y a plein de petits trucs comme ça en VB. Et il se peut qu'il doive le faire à chaque référence à un Variant vu que son contenu peut changer de type d'une ligne à l'autre.
 
Dans le même genre, t'as les propriétés par défaut dans les objets: VB doit déterminer lequel il s'agit avant de s'en servir. Moralité: je n'utilise jamais ce genre d'écriture.
 
Les objets dans les collections: à chaque fois que tu établis une référence, VB doit calculer la référence en question (donc le retrouver dans la collection), et ça aussi il le fait à chaque fois que tu y accèdes, il n'a pas une cache quelconque pour s'en rappeler. VB est un langage très simple mais aussi très primaire. J'ai pu vérifier tout cela en utilisant un profiler (TrueTime pour ne pas le citer). Les résultats sont édifiants.

Oki, je pensais que le type était déterminé à la compilation.
C'est sûr VB est primaire...c'est d'ailleurs pour ça que je n'ai même plus envie de me prendre la tête avec, donc je vais au plus simple même si c'est laid. Je me force quand même à laisser option explicit

Franchement, la vitesse n'est pas le point noir.
 
Pensez un peu au gars qui va passer derrière vous pour la maintenance ! Si c'est tout en Variant, on sait plus qui fait quoi, ce que doivent contenir les données, et dès qu'on touche à une ligne, toujours à cause du type Variant, au lieu de planter tout de suite, ça se met à péter à l'aute bout du programme, sans raison apparente. Du coup on passe des heures à chercher les effets de bords possible de la modif, alors qu'on a bêtement provoqué un problème de typage, mais vu qu'on a recopié la variable globale dans 25 autres variables variant globales aussi, ça pête sur une autre variable, dans un autre module, et c'est impossible de retrouver d'où ça vient.
 
Alors que quand c'est typé, à la première affectation, programme propre ou pas, VB va gueuler, on pourras alors débugger tout de suite.
 
Franchement, je le répète. VB est loin d'être un langage parfait, mais il est clairement mieu foutu que l'utilisation qu'en font certains. Un programme bien écrit en VB sera à la fois performant, stable et maintenable. J'ai des dizaines de progs à mon actif, donc certains ont subis de grosses évolutions. J'ai été surpris de relire les commentaires dans l'ent-tête :
- 1999-05-23 : First Release
- 1999-05-29 : Fix some bugs after customer feedback
- 2004-01-18 : New features
 
Voilà. Quand c'est développé proprement, un programme VB ne plante pas, et convient parfaitement à l'utilisation qu'on en fait.
Comme par enchantement, dans ce prog, y'a rigoureusement aucun type Variant, aucune conversion implicite, aucun "on error resume next" posé comme un con sans jamais être fermé ni trappé.
 
Alors après, si vous foutez un "on error resume next" à la première ligne du programme et que vous bosser avec des variant, faut pas vous étonner si le programme fait rigoureusement n'importe quoi (le plus marrant avec on error resume next en scope global, c'est qu'en plus ça va jamais planter, juste faire n'importe quoi ! trop fort non ? Vous devriez essayer, c'est génial à débugger après)

Attention, j'ai pas dit que je passais les integer en variant non plus...

je parle des effets de bord de casting implicite dans la FAQ VB

 
Ce qui plombe le plus VB, c'est l'illusion de simplicité.  
 
Si on fait un travail rigoureux et qu'on connait bien l'IDE, ses possibilités et ses limites, il n'y a pas de raison qu'un programme enVB soit pire qu'un programme identique dans un autre langage (dans le cas général). Mais comme VB est censé s'adresser aux débutants, il y a plein de fausses facilités (on error resume next, les variant, les méthodes par défaut, la non obligation de déclarer ses variables, etc...) qui amène des bugs hyper durs à trouver et plombent les perfs comme c'est pas permis.
 
J'en viens à la conclusion que pour faire des trucs un peu évolués, il faut beaucoup mieux maitriser son environement de developpement en VB que dans d'autres langages présentés comme plus compliqués.

exemple de casting implicite foireux
 

 
ah oui ça a l'air tout simple, et pourtant ça plante, c'est con hein?

 
Ce qui le plombe c'est aussi pas mal de trucs pas très logiques et qui donnent l'impression que les mecs avaient pas vraiment de suite dans les idées quand il ont commencé à créer le langage...Biensur on peut toujours faire un truc stable mais bon même pour faire des trucs tout con on peut perdre pas mal de temps si on a pas 6 mois d'xp.
 
drasche > oué effectivement c'est assez con...c'est vraiment tout le problème de VB, il a tellement été simplifié qu'on en arrive à des conneries comme ça...c'ets un peu dommage quand même

ça vous apprendra à pas travailler avec des constantes
 
pour info, c'est grace à des 68742 / (3600 * 24) qu'on a eu droit au problème de l'an 2000 et au problème du passage à l'euro.
je vous racontre pas non plus le bordel que c'est quand on change le taux de la TVA...
 
une constante, ça se type et ça se déclare dans le header du programme. après on l'appelle par son non, jamais directement sa valeur

en fait j'ai montré cet exemple parce que je suis tombé dessus un jour dans le code, je sais plus pourquoi, et j'ai noté le type des variables: un long et deux integers. Un peu plus tard, on a tout converti en longs, plus d'integer dans le code sauf dans le cas de certaines contraintes.

au taf c'est encore mieu, l'ERP aime pas les nombres, alors il fait tout en varchar2 (string).
comme ça, pas de problème de transtypage, faut tout le temps se palucher un transtypage à la main pour pouvoir faire un calcul
 
vi, je sais, c'est des mabouls ceux qu'on fait l'ERP

on se croirait revenu à dBase
 
Vous savez tout le bien que je pense des ERP toute façon

on est deux
 
par contre, c'est une mine d'or quand tu bosses avec la base, y'a trop plein d'astuces vraiment intéressantes pour rendre générique et évolutif un MPD... c'est un peu le gros bordel au début, mais ensuite c'est trop bon !

Moi aussi j'ai une super astuce pour rendre un MPD générique et évolutif: Une table avec un champ de type blob
 
(je rigole mais les ERP c'est un peu ça quand même )

Nan, une table "tbl" avec 20 champs de chaque type
 
Et pasde clé primaire, pas de contrainte ni rien.
 
Juste un champ "TBLCOD"
 
Comme ça tu crées autant de "tables" que tu veux à l'intérieur de cette dernière, et tu filtres par le champ "TBLCOD" pour retrouver les infos de ta "table".
 
Ca c'est du 100% hardcore
 
Mais mine de rien, utilisé à bon escient, ça permet de mettre en place des mécanismes avancés qui ont par contre de très gros avantages...

ça revient à  ce que je disais, tu perds 90% des avantages d'une BD

Ca peut dépendre des cas. Perso, j'utilise très souvent cette astuce maintenant pour gérer ce qui s'appelle des "descripteurs".
 
Evidement, l'implémentation est moins merdique, mais globalement ça revient au même :
-> Ajout de nouvelles dimensions sans modification de la base de données.
 
Par exemple, t'as un catalogue de produits.
Tu vends des stylos et des chaises.
 
Bah... Dans les deux cas, t'as des attributs :
- couleur
- prix
- matière
 
Mais avec un stylo, tu as en plus :
- type (bille, feutre, plume)
- km d'écriture
- foureau
- etc.
 
Et avec une chaîse :
- pieds
- revêtement
- inclinable
- pivotable
- réglable en hauteur
- roulettes
- etc.
 
Bah...
- soit tu crées 10 000 champs dans ta table sâchant que chaque produit en utilisera une 10aine à chaque fois...
- tu fais des champs génériques merdiques qui font que tu pourrais être amené à comparer le revêtement de la chaîse avec la couleur d'un foureau de stylo, source de problèmes...
- Tu utilises le système de descriptueur qui va stocker les infos requises et uniquement celles-ci pour chaque ligne de façon indépendante. Ainsi t'as un modèle qui reste lisible, et des données qui sont cohérentes, juste un peu plus lourdes à gérer.