Discussion :

[Astraya]

Bonjour,

J'ai un souci avec l'utilisation d'un QMessageBox dans un custom QGraphicsItem ( avec paint surcharger ).
Si j'appelle QMessageBox dans le QGraphicsItem::paint ( dans un assert maison ) j'ai plusieurs soucis ensuite:

1- Soit le QMessageBox ne retourne jamais!
2- Soit le fait d'utiliser le QPainter après le QMessageBox crash avec un "Access violation reading" dans Qt5Guid.dll

L'utilisation de QMessageBox est-elle interdite ici? pourquoi?

Exemple de code:

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
 
void Rect::paint(QPainter *Painter, const QStyleOptionGraphicsItem *Option, QWidget *Widget /* = 0 */)
{
    HD_UNUSE(Option);
    HD_UNUSE(Widget);
 
    QMessageBox::warning(Widget, "titre", "text");
 
    if (mDirtyShape)
    {
        ClearShape();
        ShapeRect(pos(), mSize);
    }
 
    Painter->setPen(mPen);
    Painter->setBrush(mBrush);
    Painter->drawPath(mPainterPath);
}

Merci

[ymoreau]

La fonction paint va être appelée à chaque fois que ton widget doit être dessiné à l'écran, donc assez souvent ! Il est important de réduire autant que possible le temps d'exécution dans ce code là.

En l'occurrence créer une boite de dialogue prend du temps. Mais le problème est de toute façon que créer une boite de dialogue crée une nouvelle boucle d'évènement et bloque l'exécution du code courant (y compris la boucle d'évènement qui a appelé ton paintEvent). Bloquer le code qui dessine les widgets n'est pas une bonne idée, pour seulement tracer une erreur ou juste un log tu peux utiliser QDebug.
Pour informer l'utilisateur d'un problème : cela devrait être fait en amont quand l'état du QGraphicsItem est modifié et est incorrect (par exemple une propriété changée pour une valeur incorrecte). Car la fonction paint risque d'être appelée un grand nombre de fois, et ce n'est pas utile d'avoir 100 fois un message d'erreur, c'est à la source qu'il faut signaler le problème.

[Astraya]

Bonjour et merci,

Je sais bien que le paint est appelé souvent, le MessageBox est en fait une macro assertion qui réalise d'autres trucs en plus en cas d'erreurs ( callstack, log... )
Je comprends la problématique de mettre ça dans le paint mais c’était plus pour de la validation en exécution debug et pas en release pour le développeur. C'est loin d'etre le code définitif mais je me suis rendu compte de ce problème dans mes tests rapides.

Mais si le MessageBox crée sa propre boucle d'event et bloque le code courant, pourquoi le code ne reprend pas tout les temps lorsque l'on femer le MessageBox. Il devrait prendre la fonction de dessin.

[ymoreau]

A priori le code reprend son cours à chaque fois que tu fermes la message-box, et comme tu l'as dit il crashe à l'utilisation du QPainter.
Je ne suis pas certain de ce qu'il se passe, de la raison du crash. Mais un principe important en Qt est d'avoir un état stable lorsque l'on crée une nouvelle boucle d'évènements, car la nouvelle boucle d'évènements va aussi traiter les nouveaux évènements arrivant et l'état de l'application (au niveau des évènements) pourra être différent après l'ouverture de la message-box. En l'occurrence, peut être que la mise à jour graphique est poursuivie dans la nouvelle boucle d'évènements et le QPainter détruit. Quand tu reprends le cours d'exécution tes pointeurs ne sont plus valides.

[Astraya]

A je comprends mieux pourquoi le comportement est aussi instable.
La boucle d’événement de la QMessageBox remplace donc complétement la boucle principale... Sans doute dans ce cas fixable avec un parent dans le QWidget... Je vais tester ca.

Encore merci pour tes lumières.