Discussion :

[meynaf]

Bonjour,


J'ai plein d'ennuis avec la console windows.
(C'est bizarre, je m'attends à un ironique "non, t'es sûr ?" comme réponse ici...)

Le but est d'avoir une fenêtre de console qui ne s'ouvre que si on s'en sert (c'est à dire dès sa 1ere utilisation, qui peut d'ailleurs ne jamais arriver).
Pour ce faire, il ne faut pas utiliser une appli de type console, faute de quoi elle s'ouvrira, qu'on le veuille ou non.
J'utilise donc AllocConsole, que je n'appelle qu'au moment voulu.

Mais, si le programme a été lancé en ligne de commande, c'est à dire depuis cmd.exe, j'aimerais bien que ce soit dans cette fenêtre-ci que ça se passe.
On peut faire ça ainsi : AttachConsole(ATTACH_PARENT_PROCESS).
Et c'est là que tout part en sucette : le "prompt" revient dès que le programme est lancé, les sorties arrivent n'importe comment, et les entrées sont confondues avec des commandes tapées.

D'autre part, impossible d'attraper correctement ni le ctrl-c, ni le clic sur la fermeture : c'est détectable, mais ça tue l'appli !
Je n'ai pas non plus trouvé de truc pour afficher/effacer le curseur (enfin si, mais ça marche pas).
Et je ne vous parle pas d'essayer d'avoir deux fenêtres de console en même temps...

Avez-vous des solutions ?
J'en viens à envisager sérieusement d'écrire mon propre système d'entrée-sortie texte avec une fenêtre ouverte à la main !

[meynaf]

On dirait que ce sujet ne passionne pas les foules...

J'ai en tous cas trouvé comment faire pour le curseur, certes le point le moins important du problème.

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
// affiche/efface curseur console - val=0 efface, <>0 affiche
void CslCurs(int show) {
	static CONSOLE_CURSOR_INFO cci;
	HANDLE hndl = GetStdHandle(STD_OUTPUT_HANDLE);
	if (hndl == NULL || hndl == INVALID_HANDLE_VALUE) return;	// y a pas
	BOOL retn = GetConsoleCursorInfo(hndl, &cci);
	if (retn) {		// si info indisponible, ben on ne fait rien : cette fct n'est pas critique
		cci.bVisible = show ? TRUE : FALSE;
		retn = SetConsoleCursorInfo(hndl, &cci);
		// retn sans importance ici en fait - on ne voit pas bien quoi faire en cas d'erreur...
	}
}

[Madmac]

On dirait que ce sujet ne passionne pas les foules...

Au contraire, mais Microsoft n'a jamais été très généreux avec les informations sur la façon d'utiliser la console et sur la façon de lancer une application utilisant la console. Pour une raison qui m'est inconnu le démarrage prend un temps fou.

Je visitais le forum microsoft pour tenté une solution à ce sujet.

[Médinoc]

Il faut dire que Windows n'a jamais vraiment été prévu pour les programmes "hybrides" qui à la fois ont et n'ont pas une console. Le plus proche que Microsoft ait fait, c'est ILDASM, un programme console qui fait un FreeConsole() quand il est lancé sans paramètre.

J'ai fait à une époque un programme qui ouvrait une console à la demande, mais c'était un programme graphique à la base, qui ne cherchait jamais à s'attacher à la console existante du parent. Et comme c'était à l'époque Windows 9x, j'ai été tellement mis en rogne par l'impossibilité d'attraper un CTRL_CLOSE_EVENT que j'ai fini par la remplacer par une fenêtre consolesque de mon cru.

[meynaf]

Si au moins on pouvait attraper sa "windows proc" pour traiter les messages à sa place. Mais même pas, ça ne tourne pas dans le même process.

[CTJayce]

Si au moins on pouvait attraper sa "windows proc" pour traiter les messages à sa place.

Si c'est faisable, tu peux utiliser une boucle de message et/ou définir
ta propre fonction de capture des signaux console.
(conf SetConsoleCtrlHandler() + HandlerRoutine callback )

On peut faire ça ainsi : AttachConsole(ATTACH_PARENT_PROCESS).
Et c'est là que tout part en sucette : le "prompt" revient dès que le programme est lancé, les sorties arrivent n'importe comment, et les entrées sont confondues avec des commandes tapées

