pourrait-il être une question très simple mais je n'ai jamais touché Delphi. J'ai une boîte d'édition et cela peut accepter le caractère. Mais sur une condition spéciale, je dois vérifier que le caractère de la boîte d'édition ne sont que des chiffres.
Comment pouvons-nous faire ça?
Remarque: l'utilisateur peut entrer n'importe quel caractère mais au moment de la validation, je dois vérifier au-dessus d'un.
4 Réponses :
Je ne sais pas quel événement vous avez l'intention d'utiliser pour invoquer la validation, mais la validation peut être faite comme ceci:
if TryStrToInt(Edit1.Text, Value) then DoSomethingWithTheNumber(Value) else HandleNotANumberError(Edit1.Text);
Il ne devrait-il pas y avoir un «d'autre» avant l'appel à Dosomeththenumber?
@awmross bon point. Dans ma tête, le gestionnaire d'erreur a soulevé une exception mais c'est trop fort et hypothèse.
Oh merci! Je convertissions le texte de la boîte d'édition en char et en comparant chaque caractère est défini ou [0..9] existe ou non. Sur la base de cela, j'ai essayé, mais cela a l'air plus court.
@Gaps Si vous souhaitez limiter les réponses aux versions de 12 ans du logiciel, vous devez vraiment le dire lorsque vous posez la question.
Je sais que vous avez dit que l'utilisateur Je refuserais l'entrée de tout sauf chiffres. remplissez l'événement OnKeyPress pour la modification. P> peut entrer n'importe quel caractère mais au moment de la validation code>.
Cependant, je voudrais offrir une alternative, car il semble très idiot de permettre à un utilisateur de saisir des valeurs, uniquement pour se plaindre à l'utilisateur 1 minute plus tard; Cela sent bien bien ... pas bien.
Si vous avez des entiers qui sont particulièrement faciles: p> procedure TForm1.Edit1KeyPress(Sender: TObject; var Key: Char) ;
var
Edit1Text: string;
begin
if (Key = '-') and Pos('-',Edit1.Text) = 0 then begin
Edit1.Text:= '-' + Edit1.Text; //Force the '-' to be in the front.
end
else if (Key = '-') and Pos('-',Edit1.Text) <> 0 then begin //else flip the sign
Edit1Text:= Edit1.Text;
Edit1.Text:= StringReplace(Edit1Text, '-', '',[]);
end;
if not(Key IN ['0'..'9', #8, #9, #13, #27, #127]) then key:= #0;
end;
Vous voudrez peut-être modifier cet ensemble dans ['0' .. '9', # 8, # 9, # 13, # 27, # 127, '-'] . Surtout le retour arrière et la suppression sont utiles pour entrer entrée. ;) (Et pour les flotteurs, vous voudrez peut-être inclure également Decimalseparator.)
-1 pour ne pas faire attention à la note de OP. Désolé. La validation des nombres à la volée pourrait être l'exception, mais la validation à la sortie ou à la soumission est une bonne pratique courante.
@NGLN, je refuse d'écrire des programmes qui émettent des messages d'erreur, vous allez ignorer votre commentaire. C'est juste une forte croire que j'ai, l'utilisateur a toujours raison.
@Johan David n'entre pas explicitement un message d'erreur: HandlenoTanumberRorror E.G. pourrait définir la mise au point sur ce contrôle d'édition et lui donner un fond rouge.
@Johan: prudent. Toutes les erreurs ne proviennent pas de l'utilisateur, et si vous n'informez pas l'utilisateur de ce qui ne va pas, cela peut conduire à la frustration de leur part.
@ Mason, Ngln, je suis très conscient de cela, j'essaie juste de faire un effort supplémentaire pour éviter d'émettre des erreurs et de l'option de Ngln d'affichage dans le rouge, j'utilise parfois aussi lorsque la validation d'entrée devient trop complexe. Je crois juste à donner des commentaires autres que les boîtes de dialogue modales avec un seul bouton
Pratiquement bullevé. Question des États "L'utilisateur peut entrer n'importe quel caractère mais au moment de la validation, je dois vérifier au-dessus d'un". Toujours votre réponse vaut la peine d'être prise en compte,
Vous devez toujours valider le texte à la sortie / modification car il existe plus de moyens de mettre des données dans une zone d'édition que d'appuyer sur les touches. Coller du texte par exemple.
"Personnellement, je ne crois pas à la délivrance d'un message d'erreur, vous devez toujours s'efforcer de ne pas permettre à l'utilisateur de saisir des données non valides en premier lieu." C'est bon jusqu'à un point, mais vous devez laisser l'utilisateur découvrir pourquoi leur contribution n'est pas acceptée.
@Pertiw, oui, cela fait longtemps que j'ai écrit ma classe TVALIDEDIT, mais IIRC j'ai fini par vérifier dans l'événement de changement.
@David, j'utilise une boîte d'indicateur de couleur bleue pour cela, qui affiche les valeurs autorisées lorsque l'utilisateur entre dans un mauvais caractère (ou une combinaison invalide de caractères) , combinée avec un message dans la barre d'état.
@johan j'ai fait la même chose, mais le client n'aime pas ça. Avec force, je devais bouger au comportement idiot mais les deux semble bon à un moment donné
Je ne comprends pas pourquoi vous voudriez permettre à un utilisateur de saisir un caractère, puis ne lui permettriez pas de passer la validation.
Si vous avez vraiment besoin de bloquer l'entrée, alors un contrôle qui le fait pour vous vaut mieux que de pirater cela. Si votre version de Delphi est vraiment ancienne, essayez la JVCl: TJVValidateDit dans la bibliothèque de composants JVCL, par exemple dans toutes les versions de Delphi. Cependant, dans les versions récentes régulières de Delphi (2009 et ultérieure), il est déjà construit dans plusieurs solutions possibles, notamment Tmaskedit et Tspinedit. P>
Si vous n'avez vraiment besoin que d'écrire une méthode de validation, puis envisagez d'utiliser une regex ou Fonction de validation codée à la main et maintenez ce code distinct de la commande. P>
// Taking OP question obsessively literally, this
// function doesn't allow negative sign, decimals, or anything
// but digits
function IsValidEntry(s:String):Boolean;
var
n:Integer;
begin
result := true;
for n := 1 to Length(s) do begin
if (s[n] < '0') or (s[n] > '9') then
begin
result := false;
exit;
end;
end;
end;
+1 Mes pensées exactement, je ne comprends pas le code, le code David le fait en une ligne: trystrtoint ()
@Warren, a-t-il dit: "Mais sur une condition particulière, je dois vérifier que le caractère de la boîte d'édition n'est que des chiffres." Il n'a donc pas besoin de vérifier cela dans certaines circonstances, pas tout le temps. BTW, PLZ Ajoutez NumberSonly Propriété dans Modifier des commandes dans les versions récentes de Delphi à la liste de votre solution intégrée. Le réglage de la propriété NumberSonly vers true rendra le contrôle d'édition pour rejeter tout caractère non numérique.
NumberSonly n'est pas une option valide imo et la définition de Winapi (ES_Number) puisque même alors vous pouvez coller du texte invalide.
Oh Intéressant Trouver @vcldveloper! Cela semble problématique cependant?
@Stefan, je ne peux pas reproduire le problème que vous avez mentionné dans Windows 7, à l'aide de Delphi 2010. Un contrôle d'édition que sa propriété NumberSonly est défini sur TRUE n'accepte aucun caractère alphabétique qui ne doit pas collez-la.
Je viens de le tester sur Windows XP et vous pouvez coller des caractères non numériques dans la modification selon msdn.microsoft.com/en-us/library/bb775464.aspx Bien qu'il semble qu'ils le modifiaient pour Vista et plus haut (voir également les commentaires sur l'article MSDN)
Mais sur une condition spéciale, j'ai Pour vérifier le caractère de la boîte d'édition sont seuls des chiffres.
Vous avez besoin de deux contrôles d'édition. Un pour la valeur NUMÉRO-UNIQUEMENT ET UNE POUR LA VALEUR ALLA TOUTES. Activer ou désactiver le contrôle qui correspond à la condition. Si les deux commandes ont de bonnes sous-titres (et peut-être des indications, pourquoi un contrôle est activé ou désactivé) afin que l'utilisateur sache ce qu'il doit entrer et pourquoi.
- Je n'aime pas bloquer l'utilisateur. Un scénario:
- je saisis " abc123 "
- En quittant le contrôle d'édition, je reçois un message d'erreur "Seuls les numéros autorisés"
- Je me rends compte que j'ai oublié d'atteindre la condition spéciale
- Je veux faire quelque chose pour atteindre la condition spéciale
- Mais je ne peux pas parce que j'ai toujours le message d'erreur "Seuls les numéros autorisés"
- Je dois donc corriger la valeur à " 123 "
- Faites les choses à atteindre la condition spéciale
- retape mon ancienne valeur "ABC123" à nouveau
Aarrgghh : -) Pour les formulaires de saisie de données simples Je fais les formulaires suivants: je permet une entrée erronée, mais commutez la couleur de police en rouge pour chaque commande d'édition avec une entrée non valide (la couleur de police rouge n'est pas suffisante lorsqu'une valeur vide n'est pas autorisée). Si l'utilisateur essaie de poster les données, je donne un message d'erreur qui informe l'utilisateur sur tous les champs d'entrée non valides et avortez le message.
Oui!! Même je fais la même chose. Mais 1 chose que je veux mentionner sur cette condition. Cette condition est simplement basée sur une valeur de case à cocher, rien de plus que cela
Veuillez clarifier pourquoi vous ne voulez pas bloquer l'utilisateur de saisir des données non valides. Les utilisateurs qui se sont bloqués avec des données non valides dans un champ d'entrée sont considérés comme un "piège à l'utilisateur" et est considérée comme une mauvaise conception d'interface utilisateur par de nombreux développeurs.
@Warren Veuillez préciser pourquoi vous souhaitez bloquer les utilisateurs entrant des valeurs à la source et les voler ainsi de la rétroaction de la touche appuyée sur la touche entraînant des caractères apparaissant à l'écran.
Ne permettant pas à l'utilisateur de saisir des valeurs non valides dans le contrôle ne signifie pas ne pas lui donner des commentaires. Vous pouvez toujours afficher du message disant "Vous avez entré une mauvaise valeur, etc ..." comme lorsque CAPSLOCLOCK se trouve sur Windows Login.
@David: Aucune réponse à Keystroke ne peut en fait confondre également certains utilisateurs. Peut-être une réponse idéale serait de clignoter un grand feu rouge à l'écran et un bip. S'ils persistent à taper des non-chiffres, nous devrons peut-être leur donner une enoogie. :-)
@Warrent C'est vous qui propose «aucune réponse à Keystroke». Et oui, ce serait déroutant.
@Stefan - c'est exactement ce que je préférerais. Pourquoi les utilisateurs devraient-ils remplir les données non valides (E. g. caractères dans le numéro de numéro) et obtenir le message d'erreur qu'ils ont fait quelque chose de mal. IMHO ça fait économiser le temps.
Donc, David, utilisateur confus ou utilisateur bloqué? Vous préféreriez les avoir coincé? De toute façon, c'est un piège.
@warren pourquoi seraient-ils coincés? Je suppose que l'utilisateur est capable de supprimer du texte.
@Warren, @stefan: Blocage de mes entrées est comme avoir les mains battues, je préférerais simplement être racontée ou laisser allongé que mon contribution est fausse, je pourrais donc le réparer moi-même. Cela ne signifie pas nécessairement que je dois être informé de l'erreur que lorsque j'appuie sur Entrée. Vous pouvez utiliser de telles choses comme la modification de la couleur du texte ou de la couleur de fond de la zone de texte. Vous pouvez même afficher un message en vous informant que quelque chose pourrait être absent sans bloquer l'entrée , oui, comme Windows effectue lorsque les capuchons verrouillent l'écran de connexion.
L'utilisateur peut être moins susceptible d'être bloqué si nous montrons un X rouge à côté d'une entrée non valide au moins.