10
votes

QT GUI App: Avertissement si QObject :: Connect () a échoué?

J'ai récemment migré mon projet QT de Linux à Vista, et maintenant je débogage des signaux aveuglément.

sur Linux, si QObject :: Connect () échoue dans une construction de débogage, je reçois un message d'avertissement sur stardr. Sous Windows, il n'y a pas de sortie de console pour les applications de l'interface graphique, uniquement un appel de sortieDebugstring.

J'ai déjà installé DEBUGVIEW , et il attrape mon propre Qdebug () Sortie joliment, mais toujours aucun avertissement sur les signaux défaillants.

Une solution possible consisterait à utiliser l'autocomplete de QTCreator pour les signaux, mais j'aime bien Eclipse et utiliser les deux est un pita. Des idées sur la manière d'obtenir des informations sur le signal / emplacement au moment de l'exécution?

Edit: Je viens de réaliser Connect () renvoie Bool, qui résout le problème immédiat, moche telle qu'elle peut être. Cependant, cela ne résout pas les cas où qmetaObject :: connectslotsbyname () échoue, et celui-ci fonctionne automatiquement avec des widgets.


0 commentaires

7 Réponses :


1
votes

Si vous utilisez Visual Studio, vous pouvez ajouter une console à n'importe quelle application QT.
Accédez aux propriétés du projet, sous Linker-> Paramètres Modifiez le "sous-système" pour dire "console"

Recompilez maintenant votre code et vous allez apparaître la console lorsque vous activez l'application. Si vous voulez vous en débarrasser, changez à nouveau le sous-système sur «Windows»

Je ne suis pas sûr si cela est éventuellement avec qtcreator.

Une autre option consiste à utiliser des appels Win32 natif tels que FixationConsole () Pour créer manuellement la console et la joindre à STDOUT et STDERR. Voir ici pour plus de détails à ce sujet.


0 commentaires

0
votes

Vous pouvez rediriger stdout / stardr assez facilement: faire une classe qui dérive de STD :: basic_streambuf et surcharges xsputn () et débordement (), puis utilisez, par exemple, STD :: cerr.rdbuf (instanceofyourredirecclass) pour rediriger tout Stdrit OutPut à une fonction de rappel que vous fournissez.

Voici une version simplifiée de ce que j'utilise; Selon vos besoins, vous devrez peut-être ajouter une logique supplémentaire au violon avec la manipulation des caractères de fin de ligne, etc. xxx

utilisation: xxx


1 commentaires

Est-ce que cela redirige aussi de stdout avec Printf () ou juste std :: cout? Je soupçonnerais ce dernier, ce qui le rend moins utile dans ce cas.



2
votes

Mon approche consiste à reculer le moteur de journalisation QT avec qinstallmsghandler et faites ma propre journalisation à la fois au fichier et à la console.

De cette façon, je sais que tous les messages d'erreur / avertissement sont enregistrés et je peux les analyser même après que le programme ait cessé d'exécuter.

P.s: QTCreator intercepte ces messages et les affiche dans le volet de sortie d'application.


1 commentaires

Merci, cela aide certainement, bien que je commence à croire que la DLL QT est tout simplement silencieuse. Je peux déjà voir la sortie Qdebug (), donc en théorie, il aurait dû être montré à DEBUGVIEW.



10
votes

Appelez la fonction statique QERXESSAGE :: QTHANDLER ().

Selon la documentation, celui-ci 'installe un gestionnaire de messages à l'aide de QInstallMsGHandler () et crée une QErressage qui affiche les messages qdebug (), qfarning () et qfatal () et qfatal (). '. XXX

... et pour ce que cela vaut, voici quelques signaux et emplacements de débogage des suggestions que j'ai compilées: http://samdutton.wordpress.com/2008/10/03/debugging-signals-and-slots-in-qt/


0 commentaires

1
votes

Vous pouvez utiliser l'IDE QT officiel: QTCreator . Il contient une console de sortie où vous verrez tout problème avec des signaux. Les erreurs de signalisation sont émises dans la course de débogage et de sortie.


0 commentaires

4
votes

La solution que j'aime pour cela est de définir xxx

dans l'environnement du programme lorsque vous avez débogué. Cela fait de l'accident de programme, vous donnant une belle arrière-plan, surtout si vous exécutez le code dans un débogueur. Si vous ne voulez pas le crash, voir la réponse ci-dessus.


2 commentaires

Pas de backtrace, malheureusement, avec Mingw: seule "une application a ... de manière inhabituelle" (éventuellement cela fonctionne mieux avec MSVC).


Je préfère cela comme la solution (dans VS 2012, le CallStack est affiché) car redéfinir Connect ne fonctionnait pas, surtout si le problème de liaison est dans une DLL différente



1
votes

La plupart du temps, je veux seulement une attention particulière de temps en temps: Il suffit de mettre un point d'arrêt sur la ligne "int DummyPutbrebrebrebrebrebrebrebrebrebrebrebrebrebrebrebrebrebrebrefshpoint = 23;" xxx


0 commentaires