Discussion :

[o-live]

Hello Kopernic,

C'est exactement ce que je voulais .

Un tout tout grand merci. Je vais juste m'attacher à bien comprendre ce que tu as fais et reviendrais vers toi avec mes commentaires pour voir si j'ai bien compris ! Si cela ne te dérange pas évidement .

J'apprécie l'aide, mais n'aime pas en profiter sans comprendre. Ceci n'apportant rien alors.

Je mettrais le post en résolu dès que j'aurais bien compris ton code.

Encore merci.

[Kropernic]

J'espère bien que tu reviendras poser des questions ! ;-)

[sinople]

La magouille la plus simple, pour pas dire la seule que je connaisse, pour sélectionné une cellule d'un datagridview et activer l'édition par code est la suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
MyDataGridView.Focus()
MyDataGridView.CurrentCell = MyDataGridView.Rows(rowIndex).Cells(cellIndex)
SendKeys.Send("{F2}")

C'est à dire de simuler la touche du clavier qui active l'édition (F2) en l'occurrence.

Après, en regardant ton exemple avec du recule, le datagridview est normalement prévu pour éditer une collection d'objet (en ligne) dont les propriétés sont en colonne. Alors que dans ton exemple tu mets les propriétés en ligne et un objet (ou une collection de 1...) en colonne. Si c'est parfaitement réalisable techniquement avec le datagridview en mode non lié, ça devient très rapidement la foire aux emmerdes pour juste bénéficier d'une interface visuel à la "Excel Style" (marque déposée par moi-même).

En effet, la bonne pratique (enfin ma pratique personnelle on va dire) est plutôt d'utiliser des couples de label + contrôle monovaleur (textbox, maskedtextbox, combobox, datestimepicker) qui sont databinder sur une bindingsource. Surtout que dans ce cas la navigation d'un contrôle à l'autre à l'aide de la touche Tab s'effectue simplement à l'aide des propriétés Tabstop et Tabindex des contrôles.

Dans certains scénario et pour aller plus loin, on peut même imaginer récupérer le contrôle qu'utilise VisualStudio pour afficher/éditer les propriétés des objets dans le designer (PropertyGrid). Ce qui peut dans certains cas, et avec relative maîtrise dans l'art de coder ses objets métiers, offrir une technique "unifiée" pour la problématique d'édition de propriété d'un objet. Même si d'un point de vue design/graphique c'est aussi sexy qu'un terminal monochrome de l'administration sur Windows 3.1, voir un challenger de Java Swing UI.

Après ceux qui commence un projet Winforms de nos jours avec des contraintes artistiques sont juste un peu à côté de la plaque (ou hors-sujet comme nous disait le prof de philo en rendant nos dissertations avec une note binaire).

Bref je te laisse découvrir la documentation par toi-même.

http://www.dotnetperls.com/propertygrid

http://www.codeproject.com/Articles/...g-PropertyGrid

https://msdn.microsoft.com/en-us/library/aa302326.aspx

[o-live]

Hello,

Pour sauter les cellules en readonly, on peut modifier l'event CellEnter comme ceci par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
    Private Sub DataGridView1_CellEnter(sender As Object, e As DataGridViewCellEventArgs) Handles DataGridView1.CellEnter
        With DataGridView1
            If Not .CurrentCell.ReadOnly Then
                .BeginEdit(False)
            Else
                SendKeys.Send("{tab}")
            End If
        End With
    End Sub

Mais faut voir si c'est bien ce comportement que tu veux. Car ça le fait aussi si tu cliques sur la cellule readonly.

Si tu as des cellules qui ne sont pas forcément en readonly mais qui sont invisibles, il faut p-e en tenir compte dans le code (pas testé).

Bonsoir Kopernic,

Excuse moi de ne revenir vers toi que maintenant mais comme tu m'as gentille-ment débloqué j'ai continué à avancer dans la réalisation mon application. J'avais pris du retard et donc ... .

Alors comme promis, voici ce que j'ai compris par rapport à ton code. Enfin si je me trompe pas ... .

