Dans Visual Studio .NET, la propriété TabStop est définie par défaut sur True pour tous les champs de commande et d'entrée. La plupart des autres concepteurs ont un certain concept de contrôle de tabulation pour les «utilisateurs avancés» qui n'aiment pas beaucoup passer à leur souris.Principe de conception: existe-t-il une raison pour désactiver TabStop?
Cette propriété bascule simplement la possibilité pour le contrôle de recevoir le focus lorsque l'utilisateur appuie sur le bouton de tabulation pour parcourir l'ordre de tabulation.
J'ai entendu de nombreux développeurs dire si tous les champs devaient être dans l'ordre des onglets. Voici quelques-uns des arguments que je l'ai entendu de chaque côté:
Toujours:
- Désactivation de l'ordre de tabulation à un bouton oblige l'utilisateur à prendre ses mains sur le
- clavier pour cliquer ce qui ralentit votre flux. Par défaut, Microsoft le définit comme vrai pour une raison quelconque.
- Les boutons désactivés/masqués ne sont pas mis au point de toute façon.
Parfois Off:
- boutons Annuler et supprimer les boutons doivent être en dehors de l'ordre de tabulation afin d'éviter l'exécution accidentelle.
- Oui c'est hors de l'ordre de tabulation, mais vous devez définir un mnémonique afin que vous puissiez toujours y accéder avec le clavier.
Ma question porte sur les principes de bonne conception:
- Est-il jamais une bonne raison de tourner ArrêtTabulation off pour un bouton de commande?
- Existe-t-il une bonne raison de désactiver TabStop pour un champ de saisie?
Si vous répondez oui à l'une de ces questions, connaissez-vous des exemples de programmes bien connus? comme Windows Media Player? ou quelque part dans le panneau de contrôle ou quelque chose comme un exemple d'un champ/bouton sans un ordre de tabulation?
Alors, est-ce vraiment la réponse? "Oui, ça va, mais personne ne peut trouver un bon exemple." – Jrud