W32/C Implémenter un mode console - Page 1

Bonjour à tous!
J'aimerais en fait recréer un truc du style la console sous Windows (quand on choisit Win32 Console Application) en utilisant une Win32 application (mais bon ça n'est pas obligatoire).
Pour le moment, je "hacke" la console pour y écrire (GetForegroundWindow puis GetDC) un buffer contenu dans une DIB avec BitBlt (d'ailleurs y'a-t-il un moyen plus rapide que ça pour accéder au buffer d'une bitmap, car c'est impossible avec les DDB mais le BitBlt est largement plus rapide).
En clair, je dois avoir une fenêtre qui se redessine régulièrement et indépendamment de ce qui est exécuté dans une autre fonction, en utilisant un buffer auquel cette fonction peut accéder et modifier. Il s'agit de multi-threading peut-être.
Ma configuration: Carte Voodoo 3 PCI 2000 (=lente si les infos ne se trouvent pas dans sa mémoire vidéo [= avec DIB]), et Visual C++ 6.0.
Merci d'avance

//Envoie un signal à ma fenêtre }

En fait je vais essayer de m'expliquer:unsigned char *monBuffer;
HDC hdcConsole;    //HDC de la console créée
//Fonction analogue à main en mode console
#define DessTexte(x,y,texte)  TextOut(hdcConsole,x,y,texte,strlen(texte))
#define AfficheEcran()  InvalidateRect(hwndConsole,NULL,FALSE)
void fonctionUtilisateurPrincipale()
{
  DessTexte(200,150,"Salut tout le monde");
  AfficheEcran();

[....]
WinMain crée une fenêtre, gère les messages, et stocke son hdc dans hdcConsole. Il démarre également la fonctionUtilisateurPrincipale qui sera séquencielle (càd jamais quittée avant la fin). Elle se redessinera si invalidée (AfficheEcran).

Si j'ai bien compris, tu veux faire une fenêtre personnalisée telle que qd ton programme client écrit dans "FILE *my_console", le texte sera affiché dans ta fenêtre personnalisée avec ta fonction personnalisée ?

Si c'est le cas, le moyen le plus simple et le plus portable serait d'appeler ton programme avec :
client.exe arg1 arg2 ... | server.exe
et alors la sortie standard de client.exe sera redirigée sur l'entrée standard de "server.exe". Il y a certainement aussi des APIs qui te permettent de faire ça sans avoir 2 exécutables séparés, mais je ne sais pas ce que c'est sous Windows (qui ne supporte malheureusement pas nativement l'API POSIX pour les pipes).


[EDIT : cross avec ./2]

Euh et en quoi la méthode de ./2 ne te satisfait pas? Tu veux que le rafraîchissement soit asynchrone?

Ok mais après server.exe reçoit quoi en entrée? (enfin plutôt comment le reçoit-il)

fgetc(stdin)

Nan, la méthode du ./2, c'est ce que j'aimerais avoir Malheureusement ce n'est pas le cas

Et qu'est-ce qui t'en empêche ? (dsl, j'ai un peu lu ./1 en diagonale)

Ben mon programme se bloque, la fenêtre ne répond pas. Je suppose qu'il faut utiliser du multi-threading...
En fait j'aimerais réaliser une console qui permette de faire (beaucoup) plus de choses que la console standarde (y compris du graphisme) mais qui reste simple à l'utilisation avec une exécution séquencielle du code.
Edit; je peux déjà le faire, mais la console n'aime pas trop ça (si elle n'est pas redessinée en boucle c'est assez moche) en plus la scrollbar et compagnie, c'est pas très beau.

Bah sinon, tu passes par les threads. Perso j'ai jamais utilisé l'API native (wxWidgets powa ), mais ça doit pas être compliqué...

(et c'est là que ce trouve mon problème)
Voici une démo de ce que j'ai fait en mode console. Regarde le fichier source.c et l'exécutable pour voir ce que ça donne.
Le but serait que ce soit aussi simple mais avec une fenêtre que j'ai créée moi-même (ça ne soit pas être compliqué)
http://www.isuisse.com/brunni/essaiConsole.zip

erf, flemme de regarder surtout que j'y connais rien en Win32... Mais tu as toujours la solution des pipes (./3), ça peut peut-être te simplifier la vie (mais ça dépend vraiment de la structure de ton prog)

Mouais ça marche maintenant. J'ai trouvé une manière exceptionnellement simple de créer un thread et on peut compiler la source du zip sans problème (et aussi simplement que ça).
Mais bon c'est pas encore terrible terrible. Apparemment je ne reçois plus de message WM_DESTROY quand on clique sur la croix pour fermer la fenêtre... pas de PostQuitMessage(0), l'"inner-loop" n'est pas quittée et s'agite, résultat le prog reste chargé en mémoire, consomme 50% (100% en mono-CPU) de processeur, ralentit le système, etc.
Sans compter que mon ordi n'arrête pas de planter (j'ai formaté entre-temps). Il redémarre comme ça sans prévenir (dès qu'il se met à bosser, genre j'exécute un prog, j'enregistre, j'ouvre un dossier, un document, après forcément la moitié du disque est corrompu). Il m'arrive que le BIOS me dise "Overclocking failed" et CA M'ENERVE. Une idée? L'ayant monté moi-même j'ai pitet fait sauter quoi selon-vous? A mon avis:
-Carte graphique
-Carte son (fait planter directement Win98)
-RAM
-Jumpers/Configuration du disque dur
Le reste je vois pas. Je vais essayer d'installer WinXP SP1 pour voir si ce n'est pas un problème avec l'hyper-threading.

^^ Euh fait gaffe avec les threads... C pas un truc à prendre à la légère, et ça peut souvent être source de plantage.
Si tu crées une fenêtre dans un thread, cette fenêtre est assignée à ce thread, donc il est possible que ce thread nécéssite lui aussi une boucle de message (mais je suis pas sûr). Il faut aussi faire attention au partage des variables. Si deux threads veulent modifier la même ressource, il risque d'y avoir plantage -> CriticalSection (c'est assez simple à mettre en oeuvre, mais il faut l'utiliser *SEULEMENT* dans les parties du code qui le nécécitent, car, autant cela peut éviter des plantages, autant cela peut en provoquer)
Euh, sinon, fais aussi attention à libérer les threads avant la fin du programme... (D'ailleurs, PostQuitMessage, je sais pas si ça marche dans un thread (enfin, si, ça marche, mais je ne sais pas ce que ça fait exactement))
Et puis la solution la plus simple par contre: as-tu pensé à regarder l'API console de windows ? Parce que c'est très facile d'afficher la fenêtre console de l'application (et sinon, une app console peut créer des fenêtres aussi.... surtt si tu ne veux pas trop t'embêter avec l'API windows )
Et j'oubliais un point essentiel: certain compilateurs ont une librairie différente pour le multi-thread, fais-y attention

Oui effectivement je viens d'avoir des problèmes à propos de ce que tu me dis là. Si je copie (BitBlt) l'écran (DIB) contenu dans un hdc partagé aux deux threads(hdcImage) et qu'en même temps le thread utilisateur veut accéder à ce hdc (genre il appelle TextOut) ça ne marche pas. En clair il peut arriver que du texte ne soit pas affiché. Un truc à faire est while(!TextOut(...)); mais après c'est du côté du BitBlt que ça embête, enfin bref.
Comme je l'ai dit, le but est de faire un truc très simple qui sera utilisable par n'importe qui comme le mode console. Dans le thread qui gère la fenêtre, ce n'est pas un problème pour moi d'avoir beaucoup de code, mais je ne veux pas qu'il faille faire quoi que ce soit dans la partie utilisateur...

Ah oui et puis au bout d'un moment ça plante (GDI ne fait absolument plus rien sur hdcImage)

^^ mais sinon, tu ne veux pas plutôt faire ta propre fenêtre de console ? pske y'a moyen de se débrouiller avec ça... (redirection de stdin, stdout et stderr) Et ça ne devrait pas bugger en principe

La redirection de stdin & out pourrait être une (très) bonne idée.
Bon là j'ai plus ou moins terminé la lib (faudra encore que j'améliore mon scanf)
Selon toi ce genre de librairies peut-il intéresser des gens?

SALUT A TOUS
VOILA C EST UNE DLL POUR VB6
JE LUI DONNE UNE PICTURE ET UNE TAILLE X/Y POUR LE BUFFER

CELA DEVRAIS ME TRANSFORME LA PICT... EN ROUGE SUR X/Y

ET BIEN NON . LA EST LA QUESTION POURQUOI ?

CA FAIS UN MOIS QUE J APPREND LE C++ .... MERCI A TOUS

//------------------------------------------------------
void _stdcall BufPic(HDC PichDC,HBITMAP PicImHandle, long x, long y)
{
RGBQUAD* Buffer = new RGBQUAD[x,y];

int Xw;
int Yw;
for (Xw=0; Xw<x; Xw++)
{
for (Yw=0; Yw<y; Yw++)
{Buffer[Xw,Yw].rgbRed=255;
}}

BMPINFOH.biBitCount = 32;
BMPINFOH.biHeight = y + 1;
BMPINFOH.biWidth = x + 1;
BMPINFOH.biPlanes = 1;
BMPINFOH.biSize = sizeof(BMPINFOH);
BMPINFO.bmiHeader = BMPINFOH;

SetDIBits(PichDC, PicImHandle, 0, y + 1, Buffer, &BMPINFO, 0);
}
//-------------------------------------

VB6 ?? T'es sûr que c'est pas VC6 ?
Pourquoi tu agrandis l'image ?

Miles
: VB6 ?? T'es sûr que c'est pas VC6 ?

Il a dit que c'est une DLL (en C++) pour VB6, pas une DLL en VB6.

ortipic :
SALUT A TOUS
VOILA C EST UNE DLL POUR VB6
JE LUI DONNE UNE PICTURE ET UNE TAILLE X/Y POUR LE BUFFER

CELA DEVRAIS ME TRANSFORME LA PICT... EN ROUGE SUR X/Y
ET BIEN NON . LA EST LA QUESTION POURQUOI ?

Déjà ARRÊTE DE PARLER EN ALL-CAPS! Ce n'est vraiment pas une bonne habitude de hurler de cette manière. Ton message n'est pas plus important que ceux des autres, donc ne le mets pas en relief de cette manière impolie et égoïste.

Et puis, la prochaîne fois, crée un nouveau topic pour ta question au lieu de parasiter ceux des autres!

Et pour en venir à ta question: C'est ta syntaxe de tableaux qui est mauvaise:

RGBQUAD* Buffer = new RGBQUAD[x,y];
... Buffer[Xw,Yw].rgbRed=255;

Tu déclares un tableau de taille x,y, expression qui évalue x, jette x (!), évalue y et retourne y. Même chose pour l'accès. En d'autres mots, ton code est absolument équivalent à:
RGBQUAD* Buffer = new RGBQUAD[y];
...
Buffer[Yw].rgbRed=255;

Pour faire un tableau à 2 dimensions, il faut faire un tableau de tableaux. Si tu utilises g++ (http://www.mingw.org), tu peux utiliser les tableaux de taille variable à la C99:
RGBQUAD(*Buffer)[y] = reinterpret_cast<RGBQUAD (*)[y]>(new RGBQUAD[x*y]);
...
Buffer[Xw][Yw].rgbRed=255;
Avec M$VC, je pense qu'il faudra utiliser des méthodes plus lourdes. (Tu peux toujours essayer, mais je ne pense pas qu'il gère les tableaux de taille variable.)

Merci pour l info TIGCC
DESOLE pour les pieds dans le plat

Kevin Kofler :
Avec M$VC, je [...]

aRf !
Mais arrête avec ça ... t'es bien content d'avoir ou d'avoir eut un windows ME #beurk# ... alors crache pas dessus !!!

Kevin Kofler :
Avec M$VC, je [...]

Ah K€vin! I£ ne ¢hangera vraiment jamai$!