Discussion :

[agullentops]

Bonjour,
mes antécédents de programmation:
un peu d'opcode sur micoprosseceur
un peu de basic
bonne expérience en TurboC sous DOS...et oui, je suis plus tout jeune!
pas d'expérience du tout en programmation sous Windows

Voudrais me relancer en programmation pour Windows (aussi CE), que me conseillez vous?
Visual? C++, C#, basic....autre?

NB programmation en amateur, donc prix de l'environement important pour moi!

1er projet: gestion ports série, touchscreen avec interface graphique, curseur pour variation de variables, boutons de sélection

merci d'avance pour vos conseils/idées.

[Mac LAK]

Vu qu'Embarcadero a jugé bon de ne plus fournir de versions personnelles de ses environnements Delphi et C++ Builder, le choix va être assez rapide en fait : Visual Studio Express... IDE gratuit, la seule limitation "lourde" étant de ne pas avoir la possibilité d'utiliser les MFC (ce qui serait plutôt un avantage, si tu veux un avis personnel... ).

Tu pourras avec faire de la programmation native (C ou C++) hors IHM, et côté IHM ou fonctions de plus haut niveau, tu auras accès au C# ou au C++/CLI (C++ sous .NET). Au pire, si tu as besoin d'IHM non basées sur .NET, tu peux installer des frameworks comme Qt.
Le développement sous Windows CE se fait également à partir de Visual Studio, donc ça ne te changera pas franchement du développement sur PC...

Voir cette page pour télécharger VS2008 Express.

[Melem]

Tu pourras avec faire de la programmation native (C ou C++) hors IHM

Pourquoi hors IHM ? VS2008 Express inclut le Windows SDK.

[Mac LAK]

Pourquoi hors IHM ? VS2008 Express inclut le Windows SDK.

Parce faire des IHM à coup d'appels Win32 lorsque l'on est débutant sous Windows serait du masochisme primaire...

[Melem]

Ah, tu aurais quand même pu le préciser. Bin sinon, SharpDevelop aussi est un excellent EDI gratuit pour développer pour la plateforme .NET, en C# ou en VB.NET.

[Mac LAK]

Ah, tu aurais quand même pu le préciser.

Ben, l'OP ayant précisé "pas d'expérience du tout en programmation sous Windows", ça me semblait largement suffisant...


Même en connaissant bien l'OS, c'est franchement plus que lourd de faire des IHM directement avec Win32, et personne ne conseille un truc similaire sous Linux (faire ses IHM directement en attaquant X).

Je ne voyais donc absolument pas l'intérêt de faire croire que VS Express permettait un développement simple d'IHM natives C/C++, à part celui de se dégoûter définitivement de Windows.

[Melem]

Tu pourras avec faire de la programmation native (C ou C++) hors IHM, et côté IHM ou fonctions de plus haut niveau, tu auras accès au C# ou au C++/CLI (C++ sous .NET). Au pire, si tu as besoin d'IHM non basées sur .NET, tu peux installer des frameworks comme Qt.

Ça laisse tout simplement croire qu'il n'est pas POSSIBLE de faire des IHM natives en C ou en C++ avec VS2008 à part après avoir installer un truc comme Qt, pas qu'il est possible de le faire mais que c'est pas vraiment recommandé à des débutants.

Même en connaissant bien l'OS, c'est franchement plus que lourd de faire des IHM directement avec Win32, et personne ne conseille un truc similaire sous Linux (faire ses IHM directement en attaquant X).

Je ne voyais donc absolument pas l'intérêt de faire croire que VS Express permettait un développement simple d'IHM natives C/C++, à part celui de se dégoûter définitivement de Windows.

GTK+ est au moins aussi lourd que l'API Win32 mais pourtant personne ne s'en est plaint, plus que conseillé c'est vivement recommandé à ceux qui souhaitent faire des IHMs en C (surtout sous Linux) et ça a rarement suscité le dégoût de Linux. Son seul avantage sur Win32 c'est sa portabilité.

[Mac LAK]

GTK+ est au moins aussi lourd que l'API Win32

Attaquer X et GTK+, c'est pas du même niveau...

[Melem]

Je n'ai jamais parlé de niveau, juste de complexité. Tu dis que faire des IHMs en Win32 c'est rarement une bonne idée, qu'on soit débutant ou pas, sous prétexte que c'est dur à coder et que heureusement, il y a d'autres langages et/ou EDIs plus simples à utiliser. C'est pourtant le même cas avec GTK+, qui est de même complexité que l'API Win32 : sur toutes les plateformes ou elle a été portée, il existe d'autres langages et/ou EDIs, également multiplateformes, permettant de créer des IHMs plus simplement, pourtant elle est toujours très utilisée. Ce que je veux dire, c'est que développer des IHMs en Win32 n'est pas systématiquement une hérésie, tout comme développer des IHMs avec GTK+ ne l'est pas. Seulement, grâce à sa portabilité notamment, beaucoup de gens se tournent vers GTK+ plutôt que Win32 même sous Windows. Sinon, pour de petites ou moyennes applications pour Windows (genre application avec une fenêtre principale et/ou quelques boîtes de dialogue), j'utilise systématiquement Win32 et je n'ai jamais rencontré le moindre problème ni le moindre inconvénient, au contraire il n'y a que des avantages (exe très compacts, autonômes, "portables", performants, etc.). Pour les autres types d'applications, ça dépend. Mais là ce sont juste des notes personnelles, un partage d'expérience, pas une argumentation.

