Discussion :

[Superpat9999]

Bonjour
Sur la même base, dans un module, j'ai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Public Type RECT
        Left As Long
        Top As Long
        Right As Long
        Bottom As Long
End Type

et dans un autre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Private Type RECT
      Left As Long
      Top As Long
      Right As Long
      Bottom As Long
End Type

Puis-je supprimer le second, il me semble qu'il y a double emploi ?
Merci de vos réponses

[deedolith]

Salut,

Effectivement, il y a double emploi.
Quand à savoir lequel supprimer, il convient en premier lieux de se poser les questions de la portée et de l'utilisation de cette structure.
Par défaut, on garde celui qui a la portée la plus petite (soit: Private).
Si ca fait coin coin:

• 1) On se pose de la question de la localisation des fonctions / procédures utilisant cette structure.
  Sont-elles définies au bon endroit ?
  Y'a t'il du sens à la regrouper dans un même module ?
  La structure est-elle utilisée en argument ?
• 2) En dernier recours, on utilisa la portée la plus grande (Public).

PS: Avant de supprimer définitivement, met les lignes en commentaire, réalise tes tests, une fois que c'est concluant, tu peux te débarrasser du code redondant.

[Superpat9999]

Salut,

Effectivement, il y a double emploi.
Quand à savoir lequel supprimer, il convient en premier lieux de se poser les questions de la portée et de l'utilisation de cette structure.
Par défaut, on garde celui qui a la portée la plus petite (soit: Private).
Si ca fait coin coin:

• 1) On se pose de la question de la localisation des fonctions / procédures utilisant cette structure.
  Sont-elles définies au bon endroit ?
  Y'a t'il du sens à la regrouper dans un même module ?
  La structure est-elle utilisée en argument ?
• 2) En dernier recours, on utilisa la portée la plus grande (Public).

PS: Avant de supprimer définitivement, met les lignes en commentaire, réalise tes tests, une fois que c'est concluant, tu peux te débarrasser du code redondant.

Merci deedolith, effectivement c'est un vrai casse tête, je n'avais pas fait attention à cela au début de ma programmation et maintenant c'est une usine à gaz !
J'en déduis qu'il vaut mieux 3 Private, qu'un seul Public.

[deedolith]

Merci deedolith, effectivement c'est un vrai casse tête, je n'avais pas fait attention à cela au début de ma programmation et maintenant c'est une usine à gaz !
J'en déduis qu'il vaut mieux 3 Private, qu'un seul Public.

Non !
Ce qu'il vaut mieux c'est: Une programmation qui a du sens.

[Pierre Fauconnier]

Salut.

Avoir deux types Rect (l'un public et l'autre private) n'a aucun sens. Il me semble logique de supprimer le private, histoire de pouvoir utiliser le type dans tout ton projet (je doute que l'utilisation d'une variable Rect soit limitée au seul module dans lequel on déclare le type)

[Superpat9999]

Salut.
Avoir deux types Rect (l'un public et l'autre private) n'a aucun sens. Il me semble logique de supprimer le private, histoire de pouvoir utiliser le type dans tout ton projet (je doute que l'utilisation d'une variable Rect soit limitée au seul module dans lequel on déclare le type)

Quand à savoir lequel supprimer, il convient en premier lieux de se poser les questions de la portée et de l'utilisation de cette structure.
Par défaut, on garde celui qui a la portée la plus petite (soit: Private).
Si ca fait coin coin:

1) On se pose de la question de la localisation des fonctions / procédures utilisant cette structure.
Sont-elles définies au bon endroit ?
Y'a t'il du sens à la regrouper dans un même module ?
La structure est-elle utilisée en argument ?
2) En dernier recours, on utilisa la portée la plus grande (Public).

Merci à tous les 2 pour vos réponses, puis-je en déduire que je peux regrouper ces fonctions dans un même module à partir du moment où elles sont appelés depuis plusieurs modules différents.
Autre question est-ce valable pour les API ?

[star]

Bonjour

Le mieux est l'ennemi du bien

A trop vouloir bien faire on finit pas casser ;7
.

[Pierre Fauconnier]

Tu peux éclater ton code dans différents modules. C'est même une très bonne chose. Et c'est pour cela que pour moi, tu dois déclarer ton type perso en Public. Ainsi, tu peux passer des variables de ce type aux différentes fonctions qui en ont besoin. C'est tout bénéf.

