Tutorial : Programmer en 'C' sous windows.

Le 13/03/2008 12:17, Vincent Burel a écrit :

http://pagesperso-orange.fr/vb-audio/fr/pub/programming/index.htm

[...] si j'ai fais des bourdes [...]

<cit.>
<A HREF="http:\www.charlespetzold.com" TARGET=_new>Charles Petzold</A>
<A HREF="http:\www.msdn.com" TARGET=_new>
</cit.>

Remplacer les « \ » par des « // » (il y en a peut-être d'autres dans
la page, mais ce sont ceux sur lesquels j'ai essayé de cliquer sans
succès). Et personnellement je virerais aussi les attributs TARGET.

"Olivier Miakinen" <om+news@miakinen.net> wrote in message
news:47d91565$1@neottia.net...

Le 13/03/2008 12:17, Vincent Burel a écrit :
>
> http://pagesperso-orange.fr/vb-audio/fr/pub/programming/index.htm
>
> [...] si j'ai fais des bourdes [...]

<cit.>
<A HREF="http:\www.charlespetzold.com" TARGET=_new>Charles Petzold</A>
<A HREF="http:\www.msdn.com" TARGET=_new>
</cit.>

Remplacer les « \ » par des « // » (il y en a peut-être d'autres dans
la page, mais ce sont ceux sur lesquels j'ai essayé de cliquer sans
succès). Et personnellement je virerais aussi les attributs TARGET.

d'accord c'est corrigé. merci.

Le 13/03/2008 13:12, Vincent Burel a écrit :

Remplacer les « \ » par des « // »

d'accord c'est corrigé. merci.

C'est parfait. Pour ce qui est du contenu effectif, je suis intéressé
car je suis censé corriger des programmes Windows assez complexes mais
que je n'ai pas encore les bases. Si je trouve le temps de m'y mettre,
ce que je souhaite, je te donnerai mon avis.

Cordialement,
--
Olivier Miakinen

Vincent Burel wrote on 13/03/2008 12:17:

hello,

Bon, ben, puisque je me suis proposé de le faire, voila une première page
pour un tutorial d'apprentissage de la programmation sous windows en 'C'.
http://pagesperso-orange.fr/vb-audio/fr/pub/programming/index.htm

- dessiner dans une window frame est une mauvaise idée.
vous pouvez limiter le contenu à ce qui présenté ici mais
conclure que le rendu du texte "This Text Is always displayed"
n'est pas agréable / acceptable et qu'un child spécialisé
pour l'affichage des infos et occupant l'espace client du
frame est requis (et Cf cours suivant).

- "#include "minprg.h" ne sert sûrement à rien (les fonctions
de minprg.c n'ont pas besoin d'êre exportées) - vous ne
fournissez pas ce fichier s'il existe.


- évitez la redondance et la recopie inutile de string
d'interface, par exemple:

char message[512];
strcpy(message,"Do you Want To Close This Application ?");
rep=MessageBox(hw, message, titre,
MB_APPLMODAL | MB_YESNO | MB_ICONQUESTION);

se code (toute chose égale par ailleurs):

rep=MessageBox(hw, "Do you Want To Close This Application ?",
titre, MB_APPLMODAL | MB_YESNO | MB_ICONQUESTION);

le recours à un buffer char local n'a de sens que si vous
chargiez une ressource string (éventuellement localisée).
eg:

char message[512];
if (LoadString(G_hinstance, IDS_CONFIRMCLOSE, message, 512) == 0)
strcpy(message,"Do you Want To Close This Application ?");
rep=MessageBox(hw, message, titre,
MB_APPLMODAL | MB_YESNO | MB_ICONQUESTION);

(ayant défini IDS_CONFIRMCLOSE en resource évidemment).
cetet gestion via ressource de tous éléments localisables
est de fait une bonne habitude à prendre très tôt.


- le 2nd parametre de'un méthode de traitement des messages
n'est pas un "event type" mais un identifiant (unique) de
messages - d'autres GUI utilise des events types (MacOS)
par exemple; on distinguera alors selon ces types puis selon
le message effectif appartenant à ce type; windows est plus
primaire et donne ici le message lui-même; les évolutions
de windows se sont accomodées de ce manque de distinction
via les messages de notification et des structures variées.


