Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Applications Microsoft Office Excel detecter si un tableau est vide

detecter si un tableau est vide

33 réponses
Avatar
Emcy
bonjour,

existe t-il un moyen de voir si une variable tableau (vba) est vide sans
utiliser les OnError ?
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4
Avatar
Emcy
... c'est pas bete
je pense que je vais faire un truc du genre

Sub Main
Call RemplirListBox(Me.ListBox1, MonTableau)
End Sub

Sub RemplirListBox(ObjetListBox As ListBox, Tableau() As String)
.... 'controle d'erreur
ObjetListBox.List = Tableau
End Sub

"Daniel" a écrit dans le message de news:
uM1Es4$$
Euh, je suis pas sûr, mais, si tu transformes ta fonction en macro
appelée, tu peux peut-être, dans cette dernière tester avant d'essayer
d'alimenter ta listbox ?
Daniel
"Emcy" a écrit dans le message de news:
uLkhXy$$
je veux que ma listbox soit vide (comme le resultat de la fonction) ...

"Daniel" a écrit dans le message de news:
uEWZvo$$
Et si tu disais ce que tu veux faire en cas de tableau vide au lieu de
dire ce que tu ne veux pas ?
Daniel
"Emcy" a écrit dans le message de news:
eZRK3f$$
je suis d'accord que cette methode marche mais ce n'est pas ce que je
veux
=> je ne veux pas avoir à fare de teste d'erreur à chaque fois que
j'appele ma fonction (je veux que ça soit fait à l'interrieur de la
fonction) : est-ce possible ?
cette fois, vous comprennez ou pas ?

"michdenis" a écrit dans le message de news:
OqC1GV$$
Bonjour Emcy,

Tu cherches à faire rouler une fonction même si dans les cas où elle
n'est pas requise...
Est-ce normal ?

Un recordset s'ouvre sur le premier enregistrement disponible.
Si le curseur se retrouve à la position EOF (End Of File)
c'est qu'il n'y a pas d'enregistrements dans le recordset
en conséquence, aucun besoin d'appliquer une fonction à
un recordset vide ! Est-ce déraisonnable de penser ainsi ?

'----------------------
If Rst.EOF = True Then
Msgbox "aucune information à afficher dans le listbox."
else
Me.ListBox1.List = FonctionRecupere(MaColonne, Filtre)
End if
'----------------------


Salutations!



"Emcy" a écrit dans le message de news:
ea4qJL$$
décidemment j'ai du mal à me faire comprendre :(
je programme en ADO => j'arrive à récupérer mes donnée et à les
retourner
dans ma fonction

le probleme est lorsque j'execute cette commande :
Me.ListBox1.List = FonctionRecupere(MaColonne, Filtre)

=> s'il n'y a aucun element dans le resultat de ma requete alors ma
fonction
revoie la valeur d'un tableau "vide" et donc une erreur se produit.
=> j'ai aussi essayé de dire à ma fonction de renvoyer un tableau
défini
comme ceci lorsque le resultat de ma requete est vide :
Function FonctionRecupere(MaColonne As String, Filtre As String) as
Variant
Dim MonTableau() As String
.....
'si le resultat de ma requete est vide alors je fais ça
Redim MonTableau(0)
MonTableau(0) = empty
.....
FonctionRecupere = MonTableau
End Function
=> avec cette methode je n'ai plus d'erreur mais j'ai dans ma ListBox
un
element "vide" (ce que je ne veux pas)

comment faire pour ne pas avoir ni d'element vide ni d'erreur ?
n'oubliez pas que je ne veux pas qu'on fasse un control d'erreur sur
la
ligne d'appel de la fonction (seulement à l'interrieur de la fonction)
pour
facilité l'utilisation de ma fonction.

"michdenis" a écrit dans le message de news:
eHFADs%23$
Bonjour Emcy,

Comment fais-tu pour obtenir ton recordset ? Par ADO, par DAO ?