Perso, je découpe mon code au moins en 3 modules (architecture en "3 tiers" qui convient à Excel):

• Presentation layer: Couche d'échanges avec l'utilisateur (msgbox, procédures évènementielles, ... + les feuilles et le workbook)
• Business layer: Tout ce qui touche au "métier" que tu pilotes en VBA (jamais de msgbox dans les fonctions de ce module)
• Data Access Layer: Couche d'accès aux données => gestion des tables, données externes, ... (jamais non plus de msgbox dans cette couche)

En VBA pour Excel, c'est parfois moins strict parce qu'Excel lui-même mélange un peu les genres, mais en étant attentif à cette architecture, tu créeras un code plus maintenable et évolutif.


Pour les API, je n'ai pas bien compris. Tu as des API dans un module? Pour moi, les fonctions d'API sont privées, et ce sont les fonctions qui les utilisent qui sont publiques.

Bien sûr, c'est une réponse générique et il convient d'adapter à ton cas.

[Superpat9999]

Pour les API, je n'ai pas bien compris. Tu as des API dans un module? Pour moi, les fonctions d'API sont privées, et ce sont les fonctions qui les utilisent qui sont publiques.

Bien sûr, c'est une réponse générique et il convient d'adapter à ton cas.

J'ai créé un module DescriptionMoniteur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
#If VBA7 Then
        Private Declare PtrSafe Function EnumDisplayDevices Lib "user32.dll" Alias "EnumDisplayDevicesA" (ByVal lpDevice As String, ByVal iDevNum As Long, ByRef lpDisplayDevice As DISPLAY_DEVICE, ByVal dwFlags As LongPtr) As LongPtr
        Private Declare PtrSafe Function EnumDisplaySettings Lib "user32.dll" Alias "EnumDisplaySettingsA" (ByVal lpszDeviceName As String, ByVal iModeNum As LongPtr, ByRef lpDevMode As DEVMODE) As LongPtr
        Private Declare PtrSafe Function LoadLibraryEx Lib "kernel32.dll" Alias "LoadLibraryExA" (ByVal lpFileName As String, ByVal hFile As LongPtr, ByVal dwFlags As Long) As LongPtr
        Private Declare PtrSafe Function GetProcAddress Lib "kernel32.dll" (ByVal hModule As LongPtr, ByVal lpProcName As String) As LongPtr
        Private Declare PtrSafe Function GetModuleHandle Lib "kernel32.dll" Alias "GetModuleHandleA" (ByVal lpModuleName As String) As LongPtr
        Private Declare PtrSafe Function FreeLibrary Lib "kernel32.dll" (ByVal hLibModule As LongPtr) As Boolean
        Private Declare PtrSafe Function EnumDisplayMonitors Lib "user32.dll" (ByVal hdc As LongPtr, ByRef lprcClip As Any, ByVal lpfnEnum As Long, ByVal dwData As Long) As Boolean
        Private Declare PtrSafe Function GetMonitorInfo Lib "user32.dll" Alias "GetMonitorInfoA" (ByVal hMonitor As LongPtr, ByRef lpmi As MONITORINFOEX) As Boolean
        Private Declare PtrSafe Function CreateDC Lib "gdi32" Alias "CreateDCA" (ByVal lpDriverName As String, ByVal lpDeviceName As String, ByVal lpOutput As String, lpInitData As LongPtr) As LongPtr
        Private Declare PtrSafe Function GetDeviceCaps Lib "gdi32" (ByVal hdc As LongPtr, ByVal nIndex As Long) As Long
        Private Declare PtrSafe Function DeleteDC Lib "gdi32" (ByVal hdc As LongPtr) As Long
