Bon...

J'ai quand même ajusté ce qu'il fallait pour permettre également l'effacement de la totalité sélectionnée, même en cas de saisie non encore complète.

Je ne changerai toutefois pas immédiatement le zip car je suis sur le point de terminer la saisie assistée des heures (principe quelque peu différent).

Je ne changerai donc de zip que lorsque cette partie-là sera également terminée et testée par les "utilisateurs" autour de moi (s'agissant en effet d'un outil destiné à des utilisateurs finaux, leur avis est et doit rester prépondérant, bien évidemment).

Le nouveau zip contiendra donc les DEUX saisies : dates et (procédure distincte) les heures, avec possibilité de choisir heure:minutes:secondes ou heures:minutes.

A très bientôt, donc.

Bonjour Renfields

Il est facile  de permettre la saisie de 7/7/7 interprêté en 07/07/2007.
J'ai voulu l'éviter et ne le ferai donc pas pour deux raisons :
1) alourdissement du code (tests supplémentaires) sans gain réel.
2) on y gagnerait certes la frappe d'un chifre de temps à autre (lorsque sur 1 chiffre au lieu de 2) mais alors :
a) on perdrait l'ajout automatique du séparateur (souvent le plus fastidieux)puiqu'aucun code ne saurait déterminer si, à la frappe de 1 (par exemple), l'utilisateur n'a pas l'intention de frapper 12 (par exemple)
b) on ouvre la porte à youtes les étourderies (contraire de la vocation de l'outils, qui est celle d'assurer la meilleure sécurité). Je ne ferai jamais un outil permettant à l'utilisateur de saisir un millésime sur 2 chiffres, y compris si l'outil se sibstitue ) lui pour en écrire 4...(je n'oublie pas les mésaventures 2K ...). La philosophie est simple : ou l'on fait totalement confiance à l'utilisateur et dans ce cas on n'a plus besoin d'un contrôle de saisie, ou on se méfie des étourderies et on évite qu'il puisse frapper un 07 pour signifier une date de naissance 1908, qu'il n'y prenne garde, et que l'on se retrouve avec un magnifique nouveau-né (2008) correspondant à un centenaire.... Je ne ferai donc certainement pas celà ...(j'ai malheusement été le témoin, dans un certain ministère, des dépenses générées des quelquefois des années plus tard, dépenses parmi lesquelles l'intervention de magistrats pour rectifier un acte d'état-civil et le dédommagement d'héritiers n'ayant pu jouir de leurs droits qu'une fois l'affaire réglée...)
En ce qui concerne l'effacement : lorsque la date est complètement frappée, la sélection de la totalité puis l'utilisation de la touche suppr l'efface complètement. Ce que tu dis (effacement du dernier chiffre uniquement) n'arrive que si l'utilisateur sélectionne la totalité d'yne date incomplète puis utilise la touche suppr. J'ai délibérément adopté cette approche pour plusieurs raisons. L'inventaire en serait long, mais en voici quelques unes :

- il est bien rare que l'on décide de saisir une date puis que l'on se ravise en chemin
- lorsque tel est le cas, il est bien plus facile de laisser son doigt sur la touche backspace que de sélectionner puis d'enfoncer la touche suppr.
- su l'utilisateur s'aperçoit de ce qu'il s'est trompé d'un chiffre, il peut :
a) soit le sélectionner (un seul) et directement frapper le caractère (unique) de remplacement
b) soit revenir en arrère en utilisant uniquement la touche backspace

Avant d'arrêter mon choix (j'avais mis en place plusieurs ergonomies), j'ai mis au clavier mon épouse, mes trois filles et mes petits voisins. Leur p^référence unanime a été celle de l'ergonomie finalement choisie.

verifcomplet ne risque pas de traiter un multiple de 10 puisque tu ne peux saisir plus de 10 caractères. En utilisant Mod, je permets de quitter si le champ de saisie est vide, avec simplement Mod, sans avoir à écrire un if supplémentaire pour traiter ce cas, c'est tout)


Je veux bien faire en sorte que l'on puisse choisir MM/DD/YYYY au lieu de mm/dd/yyyy uniquement (j'avais choisi les minuscules uniquement par goût personnel).

