en vb y a pas moyen de faire exectuer les tests separement car remplacer ca :

(il provoque une erreur parce qu'il est a la fin du fichier et que me! n'existe pas qd c a la fin du fichier)
 
par ca ca marche pas:

si je n'mabuse en C/C++ ca aurais marché car il test pas le 2eme membre du WHILE lorsque la condiion du 1er membre est fausse.
 
comprendo les monsieurs ? le C c bien  

C'est une énormité qu'en c/c++ ça passe (je doute que tous les compilos laissent passer...)
 
En algèbre, sorti de la priorité des opérateurs, il n'y a pas d'ordre pour faire les calculs.
 
L'algèbre de bool, comme son nom l'indique, n'est ni plus ni moins que de l'algèbre, donc les mêmes pricinpes s'appliquent.
 
Il est donc impossible de savoir dans quel ordre le compilo va décider de faire les tests... Ce type de bidouilles est donc à bannir. (perso, je casse les dents de tous mes collègues qui pondent ces horreurs)
 
Tu testes si eof dans le while, et dans un if à l'intérieur, tu fait un exit while en fonction de ton code, voilà tout.
 
C'est non seulement plus lisible, mais en plus c'est aussi rapide et tu ne peux en aucun cas planter.

Et tu as quoi comme erreur ?