De tester si ta requête retourne des enregistrements avant l'usage de
ta fonction devrait être relativement simple

Par exemple ceci :
Rst étant une variable de type recordset

If Rst.EOF = True Then
MsgBox "aucun enregistrement"
'arrêt de la procédure !
End If


Salutations!


"Emcy" a écrit dans le message de news:
%2328%23oi%23$
ça ne resoudera pas réellement mon probleme : certe je n'aurais plus
à
utiliser on error mais il faudra quand même faire un test sur ce
compteur

ce que je veux c'est créer une fonction qui me permette de remplir ma
ListBox simplement en utilisant la ligne de commande suivante :
Me.ListBox1.List = FonctionRecupere(MaColonne, Filtre)
=> je ne veux faire aucun control d'erreur dans cette section
(seulement à
l'interieur de la fonction)
=> ce que je veux c'est qu'une fois ma fonction créée, que je n'ai
plus à
me
préocuper de comment je vais gérer mes erruer lorsque je vais remplir
ma
ListBox ... j'espere avoir ete assez explicite => mais j'ai
l'impression
que
ce n'est pas possible....



"Daniel" a écrit dans le message de news:
OPK1AE%23$
Est-ce que tu ne peux pas mettre un compteur d'enregistrements au
moment
du remplissage ?
Daniel
"Emcy" a écrit dans le message de news:
eqAETy9$
malheuresement, je ne peux garantir que le tableau soit non vide.

j'ai fait une fonction qui revoie un tableau constitué des éléments
d'un
RecordSet (BDD Access) => donc je ne peux pas avoir comme certitude
que
mon tableau ne sera pas vide

Sub Main()
Me.ListBox1.List = FonctionRecupere(MaColonne, Filtre)
End Sub

Function FonctionRecupere(MaColonne As String, Filtre As String) as
Variant
Dim MonTableau() As String
.....
..... 'remplissage de MonTableau (en utilisant Redim pour fixer
la
taille)
.....
FonctionRecupere = MonTableau
End Function

=> si la fonction renvoie un tableau vide alors j'ai un message
d'erreur
lorsque je remplis la ListBox : je recherche un moyen pour qu'il
n'y ai
pas d'erreur s'il n'y a aucuns element à rentrer dans la ListBox
(sans
avoir à toucher le code de la sub Main)


"Emcy" a écrit dans le message de news:
et97VO8$
mon cas est pour Mat3 : y a t-il un moyen de ne pas avoir à
utliser On
Error ?

"Michel Gaboly" a écrit dans le message
de
news: O%23i470v$
Bonjour Emcy

Cela dépend de ce que tu appelles une variable tableau et de la
façon
dont elle a été définie.

Avec ce code :

Private Sub Tableaux()
Dim Mat1, Mat2(0), Mat3()
Mat1 = Array()
MsgBox UBound(Mat1)
MsgBox UBound(Mat2)
MsgBox UBound(Mat3)
End Sub

Mat1, sans parenthèse est un Variant auquel on affecte un tableau
vide

Mat2, avec parenthèses est défini directement comme un tableau de
Variant à une dimension.

Mat3, avec parenthèses est défini directement comme un tableau de
Variant non dimensionné.

UBound(Mat1) est égal à -1, tandis que UBound(Mat2) est égal à 0
(indice maximal), tandis que UBound(Mat3) déclenche une erreur.

bonjour,

existe t-il un moyen de voir si une variable tableau (vba) est
vide
sans utiliser les OnError ?



--
Cordialement,

Michel Gaboly
www.gaboly.com









































Avatar
Michel Gaboly
Bonjour,

Tu peux enlever Call et les parenthèses dans l'appel de la Sub RemplirL istBox, cela marchera aussi bien ;-))

... c'est pas bete
je pense que je vais faire un truc du genre

Sub Main
Call RemplirListBox(Me.ListBox1, MonTableau)
End Sub

