none
vs2017 UWP c# comment donner par code le focus à un texbox

    Question

  • bonjour

     j'avance doucement sur mon projet et encore un code que je sais pas écrire correctement

     voici mon code  textbox 1.focus();

     et cela me donne une  erreur pouvez vous m'aider merci d'avance

    samedi 3 février 2018 14:28

Réponses

  • Bonjour, 
    Pouvez-vous partager le message d'erreur? Le thread suivant peut-être vous aidera:
    C# - Set Focus on TextBox - Which Event? 

    Cordialement, 
    Nina

    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.

    • Marqué comme réponse SIMONGEORGES mardi 6 février 2018 08:43
    • Non marqué comme réponse SIMONGEORGES mardi 6 février 2018 08:43
    • Marqué comme réponse SIMONGEORGES mercredi 7 novembre 2018 09:00
    lundi 5 février 2018 15:25
    Modérateur
  • Bonjour,

    Ah ben oui, c'est vrai ce que dit Nina : quand on rencontre une erreur, ça peut être utile, mais seulement si on a quelques propriétés de l'erreur.

    Quelque chose de ce type peut donner des informations intéressantes dans la fenêtre de sortie :

    try
    {
       TextBox1.Focus();
    }
    catch(Exception Ex)
    {
       System.Diagnostics.Debug.Print(Ex.Message);
    }

    Dans certains cas on peut avoir besoin d'autres propriétés de l'exception, il peut aussi y avoir une InnerException.

    Donc ... Qu'est-ce qu'on propose comme critères de recherche, déjà ?

    "DotNet Exception"

    "C# try ... catch"

    "gestion d'exception sous .Net"

    Il y a de quoi lire des pages et des pages, et ça ne sera pas du temps perdu.

    Quand l'exception comporte un numéro avec huit caractères hexadécimaux, il ne faut pas négliger de transmettre ça, c'est ça qui sert de critère de recherche au sujet de l'erreur. Mais à ce qu'il me semble, il faut une version relativement récente de .Net pour en bénéficier ?

    Au passage, j'ai implicitement corrigé une erreur possible, à savoir que le contrôle pouvait s'appeler non pas

    1 (avec une étiquette TextBox: devant, à l'usage d'un goto, mais c'est le genre de chose qu'on cherche à éviter en C#),

    mais TextBox1, ce qui est le nom par défaut du premier contrôle TextBox qu'on crée sur un formulaire WinForm (et bien sûr on est invité à le renommer sans tarder pour mettre quelque chose de plus explicite, sinon bon courage au bout de six mois pour faire le tri entre TextBox1, TextBox2, TextBox3 ... C'est quand même plus facile de s'y retrouver avec txbNomClient, txbAdresseClient, txbCommentairePourLivreur.

    Pour ce qui est arrivé là-haut, les ordinateurs des années 80 auraient dit "syntax error" et on se serait débrouillé avec ça  :) Ce qui finalement correspond à ce qui nous est arrivé sur ce forum ;)



    • Marqué comme réponse SIMONGEORGES samedi 10 février 2018 08:19
    • Modifié Gloops samedi 10 février 2018 08:32
    vendredi 9 février 2018 15:52
  • SVP, pas de "catch(Exception ex)", le débogueur est notre ami.

    Paul Bacelar, Ex - MVP VC++

    • Marqué comme réponse SIMONGEORGES mercredi 7 novembre 2018 09:00
    vendredi 9 février 2018 16:31