Avec If Not .CurrentCell.ReadOnly, tu vérifie si on est pas dans une de mes cellules que j'ai mis en ReadOnly. Du coup, si la condition est vérifiée puisque mon DataGridView ne compte que deux type de cellules on est sur une des cellules destinées à l'encodage des coordonnées. Là, la méthode BeginEnd(False) met ma cellule active en mode edition et comme on lui passe le booléen False on ne sélectionne rien. On place simplement le curseur dans la cellule. Si on veux sélectionner le contenu de la cellule, il suffirait de passer true à la méthode.

Ensuite si je suis sur une cellule en ReadOnly (seconde partie de ton code), l'utilisation de la méthode SendKeys.Send (méthode que je connaissais pas) envoi la séquence Tab, ce qui me renvoi dans une cellule destinée à l'encodage des coordonnées.

Voilà un code tous simple finalement et qui répondait donc parfaitement à mes besoin.

Encore un grand merci à toi .

Ps: pour être sur si tu as le temps, merci de me dire si j'ai bien tous compris.

[o-live]

La magouille la plus simple, pour pas dire la seule que je connaisse, pour sélectionné une cellule d'un datagridview et activer l'édition par code est la suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
MyDataGridView.Focus()
MyDataGridView.CurrentCell = MyDataGridView.Rows(rowIndex).Cells(cellIndex)
SendKeys.Send("{F2}")

C'est à dire de simuler la touche du clavier qui active l'édition (F2) en l'occurrence.

Après, en regardant ton exemple avec du recule, le datagridview est normalement prévu pour éditer une collection d'objet (en ligne) dont les propriétés sont en colonne. Alors que dans ton exemple tu mets les propriétés en ligne et un objet (ou une collection de 1...) en colonne. Si c'est parfaitement réalisable techniquement avec le datagridview en mode non lié, ça devient très rapidement la foire aux emmerdes pour juste bénéficier d'une interface visuel à la "Excel Style" (marque déposée par moi-même).

En effet, la bonne pratique (enfin ma pratique personnelle on va dire) est plutôt d'utiliser des couples de label + contrôle monovaleur (textbox, maskedtextbox, combobox, datestimepicker) qui sont databinder sur une bindingsource. Surtout que dans ce cas la navigation d'un contrôle à l'autre à l'aide de la touche Tab s'effectue simplement à l'aide des propriétés Tabstop et Tabindex des contrôles.

Dans certains scénario et pour aller plus loin, on peut même imaginer récupérer le contrôle qu'utilise VisualStudio pour afficher/éditer les propriétés des objets dans le designer (PropertyGrid). Ce qui peut dans certains cas, et avec relative maîtrise dans l'art de coder ses objets métiers, offrir une technique "unifiée" pour la problématique d'édition de propriété d'un objet. Même si d'un point de vue design/graphique c'est aussi sexy qu'un terminal monochrome de l'administration sur Windows 3.1, voir un challenger de Java Swing UI.

Après ceux qui commence un projet Winforms de nos jours avec des contraintes artistiques sont juste un peu à côté de la plaque (ou hors-sujet comme nous disait le prof de philo en rendant nos dissertations avec une note binaire).

Bref je te laisse découvrir la documentation par toi-même.

http://www.dotnetperls.com/propertygrid

http://www.codeproject.com/Articles/...g-PropertyGrid

https://msdn.microsoft.com/en-us/library/aa302326.aspx

Bonjour Sinople,

Merci pour tes réflexions et liens.

Je voudrais juste t'éclairer sur le pourquoi de l'utilisation du DataGridView dans mon cas pour l'enregistrement des coordonnées que tu peux voir sur mon print screen .

Oui, effectivement pour te citer je "mets les propriétés en ligne et un objet (ou une collection de 1...) en colonne". Mais c'est voulu.

Oui en effet j'aurais pu utiliser des "couples de label + contrôle monovaleur (probablement des texbox dans mon cas).

Et oui, tu as peut-être raison de dire "ceux qui commence un projet Winforms de nos jours avec des contraintes artistiques sont juste un peu à côté de la plaque".

