Discussion :

[lbensch]

Bonjour,

J'ai des fenêtres qui jusqu'à maintenant s'ouvrait avec ShowDialog, or, mes utilisateurs se plaignaient de ne plus avoir accès aux autres fenêtres. Du coup, j'ai surchargé la méthode ShowDialog() pour effectuer un Show() avec un boucle pour attendre un DialogResult.

Code :

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

1
2
3
4
5
6
7
8
9
10
public new DialogResult ShowDialog(IWin32Window owner)
{
    Show(owner);
    while (DialogResult == DialogResult.None)
    {
        System.Threading.Thread.Sleep(100);
        Application.DoEvents();
    }
    return DialogResult;
}

Cette fonction réponds au besoin, cependant, j'ai un petit soucis. Lorsque la fenêtre s'ouvre, elle n'a pas le focus, je suis obligé de cliquer une fois pour activer la fenêtre, puis une autre fois pour 'Ok'.

Est-ce que ma méthode est bonne, que dois-je faire pour avoir le focus immédiatement à l'ouverture (j'ai bien évidemment essayé BringToFront(), Focus(), Activate() mais rien)

Merci de bien vouloir m'aider.

[Guulh]

ShowDialog sert à donner une info à l'user ou à lui poser une question. ca veut dire que l'appli a besoin tout de suite, MAINTENANT, d'une réponse, et c'est pour ça que les autres fenêtes sont rendues inaccessibles.

Quelle est la nature de la fenêtre que tu affiches ? As-tu besoin du dialog result de suite ? Parce que sinon, un Show standard suffit.

[lbensch]

Comme je l'ai dis, le code existe déjà. Il y a environ 500 ouvertures de fenêtre modale. Je ne peux donc pas passer partout pour remplacer par Show() avec des events sur le "Annuler" ou le "Ok"

Car le besoin est de faire passer ces fenêtres semi modale, je m'explique. Un traitement ouvre une fenêtre modal et attend son résultat pour continuer, cependant, l'utilisateur dois pouvoir faire autre chose a coté dans l'application.

Actuellement, un ShowModal bloque toute l'application. Mon application est multi-form et il faut que l'utilisateur puisse passer de l'une à l'autre même s'il est en cours de saisie sur l'une des fenêtre "semi-modale"

[ClaudeBg]

Comme je l'ai dis, le code existe déjà. Il y a environ 500 ouvertures de fenêtre modale.

Comme le dit Guulh, tu dois ouvrir tes fenêtres avec Show() et t'abonner à un évènement lorsque l'utilisateur valide son choix.

Note que 500 fenêtres qui s'ouvrent en mode modal, ça sent quand même un peu le problème de conception.

Je ne peux donc pas passer partout pour remplacer par Show() avec des events sur le "Annuler" ou le "Ok"

Ben, tu demandes en fait à transformer un comportement de fenêtre modale par un comportement de fenêtre non modale.
La bonne pratique est donc d'ouvrir ces fenêtres en mode non modal et d'ajouter des évènements. Le reste, à mon avis, ce serait du "bricolage", surtout en utilisant le genre de méthode que tu décris.

Application.DoEvents();

Attention avec DoEvents, parce que les effets de bords peuvent être vicieux, genre rendre la main à un utilisateur qui vient de lancer une méthode en cliquant sur un bouton, et à qui le DoEvents permet de recliquer une seconde fois avant que l'action précédente ne soit terminée.

Un "DoEvents" ajouté comme ça à la volée sans recontrôler tout ce que ça implique (bonjour le boulot avec toutes tes fenêtres), ça me semble une solution susceptible d'amener un grand nombre de bugs aléatoires difficiles à détecter (le code n'a pas été conçu pour éviter les réentrances).

