[Qt] Fermeture d'un tab de QTableWidget (et autres questions %)) - Page 4

Le problème est qu'il y a 2 versions surchargées du signal:

void currentIndexChanged(int index)
void currentIndexChanged(const QString &text)

et le compilateur ne sait pas laquelle tu veux. (C'est l'inconvénient de la nouvelle syntaxe.) Il faut donc écrire:
connect(MainWindow::ui->projectList, (void (QComboBox::*)(int)) &QComboBox::currentIndexChanged, this, &MainWindow::changeCurrentProject);

Et encore une fois, c'est bien ça et ça fonctionne, meric beaucoup

Dommage qu'ils n'aient pas plus explicité ce point dans la page de doc consacrée au sujet. Ou si l'explication y figure, je suis passé à coté tout à l'heure.

Merci encore

Y a-t-il un moyen pour compiler statiquement avec Qt Creator, sous Windows ?
J'ai ajouté ces lignes à mon project.pro :

CONFIG += staticlibLIBS += -LC:/Qt/Qt5.5.0/5.5/mingw492_32/lib -lQt5Core -lQt5Gui -lQt5Widgets

Ca me sort des étapes de compilation de ce genre :

g++ -c -pipe -fno-keep-inline-dllexport -O2 -frtti -Wall -Wextra -fexceptions -mthreads -DUNICODE -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB
-DQT_CORE_LIB -DQT_NEEDS_QMAIN -I..\FMetro -I. -IC:\Qt\Qt5.5.0\5.5\mingw492_32\include -IC:\Qt\Qt5.5.0\5.5\mingw492_32\include\QtWidgets
-IC:\Qt\Qt5.5.0\5.5\mingw492_32\include\QtGui -IC:\Qt\Qt5.5.0\5.5\mingw492_32\include\QtANGLE -IC:\Qt\Qt5.5.0\5.5\mingw492_32\include\QtCore
-Irelease -I. -IC:\Qt\Qt5.5.0\5.5\mingw492_32\mkspecs\win32-g++  -o release\main.o ..\FMetro\main.cpp

Et un linking comme ça :

g++ -Wl,-s -Wl,-subsystem,windows -mthreads -o release\FMetro.exe release/main.o release/mainwindow.o release/moc_mainwindow.o
 -lmingw32 -LC:/Qt/Qt5.5.0/5.5/mingw492_32/lib -lqtmain -lshell32 -lQt5Widgets -lQt5Gui -lQt5Core 

Pourtant, ça a bien l'air conforme à ce que je lis ici : http://stackoverflow.com/questions/20799161/how-to-make-qt-and-qtcreator-link-the-libraries-statically-instead-of-dynamic
Mais j'ai l'impression que je rate complètement ce que je veux faire, d'être bien à l'ouest, car le binaire résultant est toujours aussi petit. Où déconné-je ?

Merci bien.

