Problèmes sur les dates venant d'un textbox

Bonsoir,
je bute sur une conversion d'heure pour mon application.
Sur le principe j'ai un SpinBouton un TextBox un Bouton et une cellule dans un tableau structuré.

• Le SpinButton doit varier par pas de 15mn de 0 à 50 heures
• Le TextBox doit afficher la valeur au format "hh:mm"
• Après validation par le bouton :
• La cellule doit recevoir le contenu du TextBox au format Serial number d'Excel. La cellule elle-même doit être au format "hh:mm" ou "[h]:mm" si les heures dépassent 24h

J'ai tester avec ce style de fonction

Code:

---

1 2 3 4 5 6 7 8 9 10

Public Function HeureToDec(pHeure As Date) As Single Dim nbHeures As Integer, nbMinutes As Integer, nbSecondes As Single   nbHeures = DatePart("h", pHeure, vbMonday, vbFirstFourDays) nbMinutes = DatePart("n", pHeure, vbMonday, vbFirstFourDays)   nbSecondes = nbMinutes * 60 + DatePart("s", pHeure, vbMonday, vbFirstFourDays) nbSecondes = nbSecondes / 3600 HeureToDec = nbHeures + nbSecondes   End Function

---

Mais je n'arrive pas au résultat voulu.
Merci pour votre aide.

Salut,

Un peut maladroite ta fonction,
Calculer des heures à partir des secondes et stocker le résultat dans la variable destinée à recevoir un nombre de secondes (ligne 7), ce n'est pas à faire.
Comprend bien qu'une variable n'est pas qu'un bête espace mémoire pour stocker une valeur. Elle à aussi un rôle définit par son nom, et toute utilisation doit satisfaire ce rôle.
Pour faire simple: Stocker des heures dans des secondes, ca n'a pas de sens.

Sinon, par rapport à ta question, si j'ai bien compris:
Si le nombre d'heure est inférieur à 24h, afficher le nombre d'heure en décimal.
Si le nombre d'heure est supérieur à 24h, afficher le nombre d'heure au format hh:mm.