[Mac LAK]

Ce que je veux dire, c'est que développer des IHMs en Win32 n'est pas systématiquement une hérésie

Je n'ai pas dit le contraire... Juste que débuter les IHM sous Windows de cette manière, c'est du masochisme.

TU n'as pas de problèmes avec le fait de taper directement dans Win32, et moi non plus. Remets-toi dans la peau d'un débutant ne connaissant même pas les principes généraux de Win32, et ne dis pas ça avec ton expérience... Sinon, moi, je vais dire que se passer de 100% des librairies "classiques" (STL incluse) pour taper dans le bas niveau et programmer en MT façon "roots", c'est facile et trivial. On sait tous les deux que si l'on fait commencer le dév MT à un débutant tel que MOI je le pratique au quotidien, il va se tirer une balle...

[10_GOTO_10]

Parce faire des IHM à coup d'appels Win32 lorsque l'on est débutant sous Windows serait du masochisme primaire...

Tiens ? Pourtant, j'ai fait des IHM en Win32 alors que j'étais débutant, avec le Petzold dans une main et à une époque où internet n'existait pas ou très peu, et pourtant mon masochisme n'est pas si primaire ?

Non, plus sérieusement, je pense que commencer par la base n'est pas si idiot que ça. Même si le débutant n'utilisera ensuite jamais directement ces connaissances, comprendre comment ça fonctionne au plus bas niveau est toujours bénéfique. C'est comme apprendre l'assembleur. On s'en sert ensuite qu'une fois par an, mais ça permet de comprendre des bugs incompréhensibles.

Ce n'est que mon avis, merci de ne pas troller.

[Mac LAK]

Non, plus sérieusement, je pense que commencer par la base n'est pas si idiot que ça.

Si tu m'as déjà lu, je pense que tu sais déjà que le bas niveau, c'est mon dada... Toutefois, je ne suis pas partisan de débuter à ce niveau, mais plutôt de débuter d'une façon médiane (ni trop haut, ni trop bas). J'ai fait comme toi, parce qu'il n'y avait pas le choix à l'époque, mais ce n'est pas pour ça que je conseille d'en faire autant.

MON expérience des débutants en Win32 me fait dire que la plupart "paniquent" devant les boucles de messages, mettent un temps infernal à comprendre qu'une "window" n'est pas ce qu'ils croient, et ont du mal à assimiler qu'un comportement non programmé ne se produit pas... Choses qui sont masquées par des outils tirant vers le RAD, ce qui leur permet de développer des IHM sans se préoccuper de la tripaille tout en se familiarisant avec le reste de l'API Win32. Une fois les concepts de cette API bien ancrés, passer au mode "roots" ne pose alors plus de problèmes... Et cela produit de meilleurs dévs au final.

Là aussi, ce n'est que mon avis, mais les meilleurs dévs bas niveau que j'ai pu côtoyer ont tous commencé à un niveau médian, et non pas à bas niveau. Et ce n'est pas vraiment paradoxal, en fait, cf. cette discussion qui reprends tout ça de façon exhaustive et avec beaucoup plus de points de vue qu'ici, où l'on reste quand même dans le cas "Win32 brut de fonderie ou pas pour les IHM"...

[Médinoc]

Je trouve que commencer par Win32 n'est pas trop un problème si c'est correctement expliqué, mais il y a une barrière à l'accès: L'élève doit déjà avoir appris et compris ce qu'est une fonction callback. qsort() et bsearch() peuvent aider dans ce sens.

[lepinekong]

Je n'ai jamais parlé de niveau, juste de complexité. Tu dis que faire des IHMs en Win32 c'est rarement une bonne idée, qu'on soit débutant ou pas, sous prétexte que c'est dur à coder et que heureusement, il y a d'autres langages et/ou EDIs plus simples à utiliser. C'est pourtant le même cas avec GTK+, qui est de même complexité que l'API Win32 : sur toutes les plateformes ou elle a été portée, il existe d'autres langages et/ou EDIs, également multiplateformes, permettant de créer des IHMs plus simplement, pourtant elle est toujours très utilisée. Ce que je veux dire, c'est que développer des IHMs en Win32 n'est pas systématiquement une hérésie, tout comme développer des IHMs avec GTK+ ne l'est pas. Seulement, grâce à sa portabilité notamment, beaucoup de gens se tournent vers GTK+ plutôt que Win32 même sous Windows. Sinon, pour de petites ou moyennes applications pour Windows (genre application avec une fenêtre principale et/ou quelques boîtes de dialogue), j'utilise systématiquement Win32 et je n'ai jamais rencontré le moindre problème ni le moindre inconvénient, au contraire il n'y a que des avantages (exe très compacts, autonômes, "portables", performants, etc.). Pour les autres types d'applications, ça dépend. Mais là ce sont juste des notes personnelles, un partage d'expérience, pas une argumentation.

Très bien les tuts Win32, ça me donne envie de m'y remettre tiens

Je pense que ça dépend un peu de la personne et de ses objectifs. Quelqu'un qui est très technique sans objectif précis aura tendance à vouloir commencer par le bas niveau pour vraiment comprendre, d'autres auront l'impression de perdre leur temps.

Moi je suis entre les deux, j'aime bien comprendre alors de temps en temps je refais un tour à la cave mais comme je sais que je n'ai pas vraiment besoin d'aller aussi bas, je remonte au premier étage