Discussion :

[DakM]

Bonsoir !

Le problème:
Reussir à afficher de facon dynamique plusieurs ecrans differents en utilisant une classe pour chaque ecran.
note: Etant donné que l'erreur ne viens pas de la bibliotheque que j'utilise (SFML), cela est un probleme de conception !

Approche: heritage
Chaque classe ecran herite d'une classe mere purement virtuelle:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class Screen
{
    public :
        Screen() {};
        ~Screen() {};
        virtual int Run (sf::RenderWindow& App) =0;
 
        Perennials* m_perennials;
        ClientSocket* m_tcpsocket;
        ClientSocket* m_udpsocket;
};

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
class SplashScreen: public Screen
{
    public:
        SplashScreen(Perennials* wd, ClientSocket* tcps)
        {
            m_perennials = wd;
            m_tcpsocket = tcps;
        }
        ~SplashScreen() {}
        int Run (sf::RenderWindow& App);
 
        static const int ID = 1;
 
    private:
        // Common structure
        //sfg::SFGUI m_sfgui;
        //sfg::Desktop desktop;
        sf::Event event;
        sf::Clock clock;
};

Donc dans Run(), il se passe des choses... et a un moment je vais retourner un int, qui est censé nous amener a un autre ecran !
Donc, voici le main:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
        // std::vector<Screen> Screens; et on y ajoute nos ecrans.
    int iscreen = 0, temp;
    while(iscreen >= 0)
    {
        // On lance l'affichage
        temp = Screens[iscreen]->Run(App);
        // On vient de sortir de la boucle de Screen::Run()
        // Si temp est different, on met a jour les variables
        if(temp != iscreen)
        {
            delete Screens[iscreen];
            App.clear();
            iscreen = temp;
        }
    }

Le probleme de cette approche: ecran noir.
Si je fais simplement un SplashScreen ss(...); ss.Run(App); l'écran marche parfaitement.
Donc... un gros soucis ...

Avant que les modos vire mon sujet dans 2D>SFML: Laurent Gomila pense que c'est bien un probleme de conception... !

merci d'avance, nico

[koala01]

Salut,

Bon, déjà, je déclarerais le destructeur de la classe Screen virtuel, pour que le comportement de destruction puisse s'adapter correctement au type réel de l'écran (étant donné que tous tes écrans vont passer... pour etre de type Screen).

Ensuite, je placerais les membres m_perennials, m_tcpsocket et m_udpsocket dans l'accessibilité private et je rajouterais les fonctions qui permettent de manipuler ces membres de manière transparente pour l'utilisateur, éventuellement (pour les fonctions dont le comportement doit s'adapter) sous forme de fonctions virtuelles, de manière à ce que l'utilisateur (ou les fonctions propres aux différents types d'écran) n'aie(nt) pas besoin de connaitre les types Perennials et ClientSocket pour travailler (respect de la loi dite "demeter" : n'exposons pas les détails d'implémentation )

Enfin, je me dis que ce n'est pas à l'écran (et surtout pas à la fonction run) de déterminer quel est l'écran suivant qui devra être affiché, ce que laisse entrevoir le code que tu donnes

Au pire, tu remplis ton vecteur d'écran exactement dans l'ordre dans lequel tu souhaites les faire s'afficher, puis tu boucle simplement sur tes écrans, ce qui permettra d'éviter qu'un écran ne te demande d'en afficher un qui... a déjà été détruit (parce que deux types d'écrans auront renvoyé un index identique )

En outre, je ne vois pas vraiment ce que static const int ID, en membre publc, peut bien venir faire dans l'histoire...

A moins que tu ne prévoies de faire dériver certains de tes écrans de SplashScreen

Mais, dans se cas, le fait que ce soit un membre statique (et publique, qui plus est) constant fait que, de toutes manières, tous les type qui pourraient en hériter auront tous une id égale à... 1, ce qu, a priori, ne ressemble pas à grand chose étant donné que ID est, dans la "culture populaire", synonyme de facteur discriminant (comprend : permettant d'identifier un objet de manière unique et non ambigüe).

Tout ce qui précède n'entre pas vraiment dans le cadre de "problème de conception", mais plutot dans le cadre de "bonnes pratiques qu'il est préférable de respecter" et est basé, essentiellement, sur des déductions (peut etre fausses) faites sur base du code présenté

Maintenant, passons aux choses sérieuses...

Je ne vois nulle part, dans le code que tu présente, ni dans ton approche, un problème de conception : on peut, effectivement, dire que les différents types d'écran que tu crées sont, effectivement, des "écran spécialisés" et qu'ils peuvent donc tous " passer pour etre de type Screen" tout en ayant le comportement adapté lorsque l'on invque la fonction run.

Par contre, il serait intéressant de voir la manière dont tu as créé ta hiérarchie de classes, et, surtout, il serait intéressant de voir si certaines classes n'héritent pas de certains "écrans spécialisés" alors qu'elles auraient tout simplement du hériter de Screen.

Ensuite, il faudrait voir ce que chaque écran est sensé faire au sein de la fonction run et la manière de mettre cela en oeuvre.

Mais, pour répondre plus précisément, il nous manque pas mal d'infos, que toi seul peut nous apporter

[Invité]

salut,

Code :

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

delete Screens[iscreen];

Celle la me semble inconvenue, car tu n'as aucun intérêt à supprimer ton Screen. c'est pas un pointeur d'une part, et d'autre part, si tu as tout pu stocker dans le vecteur, j'imagine que tu peux les garder jusqu'à la fin du traitement et ils seront supprimés comme des grands/pas de risque de clash sur un accès sur un des éléments dans ta boucle.

Code :

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

App.clear();

Vu qu'on a pas vu la gueule de ton implémentation, c'est assez dur d'affirmer avec conviction, mais ne serait-ce pas celle-ci qui rafraichit ton écran? de fait run tente d'afficher quelquechose d'aussitot effacé.