Pour linker Qt statiquement, tu as besoin d'une version statique de Qt (des fichiers .a, et non pas des .dll.a qui ne sont que des wrappers d'importation pour les .dll). Ça m'étonnerait qu'elle soit incluse dans les binaires officiels. (D'ailleurs, nous ne proposons pas de Qt statique dans Fedora non plus.)

C'est une discrimination contre les utilisateurs qui préfèrent le _nostub !

J'essaye d'utiliser les ressources de Qt, en utilisant ça : http://doc.qt.io/qt-5/resources.html
Ca me donne des fichiers dans un pseudo-répertoire Sounds.
Comme ce sont des fichiers sont que je veux jouer dans un QMediaPlayer, je crée un QMediaContent avec une QUrl : m_media(QUrl::fromLocalFile(component->filename())).
component->filename() renvoie bien quelque chose de la forme :/Sounds/machin.mp3.

Et pourtant, ça ne marche pas, je n'arrive pas à jouer un son depuis ce fichier de ressources. Par contre, je joue n'importe quel autre mp3 sur mon disque dur (merci QMediaPlayer kifétoutouseul)
Apparemment, on construit facilement un QFile avec ce type de ressources, mais c'est une QUrl qu'il me faut, donc j'ai essayé divers trucs (transformations en QString intermédiaires etc), mais je suis en panne...

Donc ma question : comment construire une QUrl correctement à partir des fichiers de ressources ?

Merci d'avance.


EDIT -> mdr, j'ai trouvé par le plus grand des hasard, pour en faire une url, il suffit de rajouter "qrc" avant le chemin Sans faire exprès, j'ai cliqué droit sur un fichier de ressource, alors que je voulais ajouter un fichier au projet, et j'ai vu "copier l'url qrc:/blablabla.mp3"

Y a-t-il un moyen d'avoir des raccourcis clavier globaux, que recevront mon application meme quand elle n'a pas le focus ?
La visibilité maximum d'un raccourci semble etre pour l'application : http://doc.qt.io/qt-5/qt.html#ShortcutContext-enum
Qxt faisait ça, mais n'est plus maintenu : http://libqxt.bitbucket.org/doc/tip/qxtglobalshortcut.html
Comment faire alors ?

Merci d'avance.

Tu as le framework KGlobalAccel, mais ça marche seulement sous X11.

Ce n'est pas très difficile à faire marcher sous Windows non plus (https://msdn.microsoft.com/en-us/library/windows/desktop/ms646309%28v=vs.85%29.aspx), il faudra juste un peu de glue pour retranscrire ça sous forme d'événement Qt.

Kevin -> Ok merci, mais en effet, c'est inutile dans mon cas.

Zerosquare -> J'ai vu des exemples de ce type : http://stackoverflow.com/questions/20153848/sytem-wide-hotkey-shortcutwindows-qt-prevent-window-lock

Ca a l'air de marcher, mais quand je vois #include "stdafx.h", j'imagine que ça signifie MSVC obligatoire.
C'est pas que ça me dérange, mais j'utilise Qt Creator/Designer, qui est très bien foutu pour coder du Qt, précisément. C'est l'outil parfaitement adapté. Je perdrais énormément à switcher sous MSVC, et pourtant j'ai impérativement besoin de raccourcis globaux (c'est 50% de l'intérêt de mon programme).

Donc qu'est-ce qui serait une solution ? J'utilise Qt Creator/MinGW, mais QtCreator/MSVC serait mieux ? Les mêmes fonctionnalités mais la compatibilité avec l'API Windows en plus ? Si ça suffit, je switche immédiatement. Je n'utilise MinGW que par habitude, et aucune extension GNU.

À première vue, je ne vois rien dans le code qui nécessite stdafx.h, tu dois pouvoir utiliser windows.h à la place (et donc garder Qt Creator/Designer).

Par contre sa solution me semble un peu téméraire... je ne connais quasiment rien à Qt, mais apparemment il remplace l'appel à la fonction app.exec de Qt par la boucle classique de récupération/traitement des messages Windows. À moins qu'il soit documenté quelque part que app.exec sous Windows ne fait rien d'autre que ça, c'est pas correct.

J'aurais plutôt utilisé du subclassing de fenêtre : tu remplaces la fonction de traitement des messages de ta fenêtre par la tienne. Du coup tu vois tous les messages arriver, et tu peux faire ce que tu veux avec : si c'est un message qui t'intéresse pas, tu refiles le bébé en appelant la fonction de traitement d'origine, mais tu peux aussi exécuter du code avant ou après, ou ne pas le transmettre du tout, etc. Normalement Qt devrait n'y voir que du feu.

Il y a un exemple ici : https://msdn.microsoft.com/en-us/library/windows/desktop/ms633570%28v=vs.85%29.aspx#subclassing_window

Par contre, je ne sais pas si appeler des fonctions Qt depuis ce contexte est safe ou pas. Perso je choisirais la sécurité, en émulant des messages de touche "normaux" (ceux qui sont envoyés quand ton appli a le focus et qu'on appuie sur une touche) quand je reçois un message de hotkey. Du coup tu n'auras rien de spécial à faire côté Qt, tu pourras gérer tes hotkeys exactement comme des touches "normales".

Tiens on va voir ce qu'en pense GC :

Merci beaucoup pour ton explication. Je vais déjà essayer de trouver ce foutu windows.h. La structure d'une installation de MSVC est dantesque

Côté Qt, je lis ça :
It is necessary to call this function to start event handling. The main event loop receives events from the window system and dispatches these to the application widgets.Ok, on s'en serait douté. Je vais voir les sources.

edit -> et voilà : https://github.com/qtproject/qtbase/blob/dev/src/corelib/kernel/qeventdispatcher_win.cpp
Moi, j'ai trouvé la réponse. Dis-moi ce que t'en penses, on va voir si t'es bon. #pourvuksapasse#

Pff faire interagir du Qt et du Win32… C'est quand même un peu chercher les emmerdes

• stdafx.h ça "ne sert à rien", c'est juste utilisé pour les en-têtes précompilées de VC++, en dehors de ça c'est un fichier .h tout à fait normal (qui inclut d'autres .h)
• Le subclassing c'est bien mais c'est plutôt une technique adaptée pour les cas où tu n'as pas accès au code de la fenêtre que tu veux bidouiller.
• En cherchant sur Google, j'ai trouvé http://doc.qt.io/qt-5/qabstractnativeeventfilter.html, je sais pas du tout comment ça s'utilise, mais j'aurais tendance à penser que c'est plus adapté.

Poutée mais comment tu fais toi, je cherche depuis hier
Bravo en tout cas, ça a l'air d'être fait pour ce que je veux. Cependant, faut que je trouve où le coller dans mon code (je dois le redéfinir dans QApplication, QCoreApplication, ou QGuiApplication probablement).

Merci !

GoldenCrystal (./104) :
Pff faire interagir du Qt et du Win32… C'est quand même un peu chercher les emmerdes

Quant à ça : j'ai installé MSVC 2015, j'ai rien compris au 50 fichiers qui font partie d'un fichier de base. J'ai pas trouvé comment designer un simple widget/contrôle/whatever graphique. Je laisse couler. Qt, ça se code avec du glisser/déposer, ça c'est de l'outil.
Et j'ai passé pas mal de temps à l'apprendre, et je connais rien à Windows. D'où mon choix, meme si techniquement, on peut y redire ci ou ça.

./105 > Ce topic a l'air de donner la réponse: http://www.qtcentre.org/threads/56438-help-with-QAbstractNativeEventFilter
(Pour l'histoire: J'ai bêtement cherché "qt handle custom windows message" sur Google, ce qui m'a mené à StackOverflow, ce qui m'a mené à QCoreApplication:winEventFilter, ce qui m'a mené à chercher "qt5 wineventfilter", ce qui m'a mené à un topic sur le site de qt, ce qui m'a mené au nom de la fonction, puis via Google, à la page de la doc )

./106 > Oui je sais bien

Ouais pour le subclassing, c'était pour ne pas avoir à trifouiller dans les entrailles de Qt. Mais ta solution est meilleure

Folco > windows.h est fourni avec MinGW.

Attends, tu veux dire que j'ai désinstallé Qt5/MSVC13, installé Qt5/MSVC13, et MSVC13 lui-même pour des prunes ?
Je suis quand même le roi des nuls c'est pas possible

Autre question, ça vient d'où ça : xcb_generic_event_t ? C'est dans la page de doc pointée par GC.
Je vais avoir ça dans windows.h ? (Enfin, son équivalent, parce que là ça fleure bon le X11)

QAbstractNativeEventFilter Class:
The type of event eventType is specific to the platform plugin chosen at run-time, and can be used to cast message to the right type.

On X11, eventType is set to "xcb_generic_event_t", and the message can be casted to a xcb_generic_event_t pointer.

On Windows, eventType is set to "windows_generic_MSG" for messages sent to toplevel windows, and "windows_dispatcher_MSG" for system-wide messages such as messages from a registered hot key. In both cases, the message can be casted to a MSG pointer. The result pointer is only used on Windows, and corresponds to the LRESULT pointer.

On Mac, eventType is set to "mac_generic_NSEvent", and the message can be casted to an EventRef.

On Blackberry (not plain QNX) eventType is set to "bps_event_t", and the message can be casted to a bps_event_t pointer.

C'est indiqué dans la doc, tu as juste à gérer le cas qui t'intéresse

Merci. Là c'est même plus de la connerie, c'est de l'aveuglement (et de la fatigue)
Un très grand merci

Si tu arrives à faire interagir RegisterHotKey avec Qt, je suis sûr que le projet KDEWIN apprécierait un portage de KGlobalAccel.

Je regarderai. ^^
Mais si moi j'y arrive, c'est que c'est quand même à la portée d'à peu près tout le monde, non ? ^^

Pourquoi quand j'écris ça :

bool NativeEventFilter::nativeEventFilter(const QByteArray& eventType, void* message, long*)
{
    if (eventType == "windows_dispatcher_MSG")
    {
        return true;
    }
    return false;
}

J'ai cette erreur :
NativeEventFilter.cpp:10: erreur : no match for 'operator==' (operand types are 'const QByteArray' and 'const char [23]')
Par contre, si j'inclus <QLocalServer>, ça passe, operator== semble défini pour mes besoins (je me suis rendu compte de ça en googlant). Quelle est la solution propre, qui évite d'inclure un header random ?


EDIT -> Bon oubliez, ça marche sans que je comprenne pourquoi...


Maintenant, j'ai besoin d'une explication par rapport aux hotkeys.
- j'ai dérivé http://doc.qt.io/qt-5/qabstractnativeeventfilter.htmlQAbstractNativeEventFilter], je l'ai installé avec [url=]installNativeEventFilter comme m'a dit Golden
- j'ai registeré (c) ue hotkey comme le dit Monsieur MS

J'ai implémenté nativeEventFilter comme ça :

bool NativeEventFilter::nativeEventFilter(const QByteArray& eventType, void* message, long*)
{
    if (eventType == "windows_dispatcher_MSG")
    {
        MSG* msg = static_cast<MSG*>(message);
        if (msg->message == WM_HOTKEY)
        {
            emit hotkeyPressed();
            return true;
        }
    }
    return false;
}

En déboguant, je vois bien que j'intercepte des message de type "windows_dispatcher_MSG", par contre je dois déconner pour lire le message.
En tout cas, mon app ne réagit pas au signal émis, et je crois avoir pourtant bien fait ma connexion.
C'est ma méthode qui est mal impémentée ?

Je continue à chercher des exemples de code via google. Je suis content, je sens que j'y suis presque, et c'est le dernier truc à faire sur mon app (mais c'est aussi la feature qui fait 50% de l'app )

Tu as regardé ce qui passe par ta méthode ? (C'est quoi comme messages: WM_COMMAND, WM_PAINT, … ? Est-ce qu'il y a toujours un HWND rattaché ou non ?)
Et est-ce que tu enregistres bien ta hotkey sur le thread d'interface de Qt ? (PS: Tu peux montrer le code d'appel de RegisterHotKey ?)

    // Install a native event filter and register a hotkey
    NativeEventFilter nef;
    filter = &nef;
    app.installNativeEventFilter(filter);

    if (!RegisterHotKey(NULL, 1, MOD_ALT | 0x4000, 0x42)) // #define 0x4000 MOD_NOREPEAT, 0x57 == W
    {
        QMessageBox::critical(0, "Fatal error", "Unable to register hotkey");
        return -1;
    }

Et là je me rends compte que HWND je comprends pas ce que c'est, et qu'un thread d'interface je sais pas comment le trouver ^^
C'est quoi, c'est un pid ?


hmmm -> je vois ici de quoi trouver le thread : http://stackoverflow.com/questions/977653/gui-thread-detecting-in-the-qt-library
Mais pas de trace de méthode thread() dans QCoreApplication. D'ailleurs, ça renverrait un QThread, pas ce qu'attend précisément Windows à mon avis ><

Pour le détail de la structure MSG: https://msdn.microsoft.com/en-us/library/windows/desktop/ms644958(v=vs.85).aspx ^^ (hwnd c'est le premier membre documenté)
Le thread d'interface, c'est le thread qui exécute ton code d'interface. (Genre la boucle de messages, par exemple)
Bien que sous Windows, chaque thread puisse avoir sa propre boucle de messages, en général tu n'en as qu'un seul et c'est de facto le thread d'interface
(En général, c'est même aussi le thread principal, mais ce n'est pas obligatoire ^^)

Avec Qt, je ne sais pas comment ça fonctionne à ce niveau là, mais il faut que tu sois sûr de faire ton appel à RegisterHotKey à l'intérieur du thread d'interface. (Par exemple en réagissant à un clic sur un bouton: Sauf bidouille, le code qui gèrera le clic sera exécuté dans le thread d'interface)

Donc il faut que j'appelle RegisterHotkey dans le constructeur de ma MainWindow, par exemple ?

Mais est-ce que le NativeEventFilter de Qt gère aussi les messages "de thread" (non associés à une fenêtre) ?

J'associerais plutôt la hotkey à la fenêtre principale de l'application. Pour ça tu dois récupérer son HWND (c'est un handle Windows qui identifie les objets d'interface tels que les fenêtres, les boutons...). Apparemment il suffit de faire simplement (HWND)this->winId().

Un grand merci pour tout. Je verrai ça demain, parce que demain c'est la dernière journée de taf, et après ça ira mieux \o/