Sub RemplirListBox(ObjetListBox As ListBox, Tableau() As String)
.... 'controle d'erreur
ObjetListBox.List = Tableau
End Sub

"Daniel" a écrit dans le message de news:
uM1Es4$$

Euh, je suis pas sûr, mais, si tu transformes ta fonction en macro
appelée, tu peux peut-être, dans cette dernière tester avant d'es sayer
d'alimenter ta listbox ?
Daniel



--
Cordialement,

Michel Gaboly
www.gaboly.com


Avatar
Emcy
Pourquoi ? je suis bien obligé de dire sur quel ListBox je veux travailler,
non ?

"Michel Gaboly" a écrit dans le message de news:

Bonjour,

Tu peux enlever Call et les parenthèses dans l'appel de la Sub
RemplirListBox, cela marchera aussi bien ;-))

... c'est pas bete
je pense que je vais faire un truc du genre

Sub Main
Call RemplirListBox(Me.ListBox1, MonTableau)
End Sub

Sub RemplirListBox(ObjetListBox As ListBox, Tableau() As String)
.... 'controle d'erreur
ObjetListBox.List = Tableau
End Sub

"Daniel" a écrit dans le message de news:
uM1Es4$$

Euh, je suis pas sûr, mais, si tu transformes ta fonction en macro
appelée, tu peux peut-être, dans cette dernière tester avant d'essayer
d'alimenter ta listbox ?
Daniel



--
Cordialement,

Michel Gaboly
www.gaboly.com


Avatar
Michel Gaboly
Bien sûr, mais le mot Call, hérité du Basic d'autrefois est superfl u en VBA

RemplirListBox Me.ListBox1, MonTableau

suffit.


Dans les vieux Basic, ou utilisait REM (comme remarque) en début de lig ne pour les commentaires.
Cela marche aussi avec VBA, mais l'apostrophe est + simple. C'est pareil : il est + simple de ne pas ajouter le mot
"Call" qui ne sert + à rien.



Pourquoi ? je suis bien obligé de dire sur quel ListBox je veux trava iller,
non ?

"Michel Gaboly" a écrit dans le message de news:

Bonjour,

Tu peux enlever Call et les parenthèses dans l'appel de la Sub
RemplirListBox, cela marchera aussi bien ;-))


... c'est pas bete
je pense que je vais faire un truc du genre

Sub Main
Call RemplirListBox(Me.ListBox1, MonTableau)
End Sub

Sub RemplirListBox(ObjetListBox As ListBox, Tableau() As String)
.... 'controle d'erreur
ObjetListBox.List = Tableau
End Sub

"Daniel" a écrit dans le message de news:
uM1Es4$$


Euh, je suis pas sûr, mais, si tu transformes ta fonction en macro
appelée, tu peux peut-être, dans cette dernière tester avant d'e ssayer
d'alimenter ta listbox ?
Daniel







--
Cordialement,

Michel Gaboly
www.gaboly.com



Avatar
michdenis
Bonjour Michel,

| Bien sûr, mais le mot Call, hérité du Basic d'autrefois est superflu en VBA


L'utilisation du mot "Call" permet à l'application au moment de la compilation
d'identifier le lieu où se situe la procédure appelée. Conséquence, l'exécution
du code serait plus "rapide". De plus, dans certains cas, cela pourrait aider
à la lecture du code en discriminant les procédures appelées et les méthodes
supportées par le code VBA.

Évidemment, personne ne dit que la présence de ce mot "Call" soit obligatoire !
;-)


Salutations!
Avatar
Michel Gaboly
Bonjour Michel,

La vitesse d'exécution, pourquoi pas ?

Mais je ne suis pas sûr que la différence de temps soit mesurable.

Quant à la lecture, il s'agit de préférences personnelles : des goû ts et des couleurs ;-)))

Personnellement, je préfère discriminer en donnant des noms en clair et en français
(ControleSaisie, ReportDonnees, MAJLabels, ...)

Mais je conçois que d'autres puissent réagir différemment.