La modif ne coûtera pas cher :
changer : Select Case Left(jfr,1) ===>> en Select Case Lcase(jfr,1))   ===>> je le ferai à l'occasion...

En ce qui concerne :

q.SelStart = Len(t)
  If q.SelStart < Len(t) Then
    q.SelStart = Len(t)
    Beep
    Exit Function

C'est tout simplement un bout de code qui a échappé au nettoyage final et iù l'un des t était un ch.
Il convient de supptimer ces lignes totalement inutiles

Voilà :

Donc oui : j'apporte 2 petites modification (suppression des lignes devenues inutiles et ayant échappé au nettolyage - ajout du Lcase pour permettre des formats en Majuscules), mai non : je ne modifie absolument pas l'ergonomie.

Bonjour,  MadM@tt

Qui te parle de tester si le nombre est pair ?

Le 1er nombre premier est 2 ===>> tu l'inscris donc d'office.

Tu fais ensuite ta boucle d'ajout à partir de 3 et avec un step 2

Tu ne risques ainsi pas de balayer les pairs, non ?

Bonjour, MadM@tt,

1) je mets la note de 10. Comment faire autrement (je fais la même chose que toi pour terouver des nombres premiers. j'entends pas là : même mécanisme, à 2 "poils" près).
2) tu peux diviser par 2 te temps de traitement, si tu veux ... car (mis à part le 1er nombre premier (2), tous les autres sont impairs et il est donc inutile de "balayer" les pairs).

Amitiés.

Bonsoir à tous les deux...
Je ne me sens absolument pas choqué.
Je regrette simplement que des commentaires justifiant cette notation ne soient pas là !
Je ne peux qu'en conclure que celui qui a fait celà l'a fait "juste pour s'amuser".
Pour le reste, celà a à mes yeux peu d'importance (mais alors vraiment). Une source est déposée en général dans un souci de partage. C'est également dans un esprit de partage que sont normalement déposés des commentaires, de sorte à (au besoin) corriger la source elle-même.

Tout celà est certes bien dommage, mais l'on n'y peut absolument rien et ce sera ainsi assez fréquemment.

Mon seul espoir pour le bien-être de tous ? Que celui qui a agi avec autant de "sagesse" et d' "esprit de partage" lise le présent message et y pense demain, en se rasant (s'il a déjà de la barbe, bien sur, ce qui n'est à mon avis pas encore le cas).

Tout celà ne m'empêchera absolument pas de déposer à nouveau telle ou telle autre source après m'être assuré que rien d'analogue n'esiste déjà, si je pense qu'elle est susceptible de servir un jour à l'un ou à l'autre, bien évidemment.

Amitiés à tous.

Bonjour,

J'aurais aimé que celui qui a noté à 1 ici (et qui l'a fait ailleurs le même jour...) ait le bon sens de dire pour quelles raisons. Il en aurait ainsi fait profiter chacun, non ?

Pour la petite histoire :
La coincidence a fait qu'une question a été posée là :
http://www.xtremevbtalk.com/showthread.php?t=284982
Je m'abstiens d'intervenir là-bas (et pourtant... j'aurais de bonnes raisons de le faire !!!... peut-être ...).
Précision : ils ne connaissent pas la solution en simple écran, avant même d'avoir à se creuser les méninges pour traiter en double écran... mais je laisse. Si solution totale : elle sera celle de VBFrance, promis.

Bonjour Julien et Merci...
Mais il n'y a aucune urgence.... (Ton boulot d'abord.... le reste quand tu t'ennuieras ... C'est évident.)
Merci encore.

  Bonjour,

  Qui (travaillant en double-écran), peut s'intéresser à la valeut dmPosition donnée au paramètre lpDevMode ( le 2ème, en entrée ) de la fonction  ChangeDisplaySettingsEx de la librairie user32 de l'API de Windows ?

Ah oui,

J'ai oubliié de vous dire (suis-je distrait !...)
Vous pouvez bien évidemment positionner également de cette façon une InputBox (bien que inputbox vous permette déla de choisir l'emplacement).... et... bien d'autres petites choses ... dont l'affichage des commondialogs....