EOF or BOF is true je suppose

 
en C, C++ et Delphi (et probablement d'autres) il est prévu dans la norme qu'on n'évalue que ce qui est nécessaire, de gauche à droite.
Je fais souvent des trucs du genre :
if (Item <> nil) and (Item.Selected) then ...
je vois pas où est le problème

Bah c'est dégueux, à moins que ce que tu entendes par "norme" soit le cahier des charges du C. Dans ce cas, à la limite je dis pas... M'enfin ça n'en reste pas moins illisible, et niveau "propreté" ça passe par la norme ISO par exemple, car on mélange les poules et les cochons au niveau des tests, un EOF est bien plus grave (et surtout bloquant) qu'une égalité entre deux variables, donc nécessitement doit être traîté à part, surtout si le fait que ce dernier soit à vrai met en préile les autres instructions de la même ligne.
 
 
PS: Et pour la petite histoire, en ASP ça marche justement, de gauche à droite. Seulement, voilà le meilleur exemple prouvant qu'un code à la con n'est pas portable. Mes pages ASP ou mes programmes VB, j'ai pas une ligne à changer si je les passe de l'un à l'autre. Donc les bidouilles de "ouais, je déclare ma classe, mon objet et mes réservations mémoire dans une ligne et je plante je sais pas pourquoi"

Je vois pas ce que ça a de dégueux
ça évite de faire plein de if en cascade

Parceque au bout de 10 minutes, tu fais ça :
 
"ouais, je déclare ma classe, mon objet et mes réservations mémoire dans une ligne et je plante je sais pas pourquoi"
 
J'en vois pas trop l'intérêt

Je vois pas trop le rapport

Deplus, il me semble bien que c'est ISO, c'est pour ça que je l'ai cité, distingue vraiment ce genre de tests.
 
Un EOF, ça indique une ERREUR (qui c'est déjà produite, mais trappée par la fonction appelée, dans notre cas un movenext).
Deplus, une fois un objet à EOF, on ne peux plus lire dedans sous peine d'erreur bloquante (plantage)
 
Ca mérite donc un traîtement immédiat.
 
Un test d'égalité pour voir si le chien à bien bouffé sa pâté, ça ne résulte pas d'une erreur, les données vont pas se sauver toutes seules, donc c'est un traîtement qui doit être fait APRES les tests précédents.
 
Et APRES ça veut pas dire "un opérateur plus loin", mais bel et bien séparré par un saut de ligne (';' dans le cas du C)
 
Un programme qui ne respecte pas ces notions ne passe pas une certification ISO je sais pas combien.
 
Votre truc, c'est un peu comme regarder sa montre pour voir si c'est l'heure du thé alors qu'on est en chutte libre du haut d'une falaise. Le premier truc à faire, c'est ouvrir un parachute si on en a un, ou alors crier comme un tarré même si ça sert à rien Si vous vous en sortez pas, vous vous en foutez que ce soit l'heure de bouffer un croissant.

je peux pas affirmer que tous les compilos vont laisser passer ce genre de truc mais dans le bouquin de C que j'avais (me rappelle plus du titre et l'auteur je croit que c le createur mais chu pas sur) il y avais ces priorité de defini
C vraiment tres pratique pour pas faire de debordement, qd tu connais ces regles. Et normalement c pas du au piff.
Par contre c sur que nivo esthetique c pas top koi que...
Coté algebre de bool et comparaison de carotte et de patate je partage ton avis magicbuzz
*Pour l'erreur qu'il me sortais : il me disais qu'il connaissais pas me![toto]; pas de valeur ou non definie me![toto] un truc du genre. Ca faisais juste un message d'erreur pas de plantage mais par exemple en C mal ecrit seg fault koi  
Sinon j'ai ecrit ca :

voyez vous une autre solution plus rapide ?
 

un exemple, en ada.
 
 
if (truc = 1 and toto = null) {
 
}
 
ceci evalue les 2.
 
 
if ( truc = 1 and then toto = null ) {
 
}
ceci evalue toto = null uniquement si truc = 1 est vérifiée.

Je comprends pas trop ce que c'est censé faire
 
Je verrais plutôt :
 

 
Sinon, ton erreur est chelou si c'est à propos du Me![code]
T sûr de ta syntaxe ? je ne connais pas cette syntaxe donc je peux pas dire

Sinon, solution bourrin (c'est ce que je fais en C, et qui, alors que ça semble crade, est très propre, c'est notamment untilisé par IBM dans leurs devs (le "if" est interdit chez eux, les seuls tests qui existent dans leur code, c'est pour l'analyse des exceptions )) bien plus rapide :
 

 
La ça booste à fond, mais c'est pas compréhensible du tout

euh ok skylight ca marche dans les while cette histoire la ?ca c cool c en gros ce que je voulais
magicbuzz> je suis sur de ma syntaxe et c sur que c parce qu'il evalue le 2eme membre que ca chiais
Par contre pour ton truc je suis ok mais exit loop
  ARF C HORRIBLE enfin si mes profs avais vu ca
 
d'expliquer ce que c censé faire ^^

oui ce que j'ai écrit marche dans n'importe quel test, en langage ADA.

 
J'aime bien les exemples bidons

benh perso j'ai compris mais pour moi ca semble archi crade.
Enfin bon c les profs aussi qui veulent pas de goto

j'ai jamais compris pourquoi les profs veulent pas de goto.
 
ok au niveau de l'assembleur ca rajoute des BRA ...
 
 
mais il suffit de ne pas en abuser, moi je trouve que c'est plus propre que d'imbriquer des tests / boucles

c comment alors ?

ca c'est pas de l'ada ...
 
les boucles en ada :  
 
while (truc = true and then toto = null ) loop
 
 blabla;
 
end loop;

benh ca ressemble a un paquet de noeud qd t'as des goto de goto de goto
Pour une trace c de la merde plus courrament appeller trace de merde

c'est ce que je dis ...
2 ou 3 max dans un programme ok, mais en abuser, clairement non

coné pas l'ada c koi ? les initial ?
ca veux dire koi plz ?

c'est un langa de programmation différent de visual basic
 
 
ADA, c'est simplement le prénom de la femme qui a créé ce langage

ok

La contesse vient de faire 25 tours dans sa tombe !
 
Elle est morte bien avant que le premier ordinateur existe !
 
Non, par contre, elle assistait son mari qui travaillait sur un des tous premiers automates (à l'époque, en bois, et 100% mécanique) et a travaillé sur les tous premiers algos. En effet, la machine de son mari était le premier automate capable de changer de changer de fonctionnement en fonction de leviers un peu partout. Donc elle est s'est collée à faire des "programmes" pour cet automate. Mais ça n'a rien à voir avec le langage lui-même.

T'a déjà essayé la prog windows en C???

bon ça a bien tourné en couille je trouve ce topic
 
Trancy> si tu passais le nécessaire à une fonction qui ferait le travail et renverrait un booléen en conséquence?
 
MagicBuzz> le EOF n'est pas une erreur.  JAMAIS.  De notre point de vue de développeur, c'est un flag qui indique si on est à la fin du fichier, point final.  Ce sont les fields qui sont en état d'erreur, mais jamais un flag EOF ou BOF.
 
Trancy> pour relier avec les posts précédents, sache que ton même code en C++ aurait planté également: tu ne testes pas EOF en premier.  Si ça plante, c'est simplement parce que quand EOF est à True, ton expression test.Fields("Code" ) est en état d'erreur, c'est aussi simple que ça.  Il faut malheureusement éviter ce genre de gymnastique en VB.  Donc je suggère que tu passes Me et test à une fonction qui fera le test proprement et te renverra un booléen pour indiquer la réussite ou l'échec de la comparaison (sachant que si test.EOF est à True, il n'est nul besoin d'aller plus loin).