Il te faut écrire une fonction qui se charge de cela (ce n'est pas le job de HeureToDec).
Par exemple:

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

Public Sub test() Dim Wb As Excel.Workbook Set Wb = ThisWorkbook   Dim Ws As Excel.Worksheet Set Ws = Wb.Worksheets("Feuil1")   Dim Rng As Excel.Range Set Rng = Ws.Range("A1")   Dim dt As Date dt = Now   Dim heures As Single heures = HeureToDec(dt)   If (heures > 24) Then Rng.Value = TimeSerial(Hour(dt), Minute(dt), Second(dt)) Rng.NumberFormat = "hh:mm" Else Rng.Value = heures Rng.NumberFormat = "" End If End Sub

---

Notes:
Il y a les fonctions Hour(), Minute() et Second() disponibles pour extraires les heures / minutes / secondes d'une date.
Ce sera autrement plus lisible que DatePart().

Merci Deedolith te t'intéresser à ce sujet.

Je dois avoir la tête bien embrumée car je n'arrive même pas à expliquer mon souci, manque de sommeil je suppose.

Dans un premier temps il faut savoir que j'utilise une fonction de Pierre Fauconnier toute simple mais efficace pour écrire dans un TS

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Function TS_AddRow(TS As Range, Values, Optional Position As Long) Dim lstR As ListRow Dim lstO As ListObject Dim Counter As Long   Set lstO = TS.ListObject If Position = 0 Or Position > lstO.ListRows.Count Then Position = lstO.ListRows.Count + 1 Set lstR = lstO.ListRows.Add(Position) For Counter = LBound(Values) To UBound(Values) Step 2 lstR.Range(lstO.ListColumns(Values(Counter)).Index).Value = Values(Counter + 1) Next   If Not lstR Is Nothing Then Set lstR = Nothing If Not lstO Is Nothing Then Set lstO = Nothing End Function

---

Donc effectivement après avoir regarder de plus prés, cette fonction est bien, mais dans ce cas-ci elle ne convient pas, je dois faire une mise en forme sur chaque cellule et comme tu l'as si bien dis TimeSérial convient bien.

Donc je me suis entrainer sur un exemple avant de placer cela sur mon application, et ça à l'air, (je ne sais pas si cela a la musique :D) de fonctionner.
Merci de m'avoir ouvert les yeux.
Donc voilà pour la zone de texte la fonction ConvertMinToDay qui est limitée à 23h59mn (Je l'ai voulu) fait son job, et DateSerial pour récupérer les valeurs à mettre dans les cellules.

Si je puis me permettre quelques remarques supplémentaires sur ton code:

Passe les objets par référence en arguments, ce sera plus propre.
On Error Resume Next :cry:
GetTheValue: Je pense qu'on peut faire plus simple, avec une collections.
UserForm1Show: Triturer un formulaire depuis l'extérieur, je ne suis pas fan, car cela induit des dépendances.

Merci pour ton retour je suis toujours preneur de bonnes règles mais bon là je suis un peu perdu.

Citation:

---

On Error Resume Next :cry:

---

Là je ne pense pas que cela vienne de moi, tu as surement remarqué qu'il y a beaucoup de fonctions qui viennent de ci et de là. Je récupère et quand j'ai le temps je modifie à ma façon. Une fois ce petit projet terminé, je supprimerais tout ce qui n'est pas nécessaire au fonctionnement de l'application.

Citation:

---

GetTheValue: Je pense qu'on peut faire plus simple, avec une collections

---

Je vais me pencher sur cette solution.

Citation:

---

UserForm1Show: Triturer un formulaire depuis l'extérieur, je ne suis pas fan, car cela induit des dépendances.

---

Là par contre je suis dans l'expectative, à en croire certains (Pierre Fauconnier, que j'apprécie beaucoup) Ce n'est pas le rôle d'un formulaire d'interagir sur les tableaux ou feuilles, mais au code appelant c'est ce que je m'efforce de faire dans mes applications. Mais je suis preneur de tout point de vue.

Citation:

---

Envoyé par Valtrase

Là par contre je suis dans l'expectative, à en croire certains (Pierre Fauconnier, que j'apprécie beaucoup) Ce n'est pas le rôle d'un formulaire d'interagir sur les tableaux ou feuilles, mais au code appelant c'est ce que je m'efforce de faire dans mes applications. Mais je suis preneur de tout point de vue.

---

Ca, c'est un débat houleux qui fait couler beaucoup d'encre.

J'ai de l'expérience avec plusieurs langages objet.
VBA est un langage objet, et l'un des pilier des langage objet est l'encapsulation (masquer son implémentation interne pour ne mettre à disposition que le strict minimum, je te laisse chercher sur google pour plus de détails).
Les objets sont des instances de classes.

Malheureusement, VBA est ainsi fait,
- Les classes n'ont pas de réel constructeur, mais on peut en simuler un en s'inspirant du design pattern Factory.
- Les contrôles d'un formulaire sont publique, à mon sens, ils devraient être privés (est-ce que j'ai besoin de connaitre les propriétés Cuisine, Salon, Chambres de ta Maison ?).
- L'éditeur VBA ne nous incite absolument pas à faire du développement objet en mettant à disposition énormément de facilités (globales malheureusement), qui violent le principe d'encapsulation, et n'incitent pas non plus aux bonnes pratiques.

Le fait qu'un formulaire interagisse directement avec son environnement extérieur (que ce soit une feuille excel ou autre) introduit une forte dépendance, l'inverse est vrai également (l'environnement extérieur interagit directement avec un formulaire), et c'est source d'erreurs.
Il y a moyen de décorréler tout ce petit monde via les évènements (design pattern Observer), mais c'est hors de portée des débutants.
Je te laisse décortiquer l'exemple ci joint: Pièce jointe 633678
Tu noteras que le feuille (Feuil1) et le formulaire (formUpdateCell) n'interagissent jamais directement l'un avec l'autre.

Ca a pour avantage de faciliter la maintenance, et d'être très versatile (le formulaire peut être utilisé pour mettre à jour n'importe quelle cellule de n'importe quelle feuille, sans avoir besoin de modifier son code).
On respecte les principes SOLID (https://en.wikipedia.org/wiki/SOLID),
et la loi de Demeter (https://en.wikipedia.org/wiki/Law_of_Demeter).