À 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".