Discussion :

[andrebernard]

DIOGENE, je crois bien que je t'aaaaaaimmmeeeeeuuuuu !
Comme l'aurait chanté le beau johnny a la belle sylvie dans les années 70

Je crois que j'ai enfin compris....

Donc, on commence a mettre un ou plusieurs INCLUDE .h dans le fichier qui possede le winmain() ou le main().
Le compilateur commence toujours par cette procedure et doit connaitre auparavant chaque variable et chaque fontion.
Pour ce faire, il doit avoir été inclus un .h qui possede les prototypes des fonctions rencontrées et les declarations des variables.

A son tour une fonction en appelle une autre, elle doit avoir été renseignée par un .h au debut du fichier la contenant

En fin de compte, c'est comme une chaine, etant donné que l'on ne peut pas appeller deux fonctions en meme temps.....

Je vous remercie mille fois a tous....ce qui est rigolo..c'est qu'un seul cerveau performant vous suffit pour faire du C.
Alors qu'il faut 4 cerveaux performants pour tirer le miens afin qu'il arrive a essayer d'en faire
Vous commencez a comprendre le boulet que j'me traine depuis 30 ans

Je vous souhaite une excelente journée à tous

[Obsidian]

Tu confonds plusieurs choses, mais c'est parce que tu cherches trop compliqué.

Il a des règles de bonne conduite en C mais il n'y a pas de format imposé au départ. Pour mieux comprendre, il faut reprendre le problème à l'envers :

• J'écris un petit programme pour mon compte personnel. Ok, ça compile directement ;
• Je rajoute un appel à une fonction bien pratique mais définie dans un autre module, par exemple printf() (qui n'est pas codée en dur dans le C, mais fait partie de la bibliothèque standard). Ok, je l'invoque dans mon programme, comme j'appelle mes propres fonctions ;
• Le C, à juste titre, m'informe qu'il n'en a jamais entendu parler, de cette fonction ;
• Pas de problème, je vais écrire son prototype avant mon appel à cette fonction, pour lui expliquer comment on s'en sert ;
• En réalité, comme ce n'est pas moi qui l'ai écrite, cette fonction, je vais plutôt inclure un fichier tout fait qui contient déjà ce prototype (ainsi que pas mal d'autres). Ce fichier s'appelle stdio.h ;
• Le C, à ce stade, sait donc comment on appelle cette fonction. Il peut donc générer du langage machine à partir de mon code ;
• Le linker cherche à générer un exécutable à partir de mon simple fichier objet. Pas de problème, mais il y a quand même des références à une fonction extérieure, nommée printf() ;
• Le linker trouve justement une fonction printf() dans la bibliothèque standard. Il va donc utiliser son adresse pour combler les trous de mon fichier objet ;
• Il n'y a plus de dépendances non résolues en suspens, et il y a un point d'entrée dans mon fichier objet. Plus rien ne s'oppose à la génération d'un exécutable.

Ces derniers points sont importants car le linker va avoir la bonne idée d'aller voir tout seul dans la lib standard s'il trouve ce dont il a besoin, mais pour les autres bibliothèques, il n'y a rien dans le code qui lui dise dans quelles bibliothèques chercher les dépendances et c'est normal. C'est donc au programmeur de spécifier dans les paramètres du projet les bibliothèques qu'il compte utiliser et, éventuellement, où elles se trouvent.

Voici un exemple sous UNIX avec X-Window. Le programme ci-dessous n'affiche rien, mais il se connecte au serveur X par défaut, se déconnecte aussitôt, et se termine.

Code C :

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

1
2
3
4
5
6
7
8
9
int main (void)
{
    Display * dpy;
 
    dpy = XOpenDisplay ("");
    if (dpy!=NULL) XCloseDisplay (dpy);
 
    return 42;
}

Je mets « 42 » (valeur complètement arbitraire) dans le return pour pouvoir voir facilement depuis le Shell, ensuite, si mon programme a été exécuté ou pas.

J'essaie de compiler ça avec GCC. Par défaut, celui-ci va essayer de me générer un exécutable. Si je lui passe l'option « -c », il va s'en tenir à la seule création de mon fichier objet. L'option « -o », comme « output » ne me sert qu'à spécifier le nom du fichier généré, quel qu'il soit. Donc :

Code Shell :

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

1
2
3
4
5
6
7
$ gcc clientx.c -o clientx
clientx.c: In function ‘main’:
clientx.c:3: erreur: ‘Display’ undeclared (first use in this function)
clientx.c:3: erreur: (Each undeclared identifier is reported only once
clientx.c:3: erreur: for each function it appears in.)
clientx.c:3: erreur: ‘dpy’ undeclared (first use in this function)
clientx.c:6: erreur: ‘NULL’ undeclared (first use in this function)

Que voit-on ?
J'essaie de déclarer un pointeur « dpy » de type « Display ». Seulement, « Display », le compilo ne connaît pas, et par conséquent ne peut pas déclarer mon pointeur. La fonction suivante se plaint à son tour parce que j'utilise « dpy » qui n'a pas pu être déclaré. Et, accessoirement, on voit aussi que NULL n'est pas un mot-clé du C non plus. Il est défini dans un des nombreux headers standards, en l'occurrence, stddef.h.

Que se passe-t-il si j'essaie de ne générer que le fichier objet ?

Code Shell :

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

1
2
3
4
5
6
7
$ gcc clientx.c -c
clientx.c: In function ‘main’:
clientx.c:3: erreur: ‘Display’ undeclared (first use in this function)
clientx.c:3: erreur: (Each undeclared identifier is reported only once
clientx.c:3: erreur: for each function it appears in.)
clientx.c:3: erreur: ‘dpy’ undeclared (first use in this function)
clientx.c:6: erreur: ‘NULL’ undeclared (first use in this function)

Même chose.
Il me manque des infos pour bâtir le code.

Maintenant, j'inclus le fichier « Xlib.h», fourni avec la X-Lib, censé en décrire la majeure partie.

Code C :

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

1
2
3
4
5
6
7
8
9
10
11
#include <X11/Xlib.h>

int main (void)
{
    Display * dpy;

    dpy = XOpenDisplay ("");
    if (dpy!=NULL) XCloseDisplay (dpy);

    return 42;
}

Si j'essaie de compiler mon exécutable, j'obtiens ceci :

Code Shell :

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

1
2
3
4
5
$ gcc clientx.c
/tmp/ccAFKUEg.o: In function `main':
clientx.c:(.text+0xe): undefined reference to `XOpenDisplay'
clientx.c:(.text+0x25): undefined reference to `XCloseDisplay'
collect2: ld a retourné 1 code d'état d'exécution

On s'aperçoit que ce n'est plus mon fichier source qui pose problème, mais un fichier temporaire. On voit également sur la dernière ligne que c'est « ld » (le linker UNIX) qui se plaint, et pas GCC. Le message « ld a retourné 1 code d'état » signifie en fait que c'est GCC qui a appelé ld, que celui-ci a échoué en lui retournant un code d'erreur, et que c'est GCC (qui est toujours là, lui) qui fait état de cette erreur.

Par contre, si je lui demande de ne générer que le fichier objet :

Code Shell :

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

1
2
3
4
$ gcc clientx.c -c
$ ls -l clientx.*
-rw-rw-r-- 1 dom dom  148  3 nov.  12:07 clientx.c
-rw-rw-r-- 1 dom dom 1584  3 nov.  12:14 clientx.o

Là, ça marche. Mon compilateur a bien réussi à me transformer mon code C en langage machine et à générer un fichier objet *.o, même si celui-ci n'est pas encore utilisable en l'état. Tu as dû remarquer également qu'il ne se plaint plus non plus pour « NULL ». C'est dû au fait que le fichier que j'ai inclus s'appuie lui-même sur des headers standard qui, eux, ont fini par intégrer stddef.h a un moment ou à un autre.

Maintenant, on va demander au système de nous lister tous les symboles définis dans ce fichier *.o :

Code Shell :

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

1
2
3
4
$ nm clientx.o
                 U XCloseDisplay
                 U XOpenDisplay
0000000000000000 T main

« T » signifie « Text » et désigne en fait le code exécutable, par opposition aux données en lecture seule ou pas. « U » signifie « Unknown », c'est-à-dire « Inconnu ».

On voit que la fonction « main » a l'adresse « 0000000000000000 » par rapport au début de la section concernée dans le fichier, parce que c'est la première fonction que j'ai rédigée (et, ici, la seule). Et le rôle du compilateur s'arrête là : j'ai généré un code en langage machine parfaitement valide, avec un symbole déclaré dans le fichier, et qui se réfère à deux fonctions externes.

Et c'est là la clé du mystère : la gestion ou non de bibliothèques, qu'elles soient statiques ou dynamiques, relève du système d'exploitation et pas du langage C, ni du compilateur, dont la seule véritable fonction est d'apporter un moyen simple de produire du langage machine.

À ce stade, le compilo a fini son travail. Je peux maintenant demander au linker, directement, d'associer plusieurs *.o pour former soit un *.o plus gros qui contienne tout dans le même fichier, soit directement un exécutable. Je peux aussi lui demander de faire une liaison avec des bibliothèques « dynamiques », donc qui ne seront réellement chargées qu'au lancement de l'exécutable.

Mais il faut quand même qu'il puisse les voir pour que les associations se fassent correctement, même si c'est a posteriori. En outre, je peux avoir plusieurs versions de la même bibliothèque. Il est donc nécessaire de bien préciser à laquelle je compte me lier.

Il se trouve que j'ai une bibliothèque nommée X11 dans le dépôt standard « /usr/lib64 » de ma machine :

Code Shell :

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

1
2
$ ls -l /usr/lib64/libX11*
/usr/lib64/libX11.so

Je n'ai donc pas besoin de préciser le répertoire de dépôt, mais je vais quand même spécifier la bonne bibliothèque. Sous Unix, elles sont toujours préfixées par « lib ». On ne précise jamais ce préfixe au linker. On omet également les suffixes.

Je pourrais créer mon exécutable directement avec « ld », à ce stade. Cependant, en partant d'un code généré en C, il faudrait que je passe explicitement beaucoup d'options très compliquées, dépendantes de la version de ton compilateur et du système que tu utilises. Elles sont transmises automatiquement par ton compilo, par contre. Donc :

Code :

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

1
2
3
4
$ gcc clientx.c -o clientx -lX11
$ ./clientx
$ echo $?
42

L'option « -l » (L minuscule) signifie « Library » (dynamique, s'entend) et est à l'intention du linker. Cette fois, mon exécutable existe bien. L'exécution se déroule sans encombre, et le résultat attendu est bien le bon.

[andrebernard]

Ouuuaaahh !!! j'ai encore appris pleins de choses en te lisant.
Bon par rapport a tous les mots que tu as ecrit, c'est "pinuts"...mais quand meme c'est super important de comprendre ne serais ce qu'un peu

Au passage....c'est rigolo...vous etes tellement habitué à mettre des points virgules a la fin des instructions que t'en met a chaque phrase de français
J'espere un jour faire pareil...ça voudra dire que la force du C est en moi

En réalité, comme ce n'est pas moi qui l'ai écrite, cette fonction, je vais plutôt inclure un fichier tout fait qui contient déjà ce prototype (ainsi que pas mal d'autres). Ce fichier s'appelle stdio.h ;

Tu va pas y croire...j'avais pas fait le rapprochement avec le .h de stdio.h, ou #include <windows.h>
J'suis vraiment un lapin de 4 jours...bon sang ...mais c'est bien sur.....pour les lib internes aussi, on inclus que les .h et pas les .c comme je faisais avant

Ces derniers points sont importants car le linker va avoir la bonne idée d'aller voir tout seul dans la lib standard s'il trouve ce dont il a besoin

D'accord...donc y'a donc une lib standard qui est implicitement incluse

Il reste quand meme un point que j'ai pas trop compris..toi tu met main(), et winmain() c'est quoi la difference ???
Si je veux faire des fenetres et de la GUI, je peux quand meme appeller ma fonction principale main() ??? ou suis je obligé d'utiliser winmain()

La fonction suivante se plaint à son tour

Aaaahhh !!! d'aaaaaaaccord !!! je comprend pourquoi maintenant on a "wattmille" lignes d'erreur, et qu'apres on en corrige une et hop....y'en a plus

Je peux maintenant demander au linker, directement, d'associer plusieurs *.o pour former soit un *.o plus gros qui contienne tout dans le même fichier

Cooooool ...je ne savais pas ça possible
Je ne vois pas encore l'interet..mais si ça existe, c'est que y'en a un

Je peux aussi lui demander de faire une liaison avec des bibliothèques « dynamiques », donc qui ne seront réellement chargées qu'au lancement de l'exécutable.

D'accord, c'est donc a ce moment que les DLL interviennent, je le savais des lis statiques, je l'avais lu dans un TUTO avec un joli dessin.
Mais pour les DLL, je ne savais pas

l'option « -c »,
L'option « -o », comme « output » .
etc.....

Alors j'ai appris un truc grandiose, mais que je savais en fait deja...
Je deteste les consoles Oooooouuuuuiiiinnn

Je vais rester marié avec VC6 qui fait plein de jolies couleurs, et du texte sur fond blanc, et des fenetres... des belles fenetres bien carré comme je les aimes
J'adore les fenetres....peut etre en ai je besoin pour m'aerer la tete

Sincerement les consoles, a ce niveau la ..une fois passé le "Hello word" c'est pas fait pour les brouettes comme moi.

Toutes ces options a retenir....
J'avais peur de LINUX pour ça aussi...ça se confirme.

Et puis apres tout .....
Des cerveaux comme vous, ont créé les GUI...pour des gens comme moi.
A quoi ça sert que duCros y se decarcasse ???
Bon je te l'accorde, les gens comme moi on apporte pas grand chose au monde du C...parce que avant que je sois capable de creer une lib...
Mais on sait balayer, faire la vaisselle, le menage....et c'est utile

Vraiment merci pour toutes ces explications.
Je crois que cette fois, je devrais savoir inclure des fichiers avec un petit .h, et arreter de vous embeter avec cette Histoire avec un grand H

Merci encore, j'ai hate d'etre ce week end et de pouvoir lacher VB pour a nouveau faire du C...a mon plus grand plaisir...et votre plus grand desespoir

Excelente journée a vous tous

[Obsidian]

Au passage....c'est rigolo...vous etes tellement habitué à mettre des points virgules a la fin des instructions que t'en met a chaque phrase de français

Non, c'est la manière normale d'écrire des énumérations en français. C'est même à ça que sert le point-virgule, au départ.

D'accord...donc y'a donc une lib standard qui est implicitement incluse

Oui (parce que, sans ça, au niveau débutant, ça deviendrait franchement hardcore). Mais tu peux aussi demander à ton compilo de ne pas le faire.

Il reste quand meme un point que j'ai pas trop compris..toi tu met main(), et winmain() c'est quoi la difference ???

On te l'a déjà dit : « oublie WinMain() » !

C'est une chose qui t'est imposée par la C API de Windows. Apprendre le C avec ça, c'est franchement choper de mauvaises habitudes pour rien. WinMain() n'est absolument pas définie par le langage C.

C'est un point d'entrée spécial défini par Windows parce que d'une part, c'est le même système qui s'occupe de lancer de processus et de gérer les fenêtres (ce qui est mal, à mon goût), et parce qu'il en profite pour passer à ce processus des informations concernant l'environnement un peu plus fournies que argc et argv.

Si je ne dis pas trop d'âneries (la dernière fois que j'ai écrit un programme Windows, c'était en 2002), lorsque les formats d'exécutables Windows NE et PE ont été définis, le D.O.S. était encore très répandu et comme ces exécutables *.exe portaient la même extension dans les deux environnements. Il y avait donc encore un segment « D.O.S. » valide au départ qui contenait un tout petit programme, dont l'unique fonction était d'afficher « This program cannot be run in DOS mode » et de sortir.

Mais comme l'exécutable était censé, par définition, contenir deux segments de code distincts pour les deux systèmes, on a laissé main() au D.O.S., comme c'était le cas jusque là, et on a défini un point d'entrée WinMain() en parallèle.

Il est évident que c'est propre à Windows.

Si je veux faire des fenetres et de la GUI, je peux quand meme appeller ma fonction principale main() ??? ou suis je obligé d'utiliser winmain()

Sous Windows, en C, probablement. Peut-être peut-on faire la passerelle depuis main() et obtenir les infos nécessaires, mais là, je laisse quelqu'un d'autre répondre à ma place.

Sous d'autres systèmes, en revanche, WinMain() n'existe pas, ce qui règle le problème. Le point d'entrée d'un programme C est main(). Et, de là, c'est toi qui appelle explicitement la bibliothèque du Window Manager pour faire ce que tu veux faire.

Cooooool ...je ne savais pas ça possible Je ne vois pas encore l'interet..mais si ça existe, c'est que y'en a un

C'est pratique si tu veux créer une bibliothèque statique, justement, à l'usage des autres programmeurs. Tu fais toujours de la compilation séparée (pour éviter de tout reconstruire à chaque fois), mais tu livres le produit fini dans un seul fichier. Ce n'est qu'un exemple parmi d'autres, bien sûr.

Alors j'ai appris un truc grandiose, mais que je savais en fait deja...
Je deteste les consoles Oooooouuuuuiiiinnn Je vais rester marié avec VC6 qui fait plein de jolies couleurs, et du texte sur fond blanc, et des fenetres... des belles fenetres bien carré comme je les aimes

C'est une grosse erreur, parce que gérer des fenêtres est compliqué. Bien plus que la console.

Et ton problème, après lecture de tous tes posts sur le forum, n'est pas du tout que tu es « incapable », comme tu as essayé de nous le faire croire, même par humilité mais que tu te précipites à corps perdu dans chaque piège qui se présente à toi.

Commence par la console — y compris sous Windows — et tu passeras tout naturellement aux fenêtres après.

Bon je te l'accorde, les gens comme moi on apporte pas grand chose au monde du C...parce que avant que je sois capable de creer une lib...
Mais on sait balayer, faire la vaisselle, le menage....et c'est utile

Ce n'est pas plus difficile que créer un programme quand on a compris comment ça marche. C'est pratiquement le même travail.

[Invité]

Concernant WinMain(), ci-dessous une doc.

Syntax

int PASCAL WinMain(HINSTANCE hCurInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
int PASCAL wWinMain (HINSTANCE hCurInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int nCmdShow)
int PASCAL _tWinMain (HINSTANCE hCurInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int
nCmdShow)

Description

The WinMain function is the main entry point for a Windows application. It must be supplied by the user.

wWinMain is the Unicode version. It takes a Unicode string as the third parameter.

_tWinMain is a macro that expands to the appropriate function depending upon the type of application.

Type Parameter Description

HINSTANCE hCurInstance The instance handle of the application. Each instance of an application has a unique instance handle. It is used as an argument to several Windows functions and can be used to distinguish between multiple instances of a given application.
HINSTANCE hPrevInstance The handle of the previous instance of this application. This value is NULL if this is the first instance.
LPSTR lpCmdLine A far pointer to a null-terminated command-line. Specify this value when invoking the application from the program manager or from a call to WinExec. For the wWinMain function lpCmdLine is a Unicode string.

int nCmdShow An integer that specifies the application's window display. Pass this value to ShowWindow.

Under Win32, there are two differences in the values passed through these parameters:

hPrevInstance always returns NULL.
lpCmdLine points to a string containing the entire command line, not just the parameters.

Return Value

The return value from WinMain is not currently used by Windows. It is useful during debugging because you can display this value upon termination of your program.

Mais il est vrai que dans le contexte des OS actuels, sauf cas particulier, cela n'a plus beaucoup de raisons d'être utilisé.

Commence par la console — y compris sous Windows — et tu passeras tout naturellement aux fenêtres après.

J'ai fait du dessin, sous DOS, sans Window, J'ai fait aussi du dessin sans console (ça n'existait pas) en Fortran, j'en ai fait aussi sous UNIX mais il y avait XWindow, et maintenant le dessin sous Windows (avec des fenêtres), c'est pas mal tout de même.
Bonne continuation.

[andrebernard]

Compris pour le WinMain
Encore merci a vous deux

[Médinoc]

Vous savez, sous Windows, on peut toujours faire un programme avec int main(int argc, char *argv[]) qui ouvre des fenêtres... Simplement, ce programme aura aussi une Console (vous savez, la soi-disant "fenêtre MS-DOS").

[Invité]

Absolument.
Mais il y a en fait 3 points différents
1- l'éditeur avec lequel on rédige les modules de son programme, le makefile etc.
Ca on s'en sert tous les jours et il existe des éditeurs non spécialisés dans un langage particuliers mais qui ont des possibilités importantes, en autres les couleurs des termes suivant leur spécificité.
2- la fenêtre d'exécution du compilateur, soit pour compiler des modules, soit l'éditeur de lien, soit le lancement de l'exécution du programme lui-même. Là on peut soit utiliser la fenêtre de commande Windows, soit créer un raccourci.
3- l'aspect des dialogues avec l'utilisateur. C'est ce dernier point qui me parait plus important (intéressant). C'est là aussi que les fenêtres apportent un confort appréciable, peut-être un peu difficile à mettre en œuvre la première fois, mais, à mon avis, ce serait dommage de s'en priver.

[andrebernard]

Vous savez, sous Windows, on peut toujours faire un programme avec int main(int argc, char *argv[]) qui ouvre des fenêtres... Simplement, ce programme aura aussi une Console (vous savez, la soi-disant "fenêtre MS-DOS").

Oh oui que je la connais cette fenetre.
J'ai toujour été admirateur de leur utilisateur.
J'en ai fait pas mal sur des vieille machines pour le DOS, mais maintenant, bien que je sache que OBSIDIAN a raison, rien que la voir me donne des boutons.
Je vais essayer de l'utiliser le moins possible...mais si elle apparait derriere ma fenetre en commençant par main(), je crois que je vais preferer winmain()

Quoi qu'il en soit, bien que je deteste VISTA, je reste un enfant de windows.
LINUX c'est vraiment pour les pros, certe avec UBUNTU on peut l'utiliser sans trop en baver, mais bon...je laisse LINUX au pros comme vous.
Deja que je vais pourrir le monde du C de mon arrivée...je laisse reposer le monde de LINUX en paix

@Pierre
Oui d'ailleur ce choix me laisse perplexe...en fait encore une fois, un windozien et qui plus est "VBiste" n'est pas habitué a tout ça
En fin de compte..on est jamais content..avec VB je crevais de faim avec mon seul RAD non performant...avec le C je crois que je vais mourrir de surbouffe entre tous ces compilateurs, ces IDE.....

Au risque d'en decevoir certains, je vais rester dans l'historique, pour l'instant c'est le VC6 qui me convient le mieux.
De plus il est reconnu par le monde du C et fiable, la seule chose que j'ai vu pour l'instant qu'il lui manquait c'est de pouvoir replier les codes.
Mais ça les VS 2005/2008/ etc le font.....
Mais bon, ces usines a gaz en DVD, ça me tente pas trop VC6 est deja bien assez gros.
A force d'en essayer..je trouverais surement mon bonheur...

Quoi qu'il en soit...que je prenne n'importe lequel, grace a vous tous...je sais dans quel fichier je vais ecrire mon code ce week end...dans des .h et des .c

[andrebernard]

Juste un coucou en passant pour vous dire que comme promis des que j'ai pu ouvrir VC6, je me suis jeté dessus pour mettre a profit tous les bons conseils que vous avez eu la gentillesse et la patience de me prodiguer

Et ce matin, pour bien tout faire dans l'ordre, j'ai tout effacé mes includes, comme me l'a conseillé un des membres, et je me suis fait guider par le débugger, et ça a marché du tonnerre

Bon...j'ai joué de la musique une dizaine de fois
Et petit a petit..le zozio a fait son nid, et la liste c'est rapetissée sous mes yeux ébahis, pour finir avec une belle compilation comme nous tous les aimons

Voila..je crois avoir bien compris que chaque .c était indépendant et bien créé un .h par .c...bien propre

Classe.c

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#include "Classes.h"
 
void ClassRegister(HINSTANCE hInstance, int nCmdShow)
{
 
	wc.cbClsExtra     = 0;
	wc.cbWndExtra     = 0;
	wc.hbrBackground  = (HBRUSH)(COLOR_WINDOW + 1);
	wc.hCursor        = LoadCursor(NULL, IDC_ARROW);
	wc.hIcon          = LoadIcon(NULL, IDI_APPLICATION);
	wc.hInstance      = hInstance;
	wc.lpfnWndProc    = WndProc;
	wc.lpszClassName  = "Classe 1";
	wc.lpszMenuName   = NULL;
	wc.style          = CS_HREDRAW | CS_VREDRAW;
 
	RegisterClass(&wc);
 
}

Fenetre.c

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
#include "Fenetre.h"
 
LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    static HINSTANCE hInstance;
 
    switch (message)
    {
     case WM_CREATE:
 
        hInstance = ((LPCREATESTRUCT)lParam)->hInstance;
        CreateWindow("BUTTON", "OK", WS_CHILD | WS_VISIBLE, 0, 0, 100,24, hwnd, (HMENU)1, hInstance, NULL);
 
        break;
 
     case WM_COMMAND:
        /***************************************************\
        * LOWORD(wParam) = ID du contrôle ou du menu        *
        * HIWORD(wParam) = Raison du message (notification) *
        \***************************************************/
 
        switch(LOWORD(wParam))
        {
 
        case 1:
 
            switch(HIWORD(wParam))
            {
 
            case BN_CLICKED:
                Beep(1000, 100);
                break;
 
            default:
                break;
            }
 
            break;
 
        case 2:
 
            switch(HIWORD(wParam))
            {
 
            case BN_CLICKED:
 
                Beep(100, 100);
                break;
 
            default:
 
                break;
 
            }
 
            break; 
 
        default:
 
            break;
 
        }
 
        break; /* case WM_COMMAND */
 
    case WM_DESTROY:
 
        PostQuitMessage(0);
        break;
 
    default:
 
        return DefWindowProc(hwnd, message, wParam, lParam);
 
    }
 
    return 0;
 
}
 
int OuvertureFenetre(HINSTANCE hInstance, int nCmdShow)
{
 
 hWnd = CreateWindow("Classe 1", "Notre première fenêtre", WS_OVERLAPPEDWINDOW,100, 100, 600, 300, NULL,NULL,hInstance,NULL);
 hWndB1 = CreateWindow("BUTTON", "OK1", WS_CHILD | WS_VISIBLE, 100,100, 100,24, hWnd, (HMENU)1, hInstance, NULL);
 hWndB2 = CreateWindow("BUTTON", "OK2", WS_CHILD | WS_VISIBLE, 200,200, 100,24, hWnd, (HMENU)2, hInstance, NULL);
 ShowWindow(hWnd, nCmdShow);
 
	while (GetMessage(&msg, NULL, 0, 0))
 {	 
	 TranslateMessage(&msg);
	 DispatchMessage(&msg);
	}
 
 return (int)msg.wParam;
 
}
 
 
//void ClassRegister(HINSTANCE hInstance, int nCmdShow)
//{
//	
//	wc.cbClsExtra     = 0;
//	wc.cbWndExtra     = 0;
//	wc.hbrBackground  = (HBRUSH)(COLOR_WINDOW + 1);
//	wc.hCursor        = LoadCursor(NULL, IDC_ARROW);
//	wc.hIcon          = LoadIcon(NULL, IDI_APPLICATION);
//	wc.hInstance      = hInstance;
//	wc.lpfnWndProc    = WndProc;
//	wc.lpszClassName  = "Classe 1";
//	wc.lpszMenuName   = NULL;
//	wc.style          = CS_HREDRAW | CS_VREDRAW;
//
//	RegisterClass(&wc);
//
//}

Main.c

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
#include "Main.h"
 
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
 
 // Create first class
 ClassRegister(hInstance, nCmdShow);
 
  // Create the windows
	return OuvertureFenetre(hInstance, nCmdShow);
 
}

Classe.h

Code :

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

1
2
3
4
5
6
7
8
9
#ifndef H_Classes
 
 #define H_Classes
 #include <windows.h>
 WNDCLASS wc;
 LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam);
 void ClassRegister(HINSTANCE hInstance, int nCmdShow); 
 
#endif

Fenetre.h

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
#ifndef H_Fenetre
 
 #define H_Fenetre
 int OuvertureFenetre();
 #include <windows.h>
 HWND hWnd;
 MSG msg;
 HWND hWndB1;
 HWND hWndB2;
 LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam); 
 
#endif

Main.h

Code :

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

1
2
3
4
5
6
7
8
9
#ifndef H_Main
 
 #define H_Main
 #include <windows.h>
 void ClassRegister(hInstance, nCmdShow);
 OuvertureFenetre(hInstance, nCmdShow);
 int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow);
 
#endif

Je vous remercie encore du fond du cœur de votre précieuse aide à tous.
C'est grace a des gens comme vous, que les benets comme moi peuvent accéder au pallier supérieur et atteindre leur rêve, sans désespérer tout seuls devant leur écran,

Je vous aimes.....l'aventure commence et votre aide m'a encouragé et m'a donné encore plus envie de coder C, car quand ça marche .....
J'espère ne pas trop abuser de votre patience dans ce long voyage que j'entreprends dans l'univers du C

Je vous souhaite a tous une excellent journée

[Invité]

Bonjour,
Ben, je vous assure, ça fait plaisir.

[diogene]

Des erreurs dans ton organisation .c/.h

classe.h/classe.c :

On trouve dans classe.h

Code :

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

WNDCLASS wc;

Il ne faut pas définir de variables dans un .h .
Un .h est potentiellement destiné à être inclus par plusieurs .c. Dans ce cas, tu vas avoir une multiple définition de la variable wc.
Si tu veux définir une variable globale wc et la faire connaitre aux autres unités de compilation par l'insertion du .h, il faut procéder de la façon suivante :
- Définir la variable dans un .c
- Déclarer dans le .h cette variable en extern.

Code :

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

1
2
3
4
5
6
7
8
9
10
//---- classe.c :
#include "Classes.h"
WNDCLASS wc; 
void ClassRegister(HINSTANCE hInstance, int nCmdShow)
{....
 
//---- classe.h :
....
extern WNDCLASS wc;
....

Pourquoi le prototype

Code :

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

 LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam);

déclaré dans classe.h ? classe.c ne définit pas cette fonction (et ne l'utilise pas non plus)

Fenetre.h/Fenetre.c :
Même remarque sur les variable globales HWND hWnd; MSG msg; HWND hWndB1; HWND hWndB2;
De plus, est ce qu'on a vraiment besoin de toutes ces variables globales ? J'en doute fortement.

Main.h/Main.c

Je doute de l'utilité de Main.h : dans quel autre .c, Main.h devrait-il être inclus ?
Par contre on devrait avoir dans Main.c

Code :

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

1
2
#include "Fenetre.h" // pour OuvertureFenetre();
#include "Classe.h" // pour ClassRegister();

[andrebernard]

Bonjour,
Ben, je vous assure, ça fait plaisir.

C'est vraiment sincère...en fait la force d'un langage provient beaucoup de sa collectivité, de ses forums.
Que serait LINUX sans sa communauté, internet et ses forums
Je le vois bien avec celui d'où je viens, sans le forum, j'aurais abandonné au bout de quelques mois

Et puis avec le mal que vous vous étés donné pour aider un oisillon dans l'œuf, il serait tres ingrat de ne pas vous prévenir quand il becte ses premières petites graines

Il ne faut pas définir de variables dans un .h .

Bon..je crois que j'ai parlé trop vite
En fait j'ai bettement confondu les constantes et les variables.
Je me suis dit, je vais tout déclarer dans les .h

Bon c'est noté...que les constantes et les procedures dans les .h
Et en plus la protection anti doublon, c'est tout

Code :

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

1
2
3
#ifndef Label
 #define Label
#endif

Pourquoi le prototype déclaré dans classe.h ? classe.c ne définit pas cette fonction (et ne l'utilise pas non plus)

Bah si...enfin je crois
C'est justement l' erreur la plus dure du débugger que j'ai eu a trouver et la dernière.
Il voulait pas compiler, et je ne comprenais pas pourquoi, il me disait de déclarer WndProc, et moi je voyais pas pourquoi il disait ça.
Au debut j'ai rajouté une declaration HWND WndProc;, mais quedal...toujours l'erreur
Alors j'ai fait une recherche dans toute la source, et je me suis aperçu qu'il etait aussi dans la ligne LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam);
Alors j'ai rajouté cette ligne...et plus de bug

Même remarque sur les variable globales HWND hWnd; MSG msg; HWND hWndB1; HWND hWndB2;
De plus, est ce qu'on a vraiment besoin de toutes ces variables globales ? J'en doute fortement.

Non tu as raison...en fait comme une prune, je les ai déplace du local au GLOBAL en croyant bien faire comme je te l'ai dit au dessus
Mais promis...je le ferais plus

Je doute de l'utilité de Main.h : dans quel autre .c, Main.h devrait-il être inclus ?

Toujours raison...en fait j'ai créé un .h par .c en déclarant dans le .h tous les prototypes contenu dans le .c sans regarder si je pouvais croiser les .h
J'ai donc inclus dans le .h de main.c le #include <windows.h> puis le
void ClassRegister(hInstance, nCmdShow);
OuvertureFenetre(hInstance, nCmdShow);

Et le
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow); car il est aussi dans main.c

Et au moins avec ce que j'ai écris ça mélange pas les .h, parce que pour quelqu'un qui commence comme moi...c'est bien clair, comme vous me l'avez dit, un .h pour un .c et on déclare les prototypes et les constantes croisées dans les .c afin que le compilateur laisse des "trous" et les connaissent avant de les rencontrer

En fin de compte c'est un peu pareil, non ??, puisque le compilateur me dit que c'est bon ???? ou bien faut pas toujours l'écouter ???

En tout cas merci de ta correction

[diogene]

Pourquoi le prototype déclaré dans classe.h ? classe.c ne définit pas cette fonction (et ne l'utilise pas non plus)

Bah si...enfin je crois

Oui, je n'avais pas vu .

Si je récapitule (sans me tromper, j'espère), on a :

Code :

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

1
2
3
4
5
6
7
              Classe.c               Fenetre.c                main.c
            ----------------------------------------------------------------
Définition   ClassRegister()         WndProc()
                                 OuvertureFenetre() 
            ----------------------------------------------------------------
Utilise       WndProc()              ....                  ClassRegister() 
                                                          OuvertureFenetre()

On devrait alors avoir :

Code :

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

1
2
3
4
              Classe.h               Fenetre.h                
            ----------------------------------------------------------------
déclaration  ClassRegister()         WndProc()
                                   OuvertureFenetre()

et pour les include :

Code :

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

1
2
3
4
              Classe.c               Fenetre.c                main.c
            ----------------------------------------------------------------
Include       Classe.h               Fenêtre.h                Classe.h
              Fenetre.h                                       Fenetre.h

En fin de compte c'est un peu pareil, non ??, puisque le compilateur me dit que c'est bon ???? ou bien faut pas toujours l'écouter ???

Si il est content, tout va bien. Mais il vaut mieux prendre l'habitude de structurer les choses, c'est important si le projet devient conséquent. Ce n'est pas une bonne idée de multiplier une même déclaration en plusieurs endroits. Si on est amené à la modifier, on va se retrouver à charcuter un peu partout. Le rôle des fichiers d'en-tête est justement d'éviter cela.

[andrebernard]

Mais il vaut mieux prendre l'habitude de structurer les choses, c'est important si le projet devient conséquent

Tu as mille fois raison, mais pour l'optimisation, j'en suis pas encore la

Tu sais..pour moi c'est loin d'être encore évident l'histoire des .h et .c.
Enfin si, .....comme vous me l'avez expliqué au plus simple, un .h pour un .c
Et déclarer dans le .h avant qu'il rencontre une fonction dans le .c
Mais alors si faut que je croise les .h ...., j'suis pas sorti de l'auberge

Si il est content, tout va bien.

Oui c'est sur, et pour moi c'est deja un grand pas
Bon pour l'instant j'arrive a être un peu copain avec le compilateur et qu'il arrête de me mettre des baffes....je vais attendre un peu pour lui demander de venir manger à la maison

Mais je te remercie d'essayer...avec moi....faut savoir se contenter de peu...
Tous mes professeurs et ceux qui ont essayé de m'apprendre quelque chose, l'ont vite compris

Je te souhaite une bonne journée

[Invité]

J'appuierai (plussoie c'est mieux) encore diogène, il est indispensable de structurer toute son organisation. Quand on arrive à un programme d'une centaine de modules, avec chacun un grand nombre de fonctions, là on s'en rend compte. Mais si on n'a pas structuré dès le début, ça m'étonnerait qu'on réussisse à arriver à un tel volume.
Il arrive qu'un module devienne trop gros à gérer, alors il vaut mieux le scinder. J'ai pris l'habitude de garder les mêmes noms pour les modules "bis" et je rajoute un indice (A, B, etc) au .c, le module lui-même. Toute la partie entête (les .h) est identiques, donc simplement à "copier-coller".
Bonne continuation.

[diogene]

Ce ne sont pas tes profs qui acceptent de se contenter de peu, c'est toi !
Tu as un petit programme facile à manipuler qui te donne dans la foulée l'occasion de comprendre comment faire correctement certaines choses. Ce n'est pas au moment où tu auras pondu une usine à gaz que tu pourras le faire.
Ton programme n'est pas intéressant en soi, c'est ce qu'il peut t'apprendre qui compte.

Avoir réussi à faire tourner ce programme est une bonne chose. S'arrêter en chemin est une erreur : tu dois avoir l'ambition de l'écrire correctement avant de poursuivre.

Bonne journée

[andrebernard]

Oui oui..je comprend bien que vous avez raison ...
Ce que je ne comprend pas c'est comment fait DIOGENE pour simplifier.

C'est comme en math, je me rappelle, le prof disait que simplifier c'était mieux.
Moi je l'ai toujours cru....c'est sur qu'une fois qu'il avait simplifié, on reconnaissait même pas la formule de départ, et c'était beau.

Seulement j'ai essayé de simplifier des dizaines de fois..et a chaque fois j'arrivais a un résultat faux.
Alors je suis resté avec mes formules a rallonge

En fin de compte, pour avoir la faculté de simplifier, faut déjà maitriser pas mal de concept. On pourrait dire que c'est pas simple de simplifier

Ca me rappelle une réflexion que l'on se faisait avec mon collègue de travail, qui rejoint un peu ce que l'on est en train de dire.
Un programme plus il parait simple a l'utilisateur, plus le programmeur s'est cassé la nouille pour qu'il le devienne.

Au final, la complexité ne disparait pas avec la simplification, elle se déplace seulement.
Comme elle passe de la formule finale au mathématicien.
Le mathématicien fait deux heures de simplification, afin que l'utilisateur lui n'est qu'une équation de quelques caractères
Et bien la simplification est apportée par le programmeur afin que l'utilisateur se retrouve avec un programme intuitif et simplifié au maximum

Dans ce bas monde...rien ne se créé...et rien ne disparait...tout se transforme
Et ben moi, étant donné que j'ai encore pas compris comment DIOGENE ,comme le mathématicien il fait pour simplifier...et bah je vais laisser la complexité a mon nouvel ami le compilateur qui est bien plus fort que moi en C

Et puis si un jour il accepte de venir manger à la maison, alors la....je pense que je pourrais relancer le sujet avec DIOGENE et essayer de comprendre comment il arrive a certaines choses qui au stade ou j'en suis sont encore du domaine du miracle

N'oublie pas que je sort de l'œuf et que pour moi...vous êtes encore des sorciers vaudoux

[andrebernard]

Ton programme n'est pas intéressant en soi, c'est ce qu'il peut t'apprendre qui compte.

Tu as posté en même temps que moi

Exactement c'est pourquoi je m'attache a ce code sans essayer de le compliquer, comme une puce a un chien, pour bien comprendre les bases de la gestion des fenêtres.

Ce ne sont pas tes profs qui acceptent de se contenter de peu, c'est toi !

Mais tu as eu la patience de me faire des jolis cadres
Et j'ai pas mieux compris comment tu raisonnes, pour ça.

Et je trouve que vous en faites deja beaucoup pour moi....alors je vais pas abuser, en demandant de multiplier chaque explication par 4, sous différentes formes.
Si je comprend pas tout de suite ou presque...et que ça marche...je continue doucement mon bonhomme de chemin.
Je sais que c'est pas pro, car j'apprends toujours au bout de 20 ans des choses sur VB....
Mais bon...si je les apprend que maintenant..c'est peut être qu'au bout de 20 ans je me suis améliore et que je comprend bien mieux qu'a mes débuts, et peut être aussi, que je n'en avais pas vraiment besoin jusque la..sinon j'aurais été coincé

C'est vrai que apprendre pas dans l'ordre est une véritable connerie, je vous l'accorde, mais encore une fois, quand je comprend pas..plus j'insiste, plus ça se bloque.
Alors des fois , je passe a la suite et quelques temps plus tard, en douceur, je comprend un truc qu'on s'est évertué a m'expliquer et que je n'ai jamais compris, et en plus je le comprend alors qu'on en parle plus et que parfois on est sur un autre sujet