Bonjour Michel,

| Bien sûr, mais le mot Call, hérité du Basic d'autrefois est sup erflu en VBA


L'utilisation du mot "Call" permet à l'application au moment de la co mpilation
d'identifier le lieu où se situe la procédure appelée. Conséque nce, l'exécution
du code serait plus "rapide". De plus, dans certains cas, cela pourrait aider
à la lecture du code en discriminant les procédures appelées et l es méthodes
supportées par le code VBA.

Évidemment, personne ne dit que la présence de ce mot "Call" soit o bligatoire !
;-)


Salutations!





--
Cordialement,

Michel Gaboly
www.gaboly.com

Avatar
Emcy
s'il u a plus d'un argument dans la procédure, il faut obligatoirement
utiliser call, autrement j'ai une erreur de compil...

"Michel Gaboly" a écrit dans le message de news:

Bonjour Michel,

La vitesse d'exécution, pourquoi pas ?

Mais je ne suis pas sûr que la différence de temps soit mesurable.

Quant à la lecture, il s'agit de préférences personnelles : des goûts et des
couleurs ;-)))

Personnellement, je préfère discriminer en donnant des noms en clair et en
français
(ControleSaisie, ReportDonnees, MAJLabels, ...)

Mais je conçois que d'autres puissent réagir différemment.


Bonjour Michel,

| Bien sûr, mais le mot Call, hérité du Basic d'autrefois est superflu en
VBA


L'utilisation du mot "Call" permet à l'application au moment de la
compilation
d'identifier le lieu où se situe la procédure appelée. Conséquence,
l'exécution
du code serait plus "rapide". De plus, dans certains cas, cela pourrait
aider
à la lecture du code en discriminant les procédures appelées et les
méthodes
supportées par le code VBA.

Évidemment, personne ne dit que la présence de ce mot "Call" soit
obligatoire !
;-)


Salutations!





--
Cordialement,

Michel Gaboly
www.gaboly.com

Avatar
Michel Gaboly
Sûrement pas, j'ai écrit des dizaines de milliers de lignes en VBA sa ns jamais avoir besoin de Call.

s'il u a plus d'un argument dans la procédure, il faut obligatoiremen t
utiliser call, autrement j'ai une erreur de compil...

"Michel Gaboly" a écrit dans le message de news:

Bonjour Michel,

La vitesse d'exécution, pourquoi pas ?

Mais je ne suis pas sûr que la différence de temps soit mesurable.

Quant à la lecture, il s'agit de préférences personnelles : des g oûts et des
couleurs ;-)))

Personnellement, je préfère discriminer en donnant des noms en clai r et en
français
(ControleSaisie, ReportDonnees, MAJLabels, ...)

Mais je conçois que d'autres puissent réagir différemment.



Bonjour Michel,

| Bien sûr, mais le mot Call, hérité du Basic d'autrefois est sup erflu en
VBA


L'utilisation du mot "Call" permet à l'application au moment de la
compilation
d'identifier le lieu où se situe la procédure appelée. Conséque nce,
l'exécution
du code serait plus "rapide". De plus, dans certains cas, cela pourrait
aider
à la lecture du code en discriminant les procédures appelées et l es
méthodes
supportées par le code VBA.

Évidemment, personne ne dit que la présence de ce mot "Call" soit
obligatoire !
;-)


Salutations!









--
Cordialement,

Michel Gaboly
www.gaboly.com


Avatar
Emcy
pourtant si, j'ai une erreur de syntaxe pour ce bout de code au niveau de
l'appele de la procédure Toto(i, j) (il faut mettre call) :
Sub Main()
Dim i As Integer
Dim j As Integer

i = 1
j = 1
Toto(i, j)
End Sub

Sub Toto(a As Integer, b As Integer)
a = a + 1
b = b + 1
End Sub
=> remarque la version de visual basic est la 6.3 (Excel 2002)


"Michel Gaboly" a écrit dans le message de news:

Sûrement pas, j'ai écrit des dizaines de milliers de lignes en VBA sans
jamais avoir besoin de Call.

s'il u a plus d'un argument dans la procédure, il faut obligatoirement
utiliser call, autrement j'ai une erreur de compil...

"Michel Gaboly" a écrit dans le message de
news:
Bonjour Michel,

La vitesse d'exécution, pourquoi pas ?

Mais je ne suis pas sûr que la différence de temps soit mesurable.

Quant à la lecture, il s'agit de préférences personnelles : des goûts et
des couleurs ;-)))

Personnellement, je préfère discriminer en donnant des noms en clair et en
français
(ControleSaisie, ReportDonnees, MAJLabels, ...)

Mais je conçois que d'autres puissent réagir différemment.



Bonjour Michel,

| Bien sûr, mais le mot Call, hérité du Basic d'autrefois est superflu en
VBA


L'utilisation du mot "Call" permet à l'application au moment de la
compilation
d'identifier le lieu où se situe la procédure appelée. Conséquence,
l'exécution
du code serait plus "rapide". De plus, dans certains cas, cela pourrait
aider
à la lecture du code en discriminant les procédures appelées et les
méthodes
supportées par le code VBA.

Évidemment, personne ne dit que la présence de ce mot "Call" soit
obligatoire !
;-)


Salutations!









--
Cordialement,

Michel Gaboly
www.gaboly.com


Avatar
Michel Gaboly
C'est normal ; dans mon premier message à propos de Call, je disais :

"Tu peux enlever Call et les parenthèses dans l'appel de la Sub Remplir ListBox, cela marchera aussi bien ;-)) "


Or ici tu as laissé les parenthèses. C'est cela qui provoque l'erreur de syntaxe : il faut simplement écrire

Toto i, j

Les parenthèses sont nécessaires si l'élément appelé est l'argu ment d'autre chose : si Toto est une fonction qui renvoie
un résultat, il faut écrire :

Res = Toto(i, j)


Voilà.


pourtant si, j'ai une erreur de syntaxe pour ce bout de code au niveau de
l'appele de la procédure Toto(i, j) (il faut mettre call) :
Sub Main()
Dim i As Integer
Dim j As Integer

i = 1
j = 1
Toto(i, j)
End Sub

Sub Toto(a As Integer, b As Integer)
a = a + 1
b = b + 1
End Sub
=> remarque la version de visual basic est la 6.3 (Excel 2002)


"Michel Gaboly" a écrit dans le message de news:

Sûrement pas, j'ai écrit des dizaines de milliers de lignes en VBA sans
jamais avoir besoin de Call.


s'il u a plus d'un argument dans la procédure, il faut obligatoiremen t
utiliser call, autrement j'ai une erreur de compil...

"Michel Gaboly" a écrit dans le message de
news:
Bonjour Michel,

La vitesse d'exécution, pourquoi pas ?

Mais je ne suis pas sûr que la différence de temps soit mesurable.

Quant à la lecture, il s'agit de préférences personnelles : des g oûts et
des couleurs ;-)))

Personnellement, je préfère discriminer en donnant des noms en clai r et en
français
(ControleSaisie, ReportDonnees, MAJLabels, ...)

Mais je conçois que d'autres puissent réagir différemment.




Bonjour Michel,

| Bien sûr, mais le mot Call, hérité du Basic d'autrefois est su perflu en
VBA


L'utilisation du mot "Call" permet à l'application au moment de la
compilation
d'identifier le lieu où se situe la procédure appelée. Conséqu ence,
l'exécution
du code serait plus "rapide". De plus, dans certains cas, cela pourrai t
aider
à la lecture du code en discriminant les procédures appelées et les
méthodes
supportées par le code VBA.

Évidemment, personne ne dit que la présence de ce mot "Call" soit
obligatoire !
;-)


Salutations!












--
Cordialement,

Michel Gaboly
www.gaboly.com



1 2 3 4