Bonjour,

Problématique 1
J'utilise un listview trié par défaut sur une des colonnes qui fonctionne parfaitement à la première édition.
Lorsque je le met à jour après une saisie (par la procédure utilisée à l'initialisation) l'édition se compose d'une ligne vierge sur deux. Toutes les clés étant présentes. Après des heures (jours !) de recherches j'ai trouvé comme solution de courtcircuiter la procédure de tri : 
'LvwClients.SortOrder = lvwAscending
'LvwClients.SortKey = 1
'LvwClients.Sorted = True
La mon édition est cohérente mais j'oblige l'utilisateur à trier par
[Private Sub LvwClients_ColumnClick(ByVal ColumnHeader As MSComctlLib.ColumnHeader)]

Problématique 2
J'importe ce même formulaire dans un nouveau fichier qui sera mon fichier "programme" et là quand je lance mon Usf j'ai sur cette procédure (_ColumnClick) le msg :
"Erreur de compilation, Type défini par l'utilisateur non défini"
Je m'aperçois qu'effectivement la classe listview est absente de toute bibliothèque et je ne sais pas comment l'ajouter. Mais comme elle était bien évidemment tout aussi absente dans l'autre classeur où l'Usf fonctionnait bien (au tri près), je me dis que j'ai un second problème.

Merci de votre aide
Cordialement 

Bonjour Danisoaz,

Si tu fournissais un petit classeur en exemple peut-être qu'on pourrait tirer tout ça au clair plus rapidement.

Je prends note des deux points et j'attends le petit classeur.

Cordialement,

Guy

Bonjour Guy,

Merci de ton concours et désolé pour ce délai mais je m'étais absenté quelques jours.

Cordialement
Daniel

Bonjour Daniel,

Problématique 2 :

Je n'ai jamais eu ce problème tout simplement parce que je n'ai jamais exporté de formulaire portant des contrôles VB6 d'un classeur à l'autre. Ma curiosité a été piquée donc.

J'ai tenté la chose avec Excel 2010 et Excel 2003 et effectivement le problème se produit à l'exportation dans l'une et l'autre version.

Dans la boîte à outils contrôles il y a bien le contrôle Microsoft ListView Control 6.0 (SP6). Si je place un ListView sur un formulaire une référence à l'OCX maître Microsoft Windows Common Controls 6.0 (SP6) est ajoutée automatiquement dans les références du projet. Bien.

Par contre l'importation du formulaire dans un nouveau classeur n'inscrit pas de référence au Microsoft Windows Common Controls 6.0 (SP6) automatiquement. Tant pis. Suffit de l'inscrire et le tout compile sans problème.

Problématique 1 :

Un classeur dont la feuille Clients existe et n'est pas vide serait indiqué. J'aperçois quelques contorsions dans le code qui me semblent suspectes. Des données seraient utiles à tirer la chose au clair.

Cordialement,

Guy

Bonjour Guy,

"Suffit de l'inscrire et le tout compile sans problème" inscrire quoi, où, comment ?

Ci joint le fichier tables avec la feuille clients

Merci beaucoup
Cordialement
Daniel

Bonjour Daniel,

Pour l'inscription de la référence :
Dans l'éditeur VBA (VBE), menu Outils->Références... Puis dans la liste cocher Microsoft Windows Common Controls 6.0. 

Une fois cette référence inscrite il n'y aura plus d'erreur de compilation (Menu Débogage->Compiler VBAProject)

J'ai importé le formulaire UsfClients dans Tables.xlsx puis effectué la manipulation décrite y compris la compilation, renommé le fichier Tables.xlsm et tout fonctionne.

Seul petit problème, une fois l'importation effectuée le classeur pèse plus de 100 Ko; pas de pièce jointe donc. Tente la chose de ton côté et tout devrait rentrer dans l'ordre pour ce qui est de l'erreur de compilation (Problématique 2).

Cordialement,

Guy

Bonjour Guy,

Merci de tes éclaircissements.
En fait "Microsoft Windows Common Controls 6.0" ne figure pas dans la liste des références. Pour le faire apparaître il faut insérer un contrôle listview bidon à partir de la boite à outils. Avoue que c'est un peu tordu. On m'avait prévenu que la manipulation de ce contrôle n'était pas simple mais quand même.

Ceci étant réglé et si ne n'est pas trop te demander peux tu te pencher sur la problématique 1 évoqué dans mon premier post ? (dans procédure Private Sub MajListingClients(), problème de tri incohérent après une réinitialisation).

Cordialement
Daniel 

Bonjour Daniel,

Le petit bout de code suivant devrait aider ta cause :


Copie correctement ce truc dans ton formulaire UsfClients  en écrasant l'ancienne procédure.

Il se peut que tu aies à polir quelques coins mais commençons par là. On verra pour la suite.

Je monte un classeur minceur avec quelques lignes de données seulement et je te le transmets aussitôt que j'ai une ou deux minutes.

Cordialement,

Guy

Bonjour Guy,

Ma procédure "Private Sub LvwClients_ColumnClick..." fonctionne très bien (ce qui n'exclut pas que je puisse améliorer le code avec tes remarques !) et j'ai du mal poser ma problématique 1, donc je reprends :

Dans Private Sub UserForm_Initialize(),  le listview est initialisé , puis chargé et trié sur la colonne client par appel de 
MajListingClients. Ceci sans aucun problème.

Par contre après la saisie d'un nouveau client je veux évidemment rafraîchir mon listview avec les nouvelles données. Pour ce faire j'appelle la même MajListingClients et là l'édition se compose d'une ligne vierge sur deux bien que toutes les clés soient présentes.
Or quand je saute les 3 lignes ci dessous de MajListingClients (état du code dont tu disposes), l'édition est parfaitement cohérente en terme de données mais non triée sur la colonne client.
'LvwClients.SortOrder = lvwAscending
'LvwClients.SortKey = 1
'LvwClients.Sorted = True

C'est pas dramatique, mais comme ce n'est pas logique ça m'empêche de dormir !

Merci encore

Cordialement
Daniel 

Bonjour Daniel,

J'ai suivi le chargement de la liste pas à pas en scrutant les étapes une à une. Il apparaissait qu'à l'enregistrement d'un nouvel élément, plus précisément à l'exécution de la seconde ligne du bloc suivant :



l'élément 1 prenait la valeur 2, l'élément 2 prenait la valeur 4, l'élément 3 la valeur 6 etc.

À la passe suivante tout recommence mais à l'envers. L'élément 1 passe à 7, le 2 à 6, le 3 à 5, etc. et ça tourne les enfants ça tourne.

Comportement absolument déroutant. Inextricable.
Au bout du compte seuls les éléments impairs possédaient des ListSubItems non vides d'ou une ligne sur deux vide.
Tu pourras noter que ce ne sont que les lignes impaires qui portent des ListSubItems non vides.

Je t'invite à zieuter la chose par toi-même. Tu verras que le comportement du ListView est tout à fait ésotérique.
Pour ce faire ajoute un espion LvwClients.ListItems et un point d'arrêt au début du bloc. Des heures de plaisir.

Bien, mais encore me suis-je dit. Quel que soit le comportement de cet objet, puisque j'avais renoncé à pousser davantage dans cette direction, où peut bien être la différence entre le chargement du ListView à l'affichage (UserForm_Initialize()) et celui à la mise à jour (nouvel élément)? Compte tenu du comportement de cette bibite il semble que le chargement suive un ordre sur lequel le codeur n'a aucune prise. Hmmm... réchiflissons... Euréka!

Au démarrage le ListView n'est pas trié! La propriété Sorted est à False, alors qu'à l'ajout celle-ci est à True!

J'ai donc ajouté une instruction

' 2pme : instruction ajoutée
LvwClients.Sorted = False

juste avant le bloc cité dans MajListingClients() et le tout semble fonctionner correctement.

Alors pour ce qui est d'empêcher de dormir ton truc est champion.

Aussi il se peut fort bien que tu reviennes ici pour d'autres petits problèmes causés par ton application. J'en ai aperçu quelques bribes ici et là.

Je crois la problématique 1 résolue. Si tel est le cas prière de le noter ici.

Cordialement,

Guy