#Else
        Private Declare Function EnumDisplayDevices Lib "user32.dll" Alias "EnumDisplayDevicesA" (ByVal lpDevice As String, ByVal iDevNum As Long, ByRef lpDisplayDevice As DISPLAY_DEVICE, ByVal dwFlags As Long) As Long
        Private Declare Function EnumDisplaySettings Lib "user32.dll" Alias "EnumDisplaySettingsA" (ByVal lpszDeviceName As String, ByVal iModeNum As Long, ByRef lpDevMode As DEVMODE) As Long
        Private Declare Function LoadLibraryEx Lib "kernel32.dll" Alias "LoadLibraryExA" (ByVal lpFileName As String, ByVal hFile As Long, ByVal dwFlags As Long) As Long
        Private Declare Function GetProcAddress Lib "kernel32.dll" (ByVal hModule As Long, ByVal lpProcName As String) As Long
        Private Declare Function GetModuleHandle Lib "kernel32.dll" Alias "GetModuleHandleA" (ByVal lpModuleName As String) As Long
        Private Declare Function FreeLibrary Lib "kernel32.dll" (ByVal hLibModule As Long) As Boolean
        Private Declare Function EnumDisplayMonitors Lib "user32.dll" (ByVal hdc As Long, ByRef lprcClip As Any, ByVal lpfnEnum As Long, ByVal dwData As Long) As Boolean
        Private Declare Function GetMonitorInfo Lib "user32.dll" Alias "GetMonitorInfoA" (ByVal hMonitor As Long, ByRef lpmi As MONITORINFOEX) As Boolean
        Private Declare Function CreateDC Lib "gdi32" Alias "CreateDCA" (ByVal lpDriverName As String, ByVal lpDeviceName As String, ByVal lpOutput As String, lpInitData As Long) As Long
        Private Declare Function GetDeviceCaps Lib "gdi32" (ByVal hdc As Long, ByVal nIndex As Long) As Long
        Private Declare Function DeleteDC Lib "gdi32" (ByVal hdc As Long) As Long
#End If

Des fonctions peuvent se retrouver dans d'autres modules, dois-je les passer en Public et les regrouper ?

[deedolith]

C'est une très bonne idée de regrouper les fonctions dans différent module.

Il est recommandé de les regrouper en fonction de leurs rôle, et nommer les module en conséquence.
Ca te permettra de t'y retrouver, et tu pourras ensuite décider de la portée des variables, types, déclarations d'API.

Par exemple, si tu travailles avec le ruban, tu peux avoir un module nommé Ribbon,
dans lequel tu retrouveras toutes les fonctions callback / gestionnaires d'évènement du ruban, ainsi qu'une référence vers le ruban.
Perso, je préfère déclarer la référence en privé, et fournir une fonction retournant cette dernière:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
'// Module Ribbon
Private mRibbon As Office.IRibbonUI
 
    '// Callback appelée lors du chargement du ruban
Public Sub Ribbon_OnLoad(ByRef Ribbon As Office.IRibbonUI)
    Set mRibbon = Ribbon
End Sub
 
    '// Retourne la référence vers le ruban
Public Function GetRibbon() As Office.IRibbonUI
    Set GetRibbon = mRibbon
End Function

Autre exemple:
Supposons que tu aies besoin de detecter les coordonnées de la souris sur une image, et retourner la région (Haut, Bas, Droite, Gauche) sur lequel l'utilisateur à cliqué.
Il te faudra les API, une structure représentant les coordonéees de la souris (exigée par les API), une structure représentant la région, et une fonction retournant la région.

Le reste de l'application n'aura pas besoin de connaitre les API, ni les coordonnées de la souris, on les mettra donc en privé.
Par contre, la région doit être connue, ainsi que la fonction retournant cette dernière, on les mettra en public.
Ce qui peut ressembler à ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
'// Module Souris
Private Declare Function GetCursorPos Lib "user32" (lpPoint As POINTAPI) As Long
 
Private Type POINTAPI
    X As Long
    Y As Long
End Type
 
Public Type Region
    Haut As Boolean
    Bas As Boolean
    Droite As Boolean
    Gauche As Boolean
End Type
 
Private Function GetMousePosition() As POINTAPI
    Dim Position As POINTAPI
    GetCursorPos Position
    GetMousePosition = Position
End Function
 
Public Function GetClickedRegion(ByRef Image As Picture) As Region
    Dim Position As POINTAPI
    Position = GetMousePosition
 
    Dim Region As Region
        '// Calcul de la région
 
    GetclickedRegion = Region
End Function

En conclusion:
Il n'y a pas vraiment de réponse générique, tout dépend de ton besoin.
A ta charge d'organiser ton code au mieux.