Toutes les réponses

  • Bonjour, 
    Pouvez-vous partager le message d'erreur? Le thread suivant peut-être vous aidera:
    C# - Set Focus on TextBox - Which Event? 

    Cordialement, 
    Nina

    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.

    • Marqué comme réponse SIMONGEORGES mardi 6 février 2018 08:43
    • Non marqué comme réponse SIMONGEORGES mardi 6 février 2018 08:43
    • Marqué comme réponse SIMONGEORGES mercredi 7 novembre 2018 09:00
    lundi 5 février 2018 15:25
    Modérateur
  • Bonjour,

    Ah ben oui, c'est vrai ce que dit Nina : quand on rencontre une erreur, ça peut être utile, mais seulement si on a quelques propriétés de l'erreur.

    Quelque chose de ce type peut donner des informations intéressantes dans la fenêtre de sortie :

    try
    {
       TextBox1.Focus();
    }
    catch(Exception Ex)
    {
       System.Diagnostics.Debug.Print(Ex.Message);
    }

    Dans certains cas on peut avoir besoin d'autres propriétés de l'exception, il peut aussi y avoir une InnerException.

    Donc ... Qu'est-ce qu'on propose comme critères de recherche, déjà ?

    "DotNet Exception"

    "C# try ... catch"

    "gestion d'exception sous .Net"

    Il y a de quoi lire des pages et des pages, et ça ne sera pas du temps perdu.

    Quand l'exception comporte un numéro avec huit caractères hexadécimaux, il ne faut pas négliger de transmettre ça, c'est ça qui sert de critère de recherche au sujet de l'erreur. Mais à ce qu'il me semble, il faut une version relativement récente de .Net pour en bénéficier ?

    Au passage, j'ai implicitement corrigé une erreur possible, à savoir que le contrôle pouvait s'appeler non pas

    1 (avec une étiquette TextBox: devant, à l'usage d'un goto, mais c'est le genre de chose qu'on cherche à éviter en C#),

    mais TextBox1, ce qui est le nom par défaut du premier contrôle TextBox qu'on crée sur un formulaire WinForm (et bien sûr on est invité à le renommer sans tarder pour mettre quelque chose de plus explicite, sinon bon courage au bout de six mois pour faire le tri entre TextBox1, TextBox2, TextBox3 ... C'est quand même plus facile de s'y retrouver avec txbNomClient, txbAdresseClient, txbCommentairePourLivreur.

    Pour ce qui est arrivé là-haut, les ordinateurs des années 80 auraient dit "syntax error" et on se serait débrouillé avec ça  :) Ce qui finalement correspond à ce qui nous est arrivé sur ce forum ;)



    • Marqué comme réponse SIMONGEORGES samedi 10 février 2018 08:19
    • Modifié Gloops samedi 10 février 2018 08:32
    vendredi 9 février 2018 15:52
  • SVP, pas de "catch(Exception ex)", le débogueur est notre ami.

    Paul Bacelar, Ex - MVP VC++

    • Marqué comme réponse SIMONGEORGES mercredi 7 novembre 2018 09:00
    vendredi 9 février 2018 16:31
  • SVP, pas de "catch(Exception ex)", le débogueur est notre ami.

    Paul Bacelar, Ex - MVP VC++

    En effet, je voulais proposer un moyen de récupérer le message d'erreur, mais c'est vrai que lorsque se produit une exception pendant le débogage on dispose d'une interface utilisateur avec un lien pour copier vers le presse-papiers.

    La proposition du try...catch, c'était au cas où Simon ne serait pas trop à l'aise avec l'utilisation de l'interface utilisateur liée à l'exception.

    J'ai lu récemment un blog qui invite à tester explicitement, lorsque cela s'applique, si une variable (ou un objet) est nulle, plutôt que de confier ça à un try...catch, car celui-ci met en œuvre des ressources bien plus lourdes.

    Quand on lit un fichier en revanche on n'a pas trop le choix, les causes d'erreur sont tellement variées qu'il serait dommage de se passer du try...catch à l'exécution.

    Dans le cas qui était proposé, une fois la syntaxe corrigée il n'y a plus de raison que se produise une exception (du moment que le contrôle est visible), sauf, dans une autre instruction un peu plus loin, si la boîte de texte contient une chaîne vide et qu'on cherche à mettre ça dans un champ d'une table qui ne peut pas contenir de chaîne vide.

    Mais nous touchons là à la validation de saisie, encore une autre recherche à mener pour ouvrir de nouvelles saines lectures.



    • Modifié Gloops samedi 10 février 2018 09:22
    samedi 10 février 2018 08:54
  • >J'ai lu récemment un blog qui invite à tester explicitement,

    Dans les propositions du C#8, il y a le fait que les types références ne seront plus "nullable" par défaut, ça coupera court à tous ces tests à la noix.

    >Quand on lit un fichier en revanche on n'a pas trop le choix,

    On n'a pas le choix, on ne catch que les exceptions qu'on sait traiter, comme un problème de droit pas d'accès ou de fichier manquant, pas un problème de mémoire interne corrompu ou un mode urgence d'UPS qui pète.


    Paul Bacelar, Ex - MVP VC++

    lundi 12 février 2018 10:13