Dans mon cas la réflexion va plus loin que ce que tu aurais pu penser. En fait l'utilisation du DataGridView, au delà de l'aspect éventuellement esthétique dont tu parles, va me permettre de ne pas bloquer l'utilisateur et d'avoir finalement une application qui je pense pourra répondre au mieux à un besoin de celui-ci.

Je m'explique. Pour l'instant l'utilisateur peut encoder un numéro de téléphone bureau, un mobile, une adresse mail. Mais imagine que l'utilisateur n'ai pas assez avec cela et qu'il ai besoin de rajouter un téléphone privé, une adresse mail privée ... on pourrais certainement encore ajouter d'autres choses. Ici le codage que j'aurais à faire me sera grandement facilité puisque je n'aurais qu'a programmer la mise à jour du DataSource du DataGridView pour répondre à cette demande. Bien-sûr il y a aussi besoin d'un formulaire permettant l'ajout de la donnée mais c'est tout.

Dans le cas d'utilisation de couples de label + contrôle monovaleur, ce qui était à la base mon intention et j'y serais probablement revenu si Kopernic ne m'avait pas aidé, je ne crois pas que cela serais si simple et probablement que le client ou l'utilisateur serais limité et ou devrais revenir vers moi pour pouvoir voir sa demande et ou besoin réalisé.

Je pense que mon idée à du sens et n'est donc pas simplement un question de design. Je pense même que cette idée pourrait être utile à d'autres que moi.

Voilà, voilà.

De toute façon, je me répète mais ... . Je te remercie quand même de t'être penché sur mon problème .

[Kropernic]

Hello,

Tu as bien compris mon code.

Concernant l'intervention de sinople, je suis assez d'accord avec lui. Les arguments que tu lui avances en faveur du DataGridView ont du sens mais il y a "facilement"* moyen d'y remédier pour présenter la chose convenablement.

* il faut tout de même définir des contrôles personnalisés et c'est parfois bizarre à faire pour les débutants (en tout cas, ça l'était pour moi)

Voici comment je procède dans mes projets où les utilisateurs doivent encoder des infos clients pour lesquelles les possibilités de contact sont diverses et variées.

1 : Définir des contrôles personnalisés qui répondent à un besoin précis
Il s'agit de définir des textboxes particulières qui contiendront déjà du code chargé de vérifier la validité du format des données encodées. En général, une pour les numéros de téléphone, pour les adresses e-mail et une pour les adresses postales.

2 : Prévoir l'ajout dynamique de contrôle dans le formulaire de saisie
Il s'agit ici de faire "apparaître", à la demande de l'utilisateur, le ou les contrôles nécessaire pour encoder la donnée qu'il souhaite ajouter à la fiche signalétique du client. En pratique, l'utilisateur fait un choix dans une liste déroulante et clique ensuite sur un bouton de validation. Sur base du choix effectué, tu sais que tu dois faire apparaître, par exemple, une textbox pour téléphone s'il a choisi un type de donnée téléphonique dans la liste (tel bureau par exemple).
Là, tu affiches donc la textbox personnalisée qui sait comment valider le format du numéro encoder histoire qu'il ne puisse pas y écrire une adresse (y en a qui ne sont pas doué des fois).
Il n'y a plus qu'à prévoir un bouton d'annulation au cas où il se serait trompé de choix dans la liste déroulante ou s'il change d'avis et un bouton de validation pour quand il a finit d'encoder

3 : Ajouter la donnée encodée dans une liste
Une fois l'encodage effectué, il n'y a plus qu'à afficher tout ce que l'utilisateur à encoder dans une liste. Là, tu as le choix des contrôles : ListBox, ListView (je l'aime bien celui-ci), DataGridView, etc.
Sans oublier de stocker bien sûr tout cela dans un objet adéquat. Après, y a plus qu'à envoyer au stockage (base de données, fichier xml ou même bandes magnétiques si on est nostalgique ^^) pour persistance

De cette manière, même on invente un nouveau type de téléphone dans 5 ans, tout ce que tu auras à faire (à moins que ce nouveau bidule ait un format de numérotation bien spécifique), c'est d'ajouter ce type de téléphone dans la liste des types de téléphones dans la DB et pouf, l'application est capable de le gérer.