Aide VBA

galopin01 a écrit :

Dans VBA Modifier la Sub WriteRecord :

Private Sub WriteRecord()
   Cells(iRow, 1) = Val(Me.tb0) 'iD)
   Cells(iRow, 2) = Me.cboRech
   Cells(iRow, 3) = Val(Me.tb5) 'Qte
   Cells(iRow, 4).Formula = "=SLFRM"
   Cells(iRow, 5).Formula = "=SLFRMX"
   Cells(iRow, 6).Formula = "=SLFRMX"
   Cells(iRow, 7).Formula = "=SLFRMX"
   With WsP 'la suite sans changement

Salut galopin01, impossible de trouver cette macro, je l'ai rajouté à la suite des autres mais le problème c'est qu'il me renvoi pas la formule =SLFRMX dans les cellules mais directement les valeurs, du coup quand je change la quantité ça ne fonctionne pas. J'ai également perdu la mise en forme, je sais pas comment tu as fait pour toujours avoir la même mise en forme (45min pour trouver, changer et tester aussi peu de chose, j'ai peur d’avoir eu les yeux plus gros le ventre pour ce projet...)

Merci d'avance pour tes lumières !

Pour la mise en forme c'est bon j'ai trouvé finalement

Quand tu veux rechercher quelque chose dans VBA tu vas dans le menu Edition > Rechercher et tu coches Projet en cours :

Donc tout va bien finalement ?

A+

Salut, merci pour l'info !

En effet, ça marche mieux !

Je savais pas qu'il y avait tout ça de "cacher".

D'habitude je clic juste sur "Visualiser le code" dans le menu général "Développeur"...

D'habitude je clic juste sur "Visualiser le code"

La partie émergée de l'iceberg !

A+

Re, j'ai fais mumuse avec les codes du coup et j'y vois plus clair maintenant.

En faisant des tests, je me suis rendu compte d'un petit soucis : si je copie l'onglet "P1" pour le renommer en un autre nom, que je clic sur la cellule pour faire apparaître l'UserForm et que souhaite supprimer la ligne, ça fonctionne sur un onglet (P1) mais pas l'autre. Pourtant le code à pas bougé (j'ai simplement rajouté un "unload me" qui fonctionne très bien sur le 1er onglet) :

Private Sub cmdDelete_Click() With WsP .Range(.Cells(iRow, 1), .Cells(iRow, 7)).Delete shift:=xlUp End With Unload Me End Sub

Comme le nom de l'UserForm est identique sur les 2 onglets (1 seul "usfSaisie"), je comprends pas pourquoi c'est valable sur l'un et pas sur l'autre. Idem pour la mise en forme que j'ai mise dans "WriteRecord". Pourrais-tu me mettre sur la voie stp ?

Merci

Je viens de voir que lorsque j'ajoute des lignes sur un des onglets les lignes se rajoutent aussi sur l'autre onglet mais sans les valeurs, ça reprend seulement la mise en forme (bordures en trait fin noir) idem pour la suppression. J'en déduis que le WriteRecord et l'userForm sont liés à l'onglet (P1) il faudrait donc que je copie le code et renomme pour le second onglet, c'est ça ?

Bonjour à tous,

j'ai lu le fil et j'ai vu une question tombée aux oubliettes :

- La touche de verrouillage du pavé numérique qui se débloque ? -> Il me semble que la touche Num lock se déverrouille, peut être dû à une ligne de code, sais-tu comment modifier ce problème ?

Sans aucun doute dû à :

Private Sub cboRech_Click()
   SendKeys "{Tab}"
End Sub

c'est la maladie des sendkeys.

Je propose de remplacer par :

Private Sub cboRech_Click()
    tb5.SetFocus
End Sub

A moins qu'il ne faille compliquer un peu en fonction de la visibilité des autres textbox. Je ne connais pas le fonctionnement prévu

eric

[Eriic]

Oui bien sur...

Je n'utilise pas les noms d'onglets justement parce que les gens ont la fâcheuse habitude de nommer leurs feuilles avec des noms ésotérique, à rallonge et que ça prend de la place pour rien dans le code. Donc au lieu de copier l'onglet sous un autre nom YAKA le renommer et basta...

Le code "sait" que cette feuille est concernée (quelque soit le nom que tu lui affubles) car j'utilise en fait la plupart du temps un nom masqué. (*1) Donc que l'utilisateur ne risque pas de démolir au gré de sa fantaisie lyrique !

Cependant dans ton cas cela ne marche qu'à moitié car (pour des raisons un peu confuses) je n'ai pas pris la précaution de verrouiller complètement le système.

Pour bien faire j'aurai du écrire :

Private Sub WriteRecord()
   With WsP
   .Cells(iRow, 1) = Val(Me.tb0) 'iD)
   .Cells(iRow, 2) = Me.cboRech
   .Cells(iRow, 3) = Val(Me.tb5) 'Qte
   .Cells(iRow, 4).Formula = "=SLFRM"
   .Cells(iRow, 5) = "=SLFRMX" 'Pro
   .Cells(iRow, 6) = "=SLFRMX" 'Glu
   .Cells(iRow, 7) = "=SLFRMX" 'Lip
      With .Range(.Cells(iRow, 1), .Cells(iRow, 7)).Borders(xlEdgeBottom)
         .LineStyle = xlContinuous
         .ColorIndex = 0
      End With
   End With
End Sub

Ainsi tu n'aurais pas eu cet effet "je ne vois que les valeurs pas les traits..."

J'insiste bien sur cette notion qui fait que le code est dédié à la feuille et que pour cette raison, il ne faut pas faire une copie des onglets qui du coup sont nommés différemment par ce que pour le coup si tu utilises ce genre de subterfuge tu va avoir un comportement erratique. Un code (en particulier les miens ...) est lié à la feuille ("Toutes les feuilles") et même bien souvent au classeur...

(*1) Nom caché : Une feuille possède plusieurs noms celui attribué par l'utilisateur (Le nom de l'onglet) -que je n'utilise pas- et le CodeName VBA qui est un nom système défini dans les propriétés de la feuille et indépendant du nom de l'onglet que l'utilisateur peut modifier sans crier gare...

Tu vois ainsi que le code est dédié à cette feuille par l'intermédiaire du nom "WsP" lié à l'onglet P1 qui lui peut être renommé sans dommage.

Il existe aussi d'autres raisons qui font que le code ne doit pas être dupliqué sauvagement avec la feuille : Ce sont tous les noms du Gestionnaire de nom. Ceux- ci ont une "portée" (en générale de niveau classeur) c'est à dire que ces noms sont reconnus par VBA et Excel)dans tout le classeur comme faisant partie de "tel" onglet. (celui du CodeName d'origine) Si tu crées une copie sauvage de la feuille tu vas créer du même coup une pléthore de noms identiques à ceux de la feuille d'origine, mais avec une portée beaucoup plus restreinte Ces noms ne seront reconnus qu'au niveau de la copie...

On voit qu'on crée ainsi une ambiguïté fâcheuse qui risque de faire foirer irrémédiablement le code d'origine.

Bien sur le programmeur censé "se lave les mains" lui de toutes les manips scabreuses que tu as pu faire...

A+

Bonjour,

Merci pour vos retours !

J'aurai, encore une fois, appris quelque chose que se soit pour les sendkeys ou pour les noms masqués.

Je comprends mieux le problème rencontré lors de la copie de l'onglet du coup...

Je vais finalement laisser de côté l'idée de faire une copie de l'onglet.

L'idée était de mettre en confrontation sur un même onglet deux tableaux (afin de voir les différents aliments utilisés pour chaqu'un d'eux) et de comparer, sur un même graphique, les valeurs nutritionnelles des deux tableaux et ainsi mettre en évidence la différence entre les deux programmes sur ces valeurs.

C'est déjà pas simple à expliquer mais alors à mettre en place n'en parlons pas, je vais plutôt retourner améliorer la BD

Merci pour tout.

C'est clair que de ce coté il y a beaucoup à faire surtout si on veut en faire un outil à mettre entre toute les mains :

Au moins pour ceux qui se bornent à un régime hypocalorique, il est inutile d'avoir plus de 40 références de pains dont les 3/4 tournent entre + ou - 15 autour de la moyenne (175) et le reste entre 370 et 420. On pourrait en dire autant de nombreuses rubriques (huiles, matières grasses, pates, eaux...) tandis que d'autres mériteraient d'être développées dans des "listes en cascades" et d'autres regroupées (également dans des listes afin de permettre un comparatif instantané) avec un Listview.

Pour moi qui m'intéresse un eu à la question j'ai ainsi été très étonné de me rendre compte que ma petite entorse de ce matin (2 tranches de pain de mie Harry's) était l'équivalent de la totalité de ma ration journalière de baguette...

N'hésite pas à revenir me voir pour développer ton appli (au besoin en MP car je me fait souvent un peu rare sur le forum et certains sujets peuvent m'échapper...)

A+

Salut,

Merci pour ton retour.

Oui, je tente de remettre de l'ordre dans la BD en essayant de pas tout casser.

Je ne connais pas "Listview", je vais voir ce qu'en pense Google, ça pourrait me donner des idées

Quand tu parles de développement d'appli, tu parles de programme exécutable ? Car j'avais déjà regarder de ce côté là mais je n'ai aucunes connaissances dans le domaine (ce qui m'handicape beaucoup). Je me suis trompé de vocation je crois !

Non, on peut développer une petite appli Excel, pour ceux qui possèdent Excel.

Pour éviter de voir la base de donnée, masquer (ou pas) le menu pour éviter des fausses manoeuvres intempestives...

Pour les autres je n'ai pas d'idée sur la question.

C'est possible en programmation internet mais ça n'a rien à voir avec Excel et ça n'a rien à voir non plus avec un blog.

Il s'agit de programmation professionnelle.

A+