- le test "if (G_hwnd_MainWindow==NULL) return 0;" avant
la loop detraitement des msg est inutile (fait 3 lignes
avant).

Sylvain.

"Sylvain" <noSpam@mail.net> wrote in message
news:47d990f0$0$857$ba4acef3@news.orange.fr...

Vincent Burel wrote on 13/03/2008 12:17:
> hello,
>
> Bon, ben, puisque je me suis proposé de le faire, voila une première

page

> pour un tutorial d'apprentissage de la programmation sous windows en

'C'.

> http://pagesperso-orange.fr/vb-audio/fr/pub/programming/index.htm

- dessiner dans une window frame est une mauvaise idée.
vous pouvez limiter le contenu à ce qui présenté ici mais
conclure que le rendu du texte "This Text Is always displayed"
n'est pas agréable / acceptable et qu'un child spécialisé
pour l'affichage des infos et occupant l'espace client du
frame est requis (et Cf cours suivant).

Mouai bof, dans un premier temps (avant d'utiliser des controles CHILD) je
veux faire comprendre qu'on peut faire ce qu'on veut de sa surface
d'affichage (ca sera d'ailleurs bien montré dans la prochaine leçon).
Positionner des controles arrivera en 3 ieme leçon. Quant au controles
static (que je n'utilise d'ailleurs jamais), je pense qu'ils ont du sens
quand on utilise des RAD pour faire des formulaires ou des pages en
positionnant les contrôle à la souris sur une grille... De manière générale,
je ne suis pas fan du controle pour tout et n'importe quoi. C'est un peu ce
que j'appelle le syndrome du ++ , on créer des objets qui délèguent à des
sous objets, qui eux même délèguent etc... ou le syndrome de la grille Excel
faites avec 3 millions d'edit Box. Y'a un moment il faut faire le job et il
faut arréter de créer des objets, et même le bouton poussoir doit écrire le
label du bouton dans sa Client-Area et ne va pas faire appel à un controle
static pour ca...

- "#include "minprg.h" ne sert sûrement à rien (les fonctions
de minprg.c n'ont pas besoin d'êre exportées) - vous ne
fournissez pas ce fichier s'il existe.

oui, c'est plus par habitude. Ceci dit le .h contient des define utilisés
par minprg.c, donc il vaut mieux l'inclure...

- évitez la redondance et la recopie inutile de string
d'interface, par exemple:

char message[512];
strcpy(message,"Do you Want To Close This Application ?");
rep=MessageBox(hw, message, titre,
MB_APPLMODAL | MB_YESNO | MB_ICONQUESTION);

se code (toute chose égale par ailleurs):

rep=MessageBox(hw, "Do you Want To Close This Application ?",
titre, MB_APPLMODAL | MB_YESNO | MB_ICONQUESTION);

le recours à un buffer char local n'a de sens que si vous
chargiez une ressource string (éventuellement localisée).
eg:

char message[512];
if (LoadString(G_hinstance, IDS_CONFIRMCLOSE, message, 512) == 0)
strcpy(message,"Do you Want To Close This Application ?");
rep=MessageBox(hw, message, titre,
MB_APPLMODAL | MB_YESNO | MB_ICONQUESTION);

(ayant défini IDS_CONFIRMCLOSE en resource évidemment).
cetet gestion via ressource de tous éléments localisables
est de fait une bonne habitude à prendre très tôt.

D'accord , pour ma part c'est plus une question d'habitude, je copie
toujours mes string en local (parce que c'est pas rare que j'ai à les
modifier etc...). Ceci dit, Je n'utilise jamais de string en ressource, mais
je pense que c'est intéressant d'intégrer votre exemple ici si vous me
permettez...

- le 2nd parametre de'un méthode de traitement des messages
n'est pas un "event type" mais un identifiant (unique) de
messages - d'autres GUI utilise des events types (MacOS)
par exemple; on distinguera alors selon ces types puis selon
le message effectif appartenant à ce type; windows est plus
primaire et donne ici le message lui-même; les évolutions
de windows se sont accomodées de ce manque de distinction
via les messages de notification et des structures variées.

Mouai, c'est polémique car le message ID est fonction d'un event type quand
même... bon, je vais changer le commentaire.

- le test "if (G_hwnd_MainWindow==NULL) return 0;" avant
la loop detraitement des msg est inutile (fait 3 lignes
avant).

ouai, exact !

Merci d'avoir jeté un oeil !
VB

Vincent Burel wrote on 13/03/2008 22:53:

Mouai bof, dans un premier temps (avant d'utiliser des controles CHILD) je
veux faire comprendre qu'on peut faire ce qu'on veut de sa surface
d'affichage (ca sera d'ailleurs bien montré dans la prochaine leçon).

je n'ai pas parlé de "controles child" - j'ai dit que l'on ne dessinait
jamais dans un frame (mais dans une *window* *child* donc frameless).

[...] ... ou le syndrome de la grille Excel
faites avec 3 millions d'edit Box.

non aucun.

[...] et même le bouton poussoir doit écrire le
label du bouton dans sa Client-Area et ne va pas faire appel à un controle
static pour ca...

?!? un contrôle button est un contrôle, que voulez-vous qu'il soit ??
il stocke son caption et l'affiche dans sa zone.
vous voudriez stocker ce libellé dans la status-bar et l'afficher
dans la NC-area de la bordure ?
utiliser un child-control de type button c'est justement ne pas
réinventer la roue avec des winProcs et/ou des traitements à soi.


btw, les arguments (partiellement) cités ici n'étonnent beaucoup !

vouloir réaliser un "tutorial: programmer en C sous windows"
ne devrait en aucun cas s'alimenter de tous ces a-priori mais
respecter l'état de l'art, les bonnes façons de faire.

par exemple, je l'ai oublié dans mon post précédent, on ne fera jamais:

in WndProc:
case WM_COMMAND:
// switch on menuItemID
case IDT_DOSOMETHING:
dc=GetDC(hw);
strcpy(sss,"I write something in the Client Area");
TextOut(dc,0,0,sss,(int)strlen(sss));
ReleaseDC(hw,dc);
break;

car rien ne garantit que le DC soit prêt pour un affichage
et qu'il est disponible (vous ne le testez pas), et car ce
texte sera perdu dès le premier update.
on n'écrit jamais directement dans un DC, on fait cela
uniquement dans le traitement d'un WM_UPDATE.

- "#include "minprg.h" ne sert sûrement à rien (les fonctions
de minprg.c n'ont pas besoin d'êre exportées) - vous ne
fournissez pas ce fichier s'il existe.

oui, c'est plus par habitude. Ceci dit le .h contient des define utilisés
par minprg.c, donc il vaut mieux l'inclure...

donc il vaut mieux le fournir...

Mouai, c'est polémique car le message ID est fonction d'un event type quand
même... bon, je vais changer le commentaire.

non il n'est nullement "fonction de", la numérotation des msgID tient
même du va-comme-je-te-pousse.

Sylvain.

"Sylvain" <noSpam@mail.net> wrote in message
news:47d9b7e3$0$876$ba4acef3@news.orange.fr...

Vincent Burel wrote on 13/03/2008 22:53:
>
> Mouai bof, dans un premier temps (avant d'utiliser des controles CHILD)

je

> veux faire comprendre qu'on peut faire ce qu'on veut de sa surface
> d'affichage (ca sera d'ailleurs bien montré dans la prochaine leçon).

je n'ai pas parlé de "controles child" - j'ai dit que l'on ne dessinait
jamais dans un frame (mais dans une *window* *child* donc frameless).

Ben, d'abord je ne vois pas de différence entre control child ou windows
child (c'est techniquement la même chose). Ensuite je ne vois pas en vertue
de quoi je m'interdirais de dessiner dans une fenêtre dotée d'un cadre.

> [...] et même le bouton poussoir doit écrire le
> label du bouton dans sa Client-Area et ne va pas faire appel à un

controle

> static pour ca...

?!? un contrôle button est un contrôle, que voulez-vous qu'il soit ??

C'est d'abord une fenetre, qu'elle soit borderless, frameless ou autre, n'a
aucune importance et selon votre principe, cette fenetre pourrait créer un
control static pour afficher son label, plutot que de dessiner directement
dans sa zone client...

btw, les arguments (partiellement) cités ici n'étonnent beaucoup !

Alors vous n'avez pas fini d'être étonné :-) mais ca devrait vous réjouir.

> vouloir réaliser un "tutorial: programmer en C sous windows"

ne devrait en aucun cas s'alimenter de tous ces a-priori mais
respecter l'état de l'art, les bonnes façons de faire.

Au contraire, c'est vous qui faites preuve de rigidité, encore une fois je
ne vois pas en vertue de quoi il faudrait que je m'interdise de dessiner
dans une Window-frame, et que j'utilise des controles statique ? y'a une loi
qqc part ou quoi ?

par exemple, je l'ai oublié dans mon post précédent, on ne fera jamais:

in WndProc:
case WM_COMMAND:
// switch on menuItemID
case IDT_DOSOMETHING:
dc=GetDC(hw);
strcpy(sss,"I write something in the Client Area");
TextOut(dc,0,0,sss,(int)strlen(sss));
ReleaseDC(hw,dc);
break;

car rien ne garantit que le DC soit prêt pour un affichage
et qu'il est disponible (vous ne le testez pas), et car ce
texte sera perdu dès le premier update.
on n'écrit jamais directement dans un DC, on fait cela
uniquement dans le traitement d'un WM_UPDATE.

Il est vrai qu'on devrait tester la validité du dc (dc != NULL) cependant je
ne le fais jamais sur un GetDC, dans la pratique je n'ai jamais vu le cas ou
alors c'est que le système a un gros probleme. Alors cet exemple ici montre
que l'on peut dessiner directement (et dans l'immédiateté) dans notre
fenetre, mais que cet affichage n'est pas persistant. Si votre remarque est
bonne, votre absolutisme l'est moins, car contrairement à ce que suggère vos
"jamais", les affichages directs servent beaucoup, d'abord pour les
affichages temps réel (par exemple dépendant d'un TIMER), ensuite pour
mettre à jour une partie de son interface sans avoir à faire un
Invalidate/update Globale (qui peut prendre un certain temps). Bref, je vais
intégrer tout ca sous forme de Q&A...

>> - "#include "minprg.h" ne sert sûrement à rien (les fonctions
>> de minprg.c n'ont pas besoin d'êre exportées) - vous ne
>> fournissez pas ce fichier s'il existe.
>
> oui, c'est plus par habitude. Ceci dit le .h contient des define

utilisés

> par minprg.c, donc il vaut mieux l'inclure...

donc il vaut mieux le fournir...

comment ca ? il est bien fournit ! non ?

> Mouai, c'est polémique car le message ID est fonction d'un event type

quand

> même... bon, je vais changer le commentaire.

non il n'est nullement "fonction de", la numérotation des msgID tient
même du va-comme-je-te-pousse.

J'imagine que vous entendez "fonction de" au sens mathématique du terme...

Merci pour vos remarques, mais gaffe au trolling quand même :-)
VB

> je n'ai pas parlé de "controles child" - j'ai dit que l'on ne dessinait
jamais dans un frame (mais dans une *window* *child* donc frameless).

Je me permets de mettre mon grain de soufre. Il me semble que Vincent
construit un tutoriel d'apprentissage des *bases* de la programmation
Windows. Je ne vois pas pourquoi il faudrait dès la première leçon
indiquer tout un jeu de règles qui relèvent de niveaux bien supérieurs,
sauf à vouloir faire en sorte que l'apprenti n'y comprenne plus rien.

Techniquement, rien n'interdit de dessiner dans un frame.
Pédagogiquement, c'est la façon la plus simple de faire. Pourquoi se
bloquer sur un argument qui sera sans doute développé à la leçon n° 14
ou 15 ?

car rien ne garantit que le DC soit prêt pour un affichage
et qu'il est disponible (vous ne le testez pas),

Bah, si vous devez tester toutes les conditions hautement improbables,
votre programme va contenir beaucoup de gras. Ne me faites pas dire ce
que je n'ai pas dit, hein, je teste beaucoup de cas *peu* probables dans
mes programmes, mais une fois encore, n'oubliez pas que c'est la leçon
n° 1 d'un tutoriel. Ne focalisez pas l'apprenti sur des trucs de énième
niveau si vous voulez qu'il mette le pied à l'étrier. C'est déjà assez
compliqué comme ça à assimiler pour un débutant.

on n'écrit jamais directement dans un DC, on fait cela
uniquement dans le traitement d'un WM_UPDATE.

Et pourtant je fais ça de temps en temps, justement quand je ne veux pas
que l'affichage soit persistant (dessin mobile, affichage de données
variant rapidement, rubans d'aide, etc.). Ce "jamais" n'est pas écrit
dans le marbre. Tout dépend de la durée de vie de ce qu'on veut
afficher. Si vous voulez un affichage rapide et constamment rafraîchi,
passer par un intermédiaire fait perdre du temps et n'apporte rien.

"Bertrand Lenoir-Welter" <bertrand-dot-2008-at-galaad-dot-net> a écrit dans
le message de news:47da500b$0$876$ba4acef3@news.orange.fr...

je n'ai pas parlé de "controles child" - j'ai dit que l'on ne dessinait
jamais dans un frame (mais dans une *window* *child* donc frameless).

Je me permets de mettre mon grain de soufre. Il me semble que Vincent
construit un tutoriel d'apprentissage des *bases* de la programmation
Windows. Je ne vois pas pourquoi il faudrait dès la première leçon
indiquer tout un jeu de règles qui relèvent de niveaux bien supérieurs,
sauf à vouloir faire en sorte que l'apprenti n'y comprenne plus rien.
[...]

Entièrement d'accord !

Je trouve remarquable la démarche PÉDAGOGIQUE de Vincen (et son contenu), et
je trouve lamentable que des ayatollahs atrabilaires (même si stricto sensu
ils peuvent avoir raison sur certains points) ne pensent qu'à le critiquer
au lieu de le féliciter et le REMERCIER !
Ces intégristes n'ont visiblement JAMAIS ENSEIGNÉ !

La vulgarisation est un art très difficile.
Il est IMPOSSIBLE de TOUT dire d'un seul coup.
Pour se faire comprendre des débutants (ce qui leur permettra par la suite
d'assimiler des notions plus complexes, de façon exponentielle), il faut
partir sur des bases SIMPLES et laisser de coté tout PURISME!

En ce qui me concerne, comme tout le monde, j'ai commencé par écrire "Hello
World" dans une fenêtre.
La POO, les hooks, le multithreading, ... c'est venu bien après !

Avant de résoudre des équations différentielles aux dérivées partielles, on
apprend les quatres opérations!

<A Vincent >
N'oublie jamais les proverbes :
"Bien faire et laisser braire!"
"Les chiens aboient, la caravane passe!"
;-)

Si je vois une conceté flagrante dans ton tutoriel, je te la signalerai
amicalement, car il n'y a que les glandeurs qui ne font pas d'erreur !

Et encore MERCI pour ton boulot !

</A Vincent >

--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org

Vincent Burel wrote on 14/03/2008 07:03:

Merci pour vos remarques, mais gaffe au trolling quand même :-)

tout à fait !

inutile d'en rajouter, je pensais avoir été clair -
concernant l'affichage mon premier post disait clairement:
on peux dessiner ainsi, mais on pourra prévilégier une
fenêtre dédiée et donner rendez-vous aux cours suivant -
le 14 ou 15e si cela convient à Bertrand - pour l'appliquer.

pour plaire à JC je vais braire mon ayatollisme ailleurs,
je n'ai plus fait de tutos depuis des années et les élèves
ont sûrement bcp changés.

Sylvain.