Discussion :

[papouAlain]

Je suis en train d'écrire une surcharge de DateTimePicker pour pouvoir rendre ce P... de contrôle ReadOnly.
j'intercepte les evt MouseDown (pour la zone textBox du controle) et Enter (pour la fleche d'ouverture du calendrier). Si une propriété Locked est positionnée à true, j'interdis le traitement, mais voila si l'utilisateur clique sur le "Fleche vers le bas" pour ouvrir le DateTimePicker, il me faudrait fermer la zone calendrier de capture de la date...
j'ai pensé à un evenment Enter.
Comment faire ?

[papouAlain]

je m'explique un peu mieux...

je sais ne pas prendre en compte le MouseDown, mais dans la mesure ou le calendrier s'ouvre avant le Enter, je voufrais le fermer par code des que le Enter est généré. ainsi toute modif de date sera impossible.
Mais impossible de trouver la moindre méthode ou propriété...

[DonkeyMaster]

J'ai une solution particulièrement maquiavélique à te proposer.

Tu mémorises la date que tu veux garder.
Puis, dans l'évènement ValueChanged, tu remets cette valeur. Ainsi, dès qu'on fait une modif, hop, on revient à la vieille valeur.

Sinon, il y a toujours la propriété Enabled.

Ce que je ne comprends pas, c'est à quoi ça sert, tout ça. Si le but, c'est juste d'afficher une date, autant utiliser un TextBox.
Pourquoi veux-tu verrouiller le DateTimePicker?

[papouAlain]

Tu mémorises la date que tu veux garder.
Puis, dans l'évènement ValueChanged, tu remets cette valeur. Ainsi, dès qu'on fait une modif, hop, on revient à la vieille valeur.

C'est ce que j'ai fait actuellement, car ne pouvant faire mieux. Mais ça n'empeche pas le calendrier de s'ouvrir ce qui est un peu déroutant pour l'utilisateur

Sinon, il y a toujours la propriété Enabled.

Oui , mais une fois Disabled, c'est gris clair et totalement illisible à mon avis et à celui de mes utilisateurs...

Ce que je ne comprends pas, c'est à quoi ça sert, tout ça. Si le but, c'est juste d'afficher une date, autant utiliser un TextBox.
Pourquoi veux-tu verrouiller le DateTimePicker?

UN dateTimePicker est quand même plus puissant qu'un TextBox, ou en plus tu devrais te faire le controle de validité des dates saisies...
Par contre le DateTimePicker est pas trés lisible en Enabled=false.

Moi ce que je ne comprends pas c'est pourquoi les gens de MS sont assez amateurs pour fournir un controle permettant une saisie:
- sans propriété ReadOnly (comme sur la TextBox, puisque tu fais le parallèle),
- avec une gestion folklorique des événements (essaye de voir l'ordre de génération de ceux(ci dans le DateTimePicker),
- avec prise en compte des saisies avant génération des evt...

y'a des leçons d'informatique qu'ils ont raté...

[DonkeyMaster]

Oui , mais une fois Disabled, c'est gris clair et totalement illisible à mon avis et à celui de mes utilisateurs...

As-tu essayé de modifier le style? Je dis ça sans l'avoir vérifié, mais l'idée m'est venue à l'esprit.

UN dateTimePicker est quand même plus puissant qu'un TextBox, ou en plus tu devrais te faire le controle de validité des dates saisies...
Par contre le DateTimePicker est pas trés lisible en Enabled=false.

Si c'est seulement une question de contrôle de saisie, il y a moyen d'utiliser trycatch DateTime.Parse pour vérifier la saisie.

Moi ce que je ne comprends pas c'est pourquoi les gens de MS sont assez amateurs pour fournir un controle permettant une saisie:
- sans propriété ReadOnly (comme sur la TextBox, puisque tu fais le parallèle)

Et je confesse que je suis aussi surpris que toi par l'absence de la propriété ReadOnly. À moins qu'ils n'aient trouvé que cela ne rapporte rien par rapport à un TextBox. Non, attends, ça tient pas comme argument. Donc, je suis aussi sidéré que toi.
Je veux bien croire que le DateTimePicker a été conçu à La RACHE, mais de là à appeler les ingénieurs Microsoft d'amateurs, c'est trop quand-même.

[papouAlain]

Si c'est seulement une question de contrôle de saisie, il y a moyen d'utiliser trycatch DateTime.Parse pour vérifier la saisie.

et dans ce cas tu ne peux être que réactif aux erreurs. Ce qui pour les utilisateurs novices est déroutant égalemen, autant ne leur proposer que des données valides, quand on peux le faire...

mais de là à appeler les ingénieurs Microsoft d'amateurs, c'est trop quand-même.

Je maintiens que certains le sont. Vu les absences de réflexion sur ce que doivent proposer leurs controles, et l'absece de validation de ceux-ci...
c'est justement à cela qu'on fait la différence entre amateur et professionnel. Qu'ils soient "intellectuellement" puissants, là n'est pas la question. Mais amateurs ils le sont au niveau des controles de la .NET 1.1. pour avoir utilisé VS6 auparavant. On ne rtrouve pas dans la 1.1 pas mal des fonctionnalités précédente qui étaient fort utiles.
Donc je maintient !