Du reste, il faut également vérifier que rendre la main à l'utilisateur avec des fenêtres qui ont été conçues pour être modales à l'origine (et donc blocage volontaire des autres fenêtres) est judicieux (l'utilisateur veut souvent plein de choses contradictoires) et réalisable sans risques.

A+
Claude

[lbensch]

Comme le dit Guulh, tu dois ouvrir tes fenêtres avec Show() et t'abonner à un évènement lorsque l'utilisateur valide son choix.

Note que 500 fenêtres qui s'ouvrent en mode modal, ça sent quand même un peu le problème de conception.

En fait, c'est la même fenêtre mais les paramètres changent, cette fenêtre modale est un assistant, chaque fois que mon utilisateur veut effectuer une modification j'ouvre cette assistant et je fais défiler des pages différentes selon le traitement. Du coup, tous les traitements passent par cet appel.

Ben, tu demandes en fait à transformer un comportement de fenêtre modale par un comportement de fenêtre non modale.
La bonne pratique est donc d'ouvrir ces fenêtres en mode non modal et d'ajouter des évènements. Le reste, à mon avis, ce serait du "bricolage", surtout en utilisant le genre de méthode que tu décris.

Je sais que c'est du bricolage et crois moi, je n'aime pas. Mais je n'arrive pas à imaginer comment remplacer un code initialement prévu pour être modal comme :

Code :

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

1
2
3
4
5
6
7
using (Assistant MyAssistant = new Assistant(TraitementEnum.Traitement1)
{
    if (MyAssistant.ShowDialog() == DialogResult.OK)
    {
        //Traitement
    }
}

Attention avec DoEvents, parce que les effets de bords peuvent être vicieux, genre rendre la main à un utilisateur qui vient de lancer une méthode en cliquant sur un bouton, et à qui le DoEvents permet de recliquer une seconde fois avant que l'action précédente ne soit terminée.

Un "DoEvents" ajouté comme ça à la volée sans recontrôler tout ce que ça implique (bonjour le boulot avec toutes tes fenêtres), ça me semble une solution susceptible d'amener un grand nombre de bugs aléatoires difficiles à détecter (le code n'a pas été conçu pour éviter les réentrances).

J'en suis conscient mais comment faire autrement ?

[ClaudeBg]

Je sais que c'est du bricolage et crois moi, je n'aime pas. Mais je n'arrive pas à imaginer comment remplacer un code initialement prévu pour être modal comme :

En fait, remplacer une stratégie modale par une autre non modale, ça impose de revoir une partie de la structure du fonctionnement général. Ca peut être lourd mais je vois mal comment simplement "forcer" le modal à ne plus l'être sans en vérifier les implications, et sans modifier ce qui doit l'être.

Si c'est un gros boulot, il faut voir si la demande est réaliste et pertinente (c'est aussi le boulot du développeur que de "recentrer" l'utilisateur), et si oui il faut traiter le problème avec le soin qu'il mérite.

J'en suis conscient mais comment faire autrement ?

Mon avis, qui vaut ce qu'il vaut, c'est que :

- Soit tu dis à l'utilisateur : votre demande n'est pas réaliste ni pertinente pour les raisons suivantes (avec des gants, évidemment)

- Soit tu dis à l'utilisateur: votre requête est pertinente mais ça nécessite de revoir une grosse partie du programme, et le coût est estimé à xx heures de travail. Et ensuite tu modifies correctement

MAIS, toujours de mon avis, dire "ok" à l'utilisateur et "bricoler" du code pour qu'il semble fonctionner est une très mauvaise idée, parce que si après tu as des bugs on te lancera à la figure (avec raison) que ces bugs sont de ta faute et qu'avant il n'y avait aucun problème.

Mieux vaut refuser un travail que de le réaliser dans de mauvaises conditions, et si l'accepter est obligatoire, alors il faut le faire dans les règles de l'art.

Et vu que ta méthode est très délicate, pour ma part je n'utiliserais pas ça parce que tôt ou tard tu vas réentrer dans la même méthode et alors vont commencer les problèmes.

Mais bon, ça c'est ma façon de travailler, chacun son point de vue


A+
Claude

[lbensch]

Alors en fait, en cherchant un peu plus en avant, je me suis rendu compte que le soucis venait de mes composants (DevExpress) en reprenant mon code avec des composants .Net 2.0, je n'ai pas ce soucis et le focus et bon.

J'ai donc envoyé le bébé aux gentils développeurs de DevExpress afin qu'ils me trouve la solution puisqu'il s'agit d'un bug chez eux.

Ce qui, soit dit en passant, confirme bien que ma solution n'est pas forcément du bricolage, elle me permet d'avoir un comportement modal avec une fenêtre non modale.

Je tiens quand même à vous remercier d'avoir essayé de m'aider.

[ClaudeBg]

De rien, bonne chance pour la suite

A+
Claude