La leçon 4 : Mes premiers Controles Windows
http://pagesperso-orange.fr/vb-audio/fr/pub/programming/Lesson04/Lesson04.htm
Voici donc un exemple de code se proposant de montrer comment fabriquer ses
propres controles Windows.
j'espère avoir fait un topo clair (étant donné le nombre de soirée que ca
m'a pris :-), mais je complèterai surement la section Q and A pour apporter
des précisions...
Déjà je peux vous mettre à contribution pour une question :
quand on ouvre une message box (about box ou confirmation de fermeture) le
code est censé attendre la sortie de l'appel à ce MessageBox (ce sont des
dialogues modales), pourtant nous continuons de recevoir des message
WM_TIMER. Comment expliquer ce phénomène simplement ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sylvain SF
Vincent Burel wrote on 03/04/2008 11:12:
Déjà je peux vous mettre à contribution pour une question : quand on ouvre une message box (about box ou confirmation de fermeture) le code est censé attendre la sortie de l'appel à ce MessageBox (ce sont des dialogues modales), pourtant nous continuons de recevoir des message WM_TIMER. Comment expliquer ce phénomène simplement ?
MessageBox(..) utile sa propre pompe à message pour recevoir les events destinés au dialogue qu'il contrôle, mais le thread principal (et la pompe principale) continue de recevoir les msg qui sont destinés à toutes les fenêtres qu'il contrôle.
on reçoit des WM_TIMER mais également des WM_UPDATE (les fenêtres sont le dialogue modal sont bien redessinées) et tous messages qui ne soit pas un ""user event"" (event souris ou clavier).
une explication possible est justement qu'un élément modal prive les autres éléments d'évènements utilisateur (tous les autres events "plus systèmes" continuant à être diffusés).
Sylvain.
Vincent Burel wrote on 03/04/2008 11:12:
Déjà je peux vous mettre à contribution pour une question :
quand on ouvre une message box (about box ou confirmation de fermeture) le
code est censé attendre la sortie de l'appel à ce MessageBox (ce sont des
dialogues modales), pourtant nous continuons de recevoir des message
WM_TIMER. Comment expliquer ce phénomène simplement ?
MessageBox(..) utile sa propre pompe à message pour recevoir les events
destinés au dialogue qu'il contrôle, mais le thread principal (et la
pompe principale) continue de recevoir les msg qui sont destinés à
toutes les fenêtres qu'il contrôle.
on reçoit des WM_TIMER mais également des WM_UPDATE (les fenêtres sont
le dialogue modal sont bien redessinées) et tous messages qui ne soit
pas un ""user event"" (event souris ou clavier).
une explication possible est justement qu'un élément modal prive les
autres éléments d'évènements utilisateur (tous les autres events "plus
systèmes" continuant à être diffusés).
Déjà je peux vous mettre à contribution pour une question : quand on ouvre une message box (about box ou confirmation de fermeture) le code est censé attendre la sortie de l'appel à ce MessageBox (ce sont des dialogues modales), pourtant nous continuons de recevoir des message WM_TIMER. Comment expliquer ce phénomène simplement ?
MessageBox(..) utile sa propre pompe à message pour recevoir les events destinés au dialogue qu'il contrôle, mais le thread principal (et la pompe principale) continue de recevoir les msg qui sont destinés à toutes les fenêtres qu'il contrôle.
on reçoit des WM_TIMER mais également des WM_UPDATE (les fenêtres sont le dialogue modal sont bien redessinées) et tous messages qui ne soit pas un ""user event"" (event souris ou clavier).
une explication possible est justement qu'un élément modal prive les autres éléments d'évènements utilisateur (tous les autres events "plus systèmes" continuant à être diffusés).
Sylvain.
Vincent Burel
"Sylvain SF" wrote in message news:47f4a618$0$898$
Vincent Burel wrote on 03/04/2008 11:12: > > Déjà je peux vous mettre à contribution pour une question : > quand on ouvre une message box (about box ou confirmation de fermeture)
le
> code est censé attendre la sortie de l'appel à ce MessageBox (ce sont
des
> dialogues modales), pourtant nous continuons de recevoir des message > WM_TIMER. Comment expliquer ce phénomène simplement ?
MessageBox(..) utile sa propre pompe à message pour recevoir les events destinés au dialogue qu'il contrôle, mais le thread principal (et la pompe principale) continue de recevoir les msg qui sont destinés à toutes les fenêtres qu'il contrôle.
qui dit "seconde pompe à messages" dit seconde boucle de message, donc second thread, or il ne me semble pas qu'un nouveau thread se crée à l'ouverture d'une boite de dialogue modale.
on reçoit des WM_TIMER mais également des WM_UPDATE (les fenêtres sont le dialogue modal sont bien redessinées) et tous messages qui ne soit pas un ""user event"" (event souris ou clavier).
oui, même des MOUSEMOVE si j'en crois le spy++
une explication possible est justement qu'un élément modal prive les autres éléments d'évènements utilisateur (tous les autres events "plus systèmes" continuant à être diffusés).
comment expliquer que notre code attende la sortie de la fonction MessageBox et qu'il puisse en même temps continuer de faire tourner la boucle de message ?
VB
"Sylvain SF" <sylvain@boiteaspam.info> wrote in message
news:47f4a618$0$898$ba4acef3@news.orange.fr...
Vincent Burel wrote on 03/04/2008 11:12:
>
> Déjà je peux vous mettre à contribution pour une question :
> quand on ouvre une message box (about box ou confirmation de fermeture)
le
> code est censé attendre la sortie de l'appel à ce MessageBox (ce sont
des
> dialogues modales), pourtant nous continuons de recevoir des message
> WM_TIMER. Comment expliquer ce phénomène simplement ?
MessageBox(..) utile sa propre pompe à message pour recevoir les events
destinés au dialogue qu'il contrôle, mais le thread principal (et la
pompe principale) continue de recevoir les msg qui sont destinés à
toutes les fenêtres qu'il contrôle.
qui dit "seconde pompe à messages" dit seconde boucle de message, donc
second thread, or il ne me semble pas qu'un nouveau thread se crée à
l'ouverture d'une boite de dialogue modale.
on reçoit des WM_TIMER mais également des WM_UPDATE (les fenêtres sont
le dialogue modal sont bien redessinées) et tous messages qui ne soit
pas un ""user event"" (event souris ou clavier).
oui, même des MOUSEMOVE si j'en crois le spy++
une explication possible est justement qu'un élément modal prive les
autres éléments d'évènements utilisateur (tous les autres events "plus
systèmes" continuant à être diffusés).
comment expliquer que notre code attende la sortie de la fonction MessageBox
et qu'il puisse en même temps continuer de faire tourner la boucle de
message ?
"Sylvain SF" wrote in message news:47f4a618$0$898$
Vincent Burel wrote on 03/04/2008 11:12: > > Déjà je peux vous mettre à contribution pour une question : > quand on ouvre une message box (about box ou confirmation de fermeture)
le
> code est censé attendre la sortie de l'appel à ce MessageBox (ce sont
des
> dialogues modales), pourtant nous continuons de recevoir des message > WM_TIMER. Comment expliquer ce phénomène simplement ?
MessageBox(..) utile sa propre pompe à message pour recevoir les events destinés au dialogue qu'il contrôle, mais le thread principal (et la pompe principale) continue de recevoir les msg qui sont destinés à toutes les fenêtres qu'il contrôle.
qui dit "seconde pompe à messages" dit seconde boucle de message, donc second thread, or il ne me semble pas qu'un nouveau thread se crée à l'ouverture d'une boite de dialogue modale.
on reçoit des WM_TIMER mais également des WM_UPDATE (les fenêtres sont le dialogue modal sont bien redessinées) et tous messages qui ne soit pas un ""user event"" (event souris ou clavier).
oui, même des MOUSEMOVE si j'en crois le spy++
une explication possible est justement qu'un élément modal prive les autres éléments d'évènements utilisateur (tous les autres events "plus systèmes" continuant à être diffusés).
comment expliquer que notre code attende la sortie de la fonction MessageBox et qu'il puisse en même temps continuer de faire tourner la boucle de message ?
VB
Vincent Burel
"Vincent Burel" wrote in message news:47f4adc2$0$832$
"Sylvain SF" wrote in message news:47f4a618$0$898$ > Vincent Burel wrote on 03/04/2008 11:12: > > > > Déjà je peux vous mettre à contribution pour une question : > > quand on ouvre une message box (about box ou confirmation de
fermeture)
le > > code est censé attendre la sortie de l'appel à ce MessageBox (ce sont des > > dialogues modales), pourtant nous continuons de recevoir des message > > WM_TIMER. Comment expliquer ce phénomène simplement ? > > MessageBox(..) utile sa propre pompe à message pour recevoir les events > destinés au dialogue qu'il contrôle, mais le thread principal (et la > pompe principale) continue de recevoir les msg qui sont destinés à > toutes les fenêtres qu'il contrôle.
qui dit "seconde pompe à messages" dit seconde boucle de message, donc second thread, or il ne me semble pas qu'un nouveau thread se crée à l'ouverture d'une boite de dialogue modale.
non, c'est vous qui avait raison, mais je reformule, l'appel à MessageBox (ou à toute ouverture de boite de dialogue modale) fait rentrer le code dans la boucle de message de la boite de dialogue. Ce n'est plus notre MessageLoop qui traite les événement mais celle de la boite de dialogue. et c'est cette boucle qui par le dispatch appelle notre callback avec l'événement WM_TIMER par exemple.
d'accord ? VB
"Vincent Burel" <vincent.burel@nospam.wanadoo.fr> wrote in message
news:47f4adc2$0$832$ba4acef3@news.orange.fr...
"Sylvain SF" <sylvain@boiteaspam.info> wrote in message
news:47f4a618$0$898$ba4acef3@news.orange.fr...
> Vincent Burel wrote on 03/04/2008 11:12:
> >
> > Déjà je peux vous mettre à contribution pour une question :
> > quand on ouvre une message box (about box ou confirmation de
fermeture)
le
> > code est censé attendre la sortie de l'appel à ce MessageBox (ce sont
des
> > dialogues modales), pourtant nous continuons de recevoir des message
> > WM_TIMER. Comment expliquer ce phénomène simplement ?
>
> MessageBox(..) utile sa propre pompe à message pour recevoir les events
> destinés au dialogue qu'il contrôle, mais le thread principal (et la
> pompe principale) continue de recevoir les msg qui sont destinés à
> toutes les fenêtres qu'il contrôle.
qui dit "seconde pompe à messages" dit seconde boucle de message, donc
second thread, or il ne me semble pas qu'un nouveau thread se crée à
l'ouverture d'une boite de dialogue modale.
non, c'est vous qui avait raison, mais je reformule, l'appel à MessageBox
(ou à toute ouverture de boite de dialogue modale) fait rentrer le code dans
la boucle de message de la boite de dialogue. Ce n'est plus notre
MessageLoop qui traite les événement mais celle de la boite de dialogue. et
c'est cette boucle qui par le dispatch appelle notre callback avec
l'événement WM_TIMER par exemple.
"Vincent Burel" wrote in message news:47f4adc2$0$832$
"Sylvain SF" wrote in message news:47f4a618$0$898$ > Vincent Burel wrote on 03/04/2008 11:12: > > > > Déjà je peux vous mettre à contribution pour une question : > > quand on ouvre une message box (about box ou confirmation de
fermeture)
le > > code est censé attendre la sortie de l'appel à ce MessageBox (ce sont des > > dialogues modales), pourtant nous continuons de recevoir des message > > WM_TIMER. Comment expliquer ce phénomène simplement ? > > MessageBox(..) utile sa propre pompe à message pour recevoir les events > destinés au dialogue qu'il contrôle, mais le thread principal (et la > pompe principale) continue de recevoir les msg qui sont destinés à > toutes les fenêtres qu'il contrôle.
qui dit "seconde pompe à messages" dit seconde boucle de message, donc second thread, or il ne me semble pas qu'un nouveau thread se crée à l'ouverture d'une boite de dialogue modale.
non, c'est vous qui avait raison, mais je reformule, l'appel à MessageBox (ou à toute ouverture de boite de dialogue modale) fait rentrer le code dans la boucle de message de la boite de dialogue. Ce n'est plus notre MessageLoop qui traite les événement mais celle de la boite de dialogue. et c'est cette boucle qui par le dispatch appelle notre callback avec l'événement WM_TIMER par exemple.
d'accord ? VB
Sylvain SF
Vincent Burel wrote on 03/04/2008 12:12:
MessageBox (ou à toute ouverture de boite de dialogue modale) fait rentrer le code dans la boucle de message de la boite de dialogue. Ce n'est plus notre MessageLoop qui traite les événement mais celle de la boite de dialogue. et c'est cette boucle qui par le dispatch appelle notre callback avec l'événement WM_TIMER par exemple.
non, c'est bien le GetMessage() / DispatchMessage() de votre main qui traite l'event WM_TIMER dans la fenêtre principale.
une pompe à message traite tous les messages destinés à la fenêtre dont le handle est transmis à GetMessage() (2nd parametre), plus précisemment à cette fenêtre et à tous ses childs ... sauf pour toute fenêtre qui enregistre un autre event handler via un autre GetMessage(), c'est le cas de MessageBox, il utilise un GetMessage(&e, hWnd_du_dialog, ...) qui de fait provoque le caractère modal et cette gestion séparée.
votre appli a contrario utilise un GetMessage(&e, null, ...) afin de recevoir les msg pour toutes les fenêtres créés dans le scope de votre HINSTANCE (toutes sauf celles qui ...).
on reçoit des WM_TIMER mais également des WM_UPDATE (les fenêtres sont le dialogue modal sont bien redessinées) et tous messages qui ne soit pas un ""user event"" (event souris ou clavier).
oui, même des MOUSEMOVE si j'en crois le spy++
et de nombreuses appli. (browser par exemple pour afficher l'URL d'un tag <a>, mais d'autres avec affichage d'info-bulles) traitent ce mousemove sans prendre en compte le statut actif ou non de la fenêtre.
comment expliquer que notre code attende la sortie de la fonction MessageBox et qu'il puisse en même temps continuer de faire tourner la boucle de message ?
le code (un code comparable à votre tuto) n'est pas multi-thread, mais il est quand même réentrant. l'appel à MessageBox est bloquant pour votre thread principal unique, cela n'empêche pas le système de réappeler votre procédure de traitement de message ('MainWindowManageEvent'). le fait que l'appli soit mono-thread implique seulement qu'un seul message puisse être traité à la fois.
Sylvain.
Vincent Burel wrote on 03/04/2008 12:12:
MessageBox (ou à toute ouverture de boite de dialogue modale) fait
rentrer le code dans la boucle de message de la boite de dialogue. Ce
n'est plus notre MessageLoop qui traite les événement mais celle de
la boite de dialogue. et c'est cette boucle qui par le dispatch
appelle notre callback avec l'événement WM_TIMER par exemple.
non, c'est bien le GetMessage() / DispatchMessage() de votre main
qui traite l'event WM_TIMER dans la fenêtre principale.
une pompe à message traite tous les messages destinés à la fenêtre
dont le handle est transmis à GetMessage() (2nd parametre), plus
précisemment à cette fenêtre et à tous ses childs ... sauf pour
toute fenêtre qui enregistre un autre event handler via un autre
GetMessage(), c'est le cas de MessageBox, il utilise un
GetMessage(&e, hWnd_du_dialog, ...) qui de fait provoque le
caractère modal et cette gestion séparée.
votre appli a contrario utilise un GetMessage(&e, null, ...)
afin de recevoir les msg pour toutes les fenêtres créés dans le
scope de votre HINSTANCE (toutes sauf celles qui ...).
on reçoit des WM_TIMER mais également des WM_UPDATE (les fenêtres
sont le dialogue modal sont bien redessinées) et tous messages qui
ne soit pas un ""user event"" (event souris ou clavier).
oui, même des MOUSEMOVE si j'en crois le spy++
et de nombreuses appli. (browser par exemple pour afficher l'URL
d'un tag <a>, mais d'autres avec affichage d'info-bulles) traitent
ce mousemove sans prendre en compte le statut actif ou non de la
fenêtre.
comment expliquer que notre code attende la sortie de la fonction
MessageBox et qu'il puisse en même temps continuer de faire tourner
la boucle de message ?
le code (un code comparable à votre tuto) n'est pas multi-thread,
mais il est quand même réentrant.
l'appel à MessageBox est bloquant pour votre thread principal
unique, cela n'empêche pas le système de réappeler votre
procédure de traitement de message ('MainWindowManageEvent').
le fait que l'appli soit mono-thread implique seulement qu'un
seul message puisse être traité à la fois.
MessageBox (ou à toute ouverture de boite de dialogue modale) fait rentrer le code dans la boucle de message de la boite de dialogue. Ce n'est plus notre MessageLoop qui traite les événement mais celle de la boite de dialogue. et c'est cette boucle qui par le dispatch appelle notre callback avec l'événement WM_TIMER par exemple.
non, c'est bien le GetMessage() / DispatchMessage() de votre main qui traite l'event WM_TIMER dans la fenêtre principale.
une pompe à message traite tous les messages destinés à la fenêtre dont le handle est transmis à GetMessage() (2nd parametre), plus précisemment à cette fenêtre et à tous ses childs ... sauf pour toute fenêtre qui enregistre un autre event handler via un autre GetMessage(), c'est le cas de MessageBox, il utilise un GetMessage(&e, hWnd_du_dialog, ...) qui de fait provoque le caractère modal et cette gestion séparée.
votre appli a contrario utilise un GetMessage(&e, null, ...) afin de recevoir les msg pour toutes les fenêtres créés dans le scope de votre HINSTANCE (toutes sauf celles qui ...).
on reçoit des WM_TIMER mais également des WM_UPDATE (les fenêtres sont le dialogue modal sont bien redessinées) et tous messages qui ne soit pas un ""user event"" (event souris ou clavier).
oui, même des MOUSEMOVE si j'en crois le spy++
et de nombreuses appli. (browser par exemple pour afficher l'URL d'un tag <a>, mais d'autres avec affichage d'info-bulles) traitent ce mousemove sans prendre en compte le statut actif ou non de la fenêtre.
comment expliquer que notre code attende la sortie de la fonction MessageBox et qu'il puisse en même temps continuer de faire tourner la boucle de message ?
le code (un code comparable à votre tuto) n'est pas multi-thread, mais il est quand même réentrant. l'appel à MessageBox est bloquant pour votre thread principal unique, cela n'empêche pas le système de réappeler votre procédure de traitement de message ('MainWindowManageEvent'). le fait que l'appli soit mono-thread implique seulement qu'un seul message puisse être traité à la fois.
Sylvain.
Sylvain SF
Sylvain SF wrote on 03/04/2008 14:22:
non, c'est bien le GetMessage() / DispatchMessage() de votre main qui traite l'event WM_TIMER dans la fenêtre principale.
raté - moi aussi je dois m'y reprendre à 2 fois!
votre procédure MainWindowManageEvent est réentrante comme indiquée et c'est pour cela que les fenêtres autres que le dialogue modal continuent à recevoir des messages.
votre thread étant bloqué par MessageBox, le GetMessage() du main ne reçoit par contre plus les msg et en effet c'est un autre appel différent de votre DispatchMessage qui invoque votre callback. maintenant qui et où exactement ? je préfère réserver la réponse plutôt que de suppoter gratuitement, il reste vraisemblable que MessageBox distribue directement les events du dialog modal à sa winProc et récupère puis appelle la winProc d'autres fenêtres pour les msg destinés à autre HWND.
Sylvain.
Sylvain SF wrote on 03/04/2008 14:22:
non, c'est bien le GetMessage() / DispatchMessage() de votre main
qui traite l'event WM_TIMER dans la fenêtre principale.
raté - moi aussi je dois m'y reprendre à 2 fois!
votre procédure MainWindowManageEvent est réentrante comme indiquée
et c'est pour cela que les fenêtres autres que le dialogue modal
continuent à recevoir des messages.
votre thread étant bloqué par MessageBox, le GetMessage() du main
ne reçoit par contre plus les msg et en effet c'est un autre appel
différent de votre DispatchMessage qui invoque votre callback.
maintenant qui et où exactement ? je préfère réserver la réponse
plutôt que de suppoter gratuitement, il reste vraisemblable que
MessageBox distribue directement les events du dialog modal à sa
winProc et récupère puis appelle la winProc d'autres fenêtres pour
les msg destinés à autre HWND.
non, c'est bien le GetMessage() / DispatchMessage() de votre main qui traite l'event WM_TIMER dans la fenêtre principale.
raté - moi aussi je dois m'y reprendre à 2 fois!
votre procédure MainWindowManageEvent est réentrante comme indiquée et c'est pour cela que les fenêtres autres que le dialogue modal continuent à recevoir des messages.
votre thread étant bloqué par MessageBox, le GetMessage() du main ne reçoit par contre plus les msg et en effet c'est un autre appel différent de votre DispatchMessage qui invoque votre callback. maintenant qui et où exactement ? je préfère réserver la réponse plutôt que de suppoter gratuitement, il reste vraisemblable que MessageBox distribue directement les events du dialog modal à sa winProc et récupère puis appelle la winProc d'autres fenêtres pour les msg destinés à autre HWND.
Sylvain.
Eric M. H.
Petite histoire, j'ai programmé sous 4 API de gestion de fenetres : GEM/AES, un systeme proprietaire en assembleur que j'avais developpé moi meme, X-Windows, et un peu de java.
Et maintenant je suis fatigué fatigué, j'ai pas envie d'apprendre encore une nouvelle API. Mon reve, c'est de dessiner du pseudo-code, et de laisser supercoder faire le boulot.
Petite histoire, j'ai programmé sous
4 API de gestion de fenetres :
GEM/AES, un systeme proprietaire en assembleur que j'avais developpé moi
meme, X-Windows, et un peu de java.
Et maintenant je suis fatigué fatigué, j'ai pas envie d'apprendre encore
une nouvelle API. Mon reve, c'est de dessiner du pseudo-code, et de
laisser supercoder faire le boulot.
Petite histoire, j'ai programmé sous 4 API de gestion de fenetres : GEM/AES, un systeme proprietaire en assembleur que j'avais developpé moi meme, X-Windows, et un peu de java.
Et maintenant je suis fatigué fatigué, j'ai pas envie d'apprendre encore une nouvelle API. Mon reve, c'est de dessiner du pseudo-code, et de laisser supercoder faire le boulot.
Sylvain SF
Eric M. H. wrote on 10/05/2008 00:21:
Petite histoire, j'ai programmé sous 4 API de gestion de fenetres : GEM/AES, un systeme proprietaire en assembleur que j'avais developpé moi meme, X-Windows, et un peu de java.
Et maintenant je suis fatigué fatigué, j'ai pas envie d'apprendre encore une nouvelle API. Mon reve, c'est de dessiner du pseudo-code, et de laisser supercoder faire le boulot.
publie ton code X-Window (sans 's' il me semble) et je le reprendrais. promis personne ne t'obligera à en apprendre l'API, si par contre un dessinateur de pseudo-ihm-code en naissait, tu as sera informé ;)
Sylvain. (lassé aussi des TV, OWT, TK, Win32, WTL, MFC, AWT, Swing, ...)
Eric M. H. wrote on 10/05/2008 00:21:
Petite histoire, j'ai programmé sous
4 API de gestion de fenetres :
GEM/AES, un systeme proprietaire en assembleur que j'avais developpé moi
meme, X-Windows, et un peu de java.
Et maintenant je suis fatigué fatigué, j'ai pas envie d'apprendre encore
une nouvelle API. Mon reve, c'est de dessiner du pseudo-code, et de
laisser supercoder faire le boulot.
publie ton code X-Window (sans 's' il me semble) et je le reprendrais.
promis personne ne t'obligera à en apprendre l'API, si par contre un
dessinateur de pseudo-ihm-code en naissait, tu as sera informé ;)
Sylvain.
(lassé aussi des TV, OWT, TK, Win32, WTL, MFC, AWT, Swing, ...)
Petite histoire, j'ai programmé sous 4 API de gestion de fenetres : GEM/AES, un systeme proprietaire en assembleur que j'avais developpé moi meme, X-Windows, et un peu de java.
Et maintenant je suis fatigué fatigué, j'ai pas envie d'apprendre encore une nouvelle API. Mon reve, c'est de dessiner du pseudo-code, et de laisser supercoder faire le boulot.
publie ton code X-Window (sans 's' il me semble) et je le reprendrais. promis personne ne t'obligera à en apprendre l'API, si par contre un dessinateur de pseudo-ihm-code en naissait, tu as sera informé ;)
Sylvain. (lassé aussi des TV, OWT, TK, Win32, WTL, MFC, AWT, Swing, ...)
Etienne
Eric M. H. wrote:
Et maintenant je suis fatigué fatigué, j'ai pas envie d'apprendre encore une nouvelle API. Mon reve, c'est de dessiner du pseudo-code, et de laisser supercoder faire le boulot.
Fais du .NET. Les gosses ne font plus que ça, ils cliquent, ils cliquent et hop, une appli, sans rien comprendre. Pour quelques roupies, ils sont contents...
Eric M. H. wrote:
Et maintenant je suis fatigué fatigué, j'ai pas envie d'apprendre encore
une nouvelle API. Mon reve, c'est de dessiner du pseudo-code, et de
laisser supercoder faire le boulot.
Fais du .NET.
Les gosses ne font plus que ça, ils cliquent, ils cliquent et hop, une
appli, sans rien comprendre.
Pour quelques roupies, ils sont contents...
Et maintenant je suis fatigué fatigué, j'ai pas envie d'apprendre encore une nouvelle API. Mon reve, c'est de dessiner du pseudo-code, et de laisser supercoder faire le boulot.
Fais du .NET. Les gosses ne font plus que ça, ils cliquent, ils cliquent et hop, une appli, sans rien comprendre. Pour quelques roupies, ils sont contents...
