Erreur de compilation - Incompatibilité de type - Variable Public as Byte

Bonjour,

Un module ne peut pas se compiler à cause d'une incompatibilité de type.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Sub Compare() Application.ScreenUpdating = False Dim i As Byte Dim chem As String Select Case MsgBox("Choisissez le même fichier, mais du mois précédent.") Case vbOK Set rep = Application.FileDialog(msoFileDialogFilePicker) Case vbCancel Exit Sub End Select rep.Show If rep.SelectedItems.Count > 0 Then chem = rep.SelectedItems(1) Nfichier = "" 'Work in progress Else Exit Sub End If For f = 1 To Sheets.Count With Sheets(f) For i = 9 To Cells(Columns(1).Rows.Count, 2).End(xlUp).row .Cells(i, "H").FormulaR1C1 = "=RC[-5]-'[" _ & Nfichier & "]" _ & .Name & "'!RC3" Next End With Next f End Sub

---

C'est la variable "f" soulignée en gras qui pose problème.
Elle est déclarée de cette façon dans un module à part:

Code:

---

Public f As Byte

---

Ce qui est étrange, c'est que j'utilise "f" dans d'autres modules dans une instruction For...Next et il n'y a pas de problème.

Cordialement

Bonjour

Tu as combien de feuilles dans ton classeur ?

Philippe

Citation:

---

Envoyé par Philippe JOCHMANS

Tu as combien de feuilles dans ton classeur ?

---

Oui, j'aurais dû le préciser. Une dizaine, donc moins de 255.

J'en profite pour ajouter que si je (re)déclare "f" en début de procédure:

Code:

---

Dim f as Byte

---

il n'y a alors plus de problème de compilation... 8O

Bonjour
Si tu as bien déclaré la variable f en public dans un module standard, il n'y a selon moir qu'une explication plausible : un conflit de nom identiques pour deux choses distinctes.
Cherche partout dans ton projet (edition --->> rechercher) où tu as "f =" ou "f as" et regarde s'il s'agit toujours de la même chose.

Citation:

---

Envoyé par unparia

Bonjour
Si tu as bien déclaré la variable f en public dans un module standard, il n'y a selon moir qu'une explication plausible : un conflit de nom identiques pour deux choses distinctes.
Cherche partout dans ton projet (edition --->> rechercher) où tu as "f =" ou "f as" et regarde s'il s'agit toujours de la même chose.

---

Bravo unparia! Ton intuition était la bonne!

J'avais:

Code:

---

Private f As Worksheet

---

en début de module.

Merci pour votre aide!

Citation:

---

Bravo unparia! Ton intuition était la bonne!

---

Ce n'était pas une "intuition", à proprement parler :D

Pourquoi s'em...bêter à mettre le type Byte pour une variable qui est un entier classique ?
Il y a 30 ans, on pouvait comprendre que, la taille mémoire posant problème, on dimensionnait au mieux. Mais aujourd'hui où la mémoire se compte en Go, gagner un byte en évitant le type Integer sur UNE variable, c'est un peu ridicule. :mrgreen: (excepté si on traite effectivement un byte, comme par exemple pour une des trois composantes d'une couleur).
Perso, j'ai même abandonné le type Integer pour passer en Long, ce qui m'évite bien souvent du temps perdu à chercher un bug de dépassement de capacité.

Citation:

---

Envoyé par Menhir

Pourquoi s'em...bêter à mettre le type Byte pour une variable qui est un entier classique ?
Il y a 30 ans, on pouvait comprendre que, la taille mémoire posant problème, on dimensionnait au mieux. Mais aujourd'hui où la mémoire se compte en Go, gagner un byte en évitant le type Integer sur UNE variable, c'est un peu ridicule. :mrgreen: (excepté si on traite effectivement un byte, comme par exemple pour une des trois composantes d'une couleur).
Perso, j'ai même abandonné le type Integer pour passer en Long, ce qui m'évite bien souvent du temps perdu à chercher un bug de dépassement de capacité.

---

J'avoue que ça dépasse un peu mes compétences.

J'ai pris l'habitude de déclarer mes variables avec le plus petit type nécessaire parce qu'il m'a semblé comprendre que c'était une bonne pratique et qu'avec de longues procédures, ça pouvait faire gagner un peu de temps. Certaines de mes macros prennent quelques minutes à s'exécuter. Donc, je me dis, autant faire ce peu. Surtout que ce n'est pas un gros effort.

Cordialement

Je ne suis pas sûr qu'entre byte et integer il y ait un réel gain de temps.
Par contre, utiliser byte dans un cadre qui n'est pas celui pour lequel il a été prévu (définir la valeur d'un octet) peut entrainer des problèmes inutiles sans commune mesure avec un hypothétique gain de temps ou de mémoire.

C'est une pratique qui peut être intéressante dans le cas où on manipules des centaines de milliers de valeurs (ce qui est rare en VBA).
C'est aussi une pratique héritée de temps héroïques où la RAM se comptait en ko et où on cherchait à économiser le moindre bit, mais pour les PC modernes avec des RAM un million de fois plus grandes, c'est une pratique obsolète.

Intéressant.

Citation:

---

Envoyé par Menhir

Par contre, utiliser byte dans un cadre qui n'est pas celui pour lequel il a été prévu (définir la valeur d'un octet) peut entrainer des problèmes inutiles sans commune mesure avec un hypothétique gain de temps ou de mémoire.

---

Juste par curiosité, quel genre de problème pourrait se produire?

Cordialement

Dépasser la limite imposée par ce type (255).

J'ai eu le cas une fois avec un Integer.
Un tableau qui ne devait pas dépasser une centaine de ligne et dont chaque ligne était numérotée de 100 en 100.
Un jour un utilisateur m'appelle en me disant que la macro bug.
Une heure avant de comprendre que l'utilisateur avait eu la bonne idée de compiler plusieurs tableaux pour les traiter ensemble et donc que ça dépassait la limite de 32000 et des poussières de la variable Integer que j'utilisais pour la numérotation.
Et là, tu as vraiment envie de te mettre des coups pieds au cul si tu en avait physiologiquement la possibilité. :mur:

Depuis, j'ai abandonné Integer pour passer à Long systématiquement pour les entiers (en plus, c'est plus court à écrire) et je n'ai jamais eu à m'en plaindre.
Quant à Byte, je n'y songerais même pas, sauf, comme je le disais, dans le domaine très précis pour lequel il est adapté : valeur d'un octet.