Normal, t'as construit ton programme comme étant une appli gui.
Quand tu le lances depuis l'interpréteur cmd, ce dernier n'attend
pas la fin de son exécution, d'où l'accès concourant à la console.
Pour y remédier, il faut utiliser la commande start "" /wait pour
forcer l'attente.

[meynaf]

Si c'est faisable, tu peux utiliser une boucle de message et/ou définir
ta propre fonction de capture des signaux console.
(conf SetConsoleCtrlHandler() + HandlerRoutine callback )

La boucle de message n'attrapera pas ses messages, juste les miens. Je n'ai que le HWND, aucun moyen d'attraper les messages. Je le répète, la fenêtre de console est gérée par un autre process (en l'occurrence conhost.exe).
Pour s'en convaincre, essayer ceci :

Code C++ :

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

oldproc = (WNDPROC) SetWindowLong(GetConsoleWindow(), GWL_WNDPROC, (LONG) wndproc);

Ben oui, ça renvoie 0. Ce serait trop facile.

Quant à la fonction de capture, ce n'est pas une windows proc... Je peux savoir si on clique le bouton de fermeture avec CTRL_CLOSE_EVENT mais dès que je sors de la fonction, ça ferme tout sans rémission.

Donc non, désolé, ce n'est pas faisable.

Normal, t'as construit ton programme comme étant une appli gui.

Obligé : si c'est une appli console il ouvre une fenêtre de console qu'on le veuille ou non. Et bien sûr on a largement le temps de la voir s'afficher même si on la ferme tout de suite. Berk, je ne veux pas de ça.

Quand tu le lances depuis l'interpréteur cmd, ce dernier n'attend
pas la fin de son exécution, d'où l'accès concourant à la console.

Ouais, ben c'était pas une très bonne idée de leur part...

Pour y remédier, il faut utiliser la commande start "" /wait pour
forcer l'attente.

Je ne veux pas forcément obliger l'utilisateur du programme à faire ça

[CTJayce]

Il faut être plus clair sur tes besoins. Ton exemple de code montre que
tu mélanges les api réservées aux fenêtres graphiques et celles réservées
aux applications consoles. Les deux interfaces ne gèrent pas tout à fait les
mêmes types d'événements ou signaux, ni de la même manière.

Dans la foulée, je précise que rien n’interdit à une application console de
construire une fenêtre graphique cachée pour la gestion de la boucle
de message.

[meynaf]

Il faut être plus clair sur tes besoins. Ton exemple de code montre que
tu mélanges les api réservées aux fenêtres graphiques et celles réservées
aux applications consoles. Les deux interfaces ne gèrent pas tout à fait les
mêmes types d'événements ou signaux, ni de la même manière.

Bien sûr que je les mélange, mais je n'aurais pas eu à le faire si la console avait été gérée correctement.
Plus clair sur mes besoins ? J'ai pourtant bien précisé ce que je voulais lors du premier post...

Dans la foulée, je précise que rien n’interdit à une application console de
construire une fenêtre graphique cachée pour la gestion de la boucle
de message.

Fenêtre cachée qui n'attraperait aucun événement lié à la fenêtre de console donc ça n'est pas très utile.
Il n'y a pas "la" boucle de message, il y en a deux, en fait, même, probablement trois : celle de mon programme, celle de conhost.exe, et celle de cmd.exe.

[Médinoc]

Il n'y a pas "la" boucle de message, il y en a deux, en fait, même, probablement trois : celle de mon programme, celle de conhost.exe, et celle de cmd.exe.

Je doute que cmd ait une boucle de messages, c'est probablement un programme console "pur". Par contre, il a clairement une boucle qui attend sur ReadConsole() ou ReadConsoleInput().

Franchement, je n'ai pas vu de grand intérêt à AttachConsole() à part pour un programme de capture du contenu de celle-ci. Et ce, en grande partie parce que même avec, un programme "sans console" ne sera jamais aussi bien intégré à une console qu'un programme console.

Code :

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

start "" /wait

Je ne veux pas forcément obliger l'utilisateur du programme à faire ça

Je dirait que c'est à ça que servent les raccourcis ou batches. Mais ça oblige à avoir deux fichiers différents à utiliser pour lancer le programme, et si ça rentrait dans tes critères, tu aurais simplement deux versions de ton exécutable.

[Madmac]

Si c'est seulement pour voir les résultats de tes entrée-sorties un éditeur pourrait répondre à tes besoins:

Geany à facile à installer: https://www.geany.org/

et si tu désire un IDE complet, il y a Eclipse: https://www.eclipse.org/ide/

Cela suppose que Java est présent sur ton ordinateur. https://www.oracle.com/technetwork/j...ads/index.html

[meynaf]

Si c'est seulement pour voir les résultats de tes entrée-sorties un éditeur pourrait répondre à tes besoins:

Geany à facile à installer: https://www.geany.org/

Ce n'est pas seulement pour voir les résultats des entrées-sorties. Il faut même pouvoir supporter la redirection (que, curieusement, j'ai réussi à faire marcher sans trop de dégâts).

Le truc c'est que le programme doit lancer une sorte de script, qui peut faire n'importe quoi (ou pas) : entrée/sortie console, graphismes, sons, e/s fichier...
Donc pas de raccourcis.

et si tu désire un IDE complet, il y a Eclipse: https://www.eclipse.org/ide/

Cela suppose que Java est présent sur ton ordinateur. https://www.oracle.com/technetwork/j...ads/index.html

J'ai VS2015, ça me suffit.

[Médinoc]

Le truc c'est que le programme doit lancer une sorte de script, qui peut faire n'importe quoi (ou pas) : entrée/sortie console, graphismes, sons, e/s fichier...

Tu sais, Sun avait le même problème pour Java, et leur solution fut de créer deux exécutables (java.exe et javaw.exe).

[meynaf]

Tu sais, Sun avait le même problème pour Java, et leur solution fut de créer deux exécutables (java.exe et javaw.exe).

Ce qui me ferait deux exécutables qui peuvent être monstrueux et avec un seul bit dedans qui change... Bienvenue dans le monde Windows
Non, sans rire, j'aime encore mieux ouvrir systématiquement une fenêtre à moi (et ça, je sais que ça marche).

[Médinoc]

C'est à ça que servent les DLL: les deux exes de Java 1.8 font 188k chacun, dont 29k d'icône...

[meynaf]

C'est à ça que servent les DLL: les deux exes de Java 1.8 font 188k chacun, dont 29k d'icône...

Autrement dit on s'embête avec trois programmes (deux exe, une dll) là où un seul aurait dû suffire.
Non, rien à faire, la solution la plus simple reste encore d'ouvrir une nouvelle console.

[CTJayce]

Tu sais, Sun avait le même problème pour Java, et leur solution fut de créer deux exécutables (java.exe et javaw.exe).

Ce qui me ferait deux exécutables qui peuvent être monstrueux et avec un seul bit dedans qui change... Bienvenue dans le monde Windows

Il existe une troisième voie assez élégante grâce à la variable d'environnement
et affinité "path extension" (PATHEXT). Autrement dit, si cmd doit lancer une
application "a" et qu'il a le choix entre "a.com" et "a.exe", il va exécuter "a.com"
Le tout est donc de faire une appli console PE32(+) mais nommée "a.com",
c'est-à-dire le programme complet, et un "loader", donc très petit en taille,
nommé "a.exe" et compilé en mode gui. Dans le code source de ce dernier, il n'y
a pour ainsi dire qu'une api CreateProcess avec son flag CREATE_NO_WINDOW.

Maintenant, si on ne veut qu'une seul et unique appli, à titre personnel, je partirais
de base sur une appli console. Avec cmd, ça garantit un fonctionnement parfait.
Et à partir de l'explorateur, je profiterais de la console comme un pop-up avec un
message "Chargement en cours ..." Ce sera certainement moins déstabilisant
pour l'utilisateur final que le flash d'une fenêtre furtive.

Je doute que cmd ait une boucle de messages, c'est probablement un programme console "pur".

Et en effet pour "cmd", mis à part le fait que c'était jusqu'à peu l'interpréteur
par défaut de windows, c'est surtout une appli console tout ce qu'il y a de plus
classique. Quant à "conhost", sans entrer dans les détails, c'est juste le résultat
d'une mise à jour de sécurité, car avant ses fonctionnalités étaient intégrées
dans "csrss", mais du point de vue du développeur, ça reste totalement transparent.