Discussion :

[Jiraiya42]

Salut !

J'ai bien bossé la théorie en C pour apprendre mais là partie pratique laisse à désirer. C'est pour ça que j'aimerais faire une petite application alliant l'utile à l'agréable.

J'aimerais faire un gestionnaire de comptes. J'ai réfléchi sur le papier à ce dont j'aimerais arriver. En gros ce serait pouvoir ajouter, supprimer des comptes, ajouter de nouveaux mouvements (date, libellé, montant, retrait, dépôt, total) et gérer les virements de compte à compte.

Je pense que d'autres fonctionnalités pourraient etre imaginées mais je préfère faire "simple" comme application. Mon soucis est la sauvegarde des données. Etant donné que c'est le genre de données que l'on modifie souvent je me demande comment faire. J'avais pensé à exporter la liste des mouvements chaque mois en .pdf ou .txt mais s'il y a un soucis entre la première semaine et la dernière c'est un soucis. Sachant que j'utilise Visual C++ Express Edition 2005, est-ce que je peux lier l'application à une base de données et qu'elle "fasse partie" de l'application ?

De plus, quelqu'un pourrait-il m'aider à démarrer dans la marche à suivre (sans trop parler code pour pas qu'on me dise que je veux qu'on me fasse tout)

Merci d'avance...

[Jiraiya42]

ouais .. en même temps t'as pas beaucoup attendu pour faire ton up.

Je vous déconseille de mener un tel projet en C à moins d'utiliser une bibliothèque graphique.

Le C est plus adapté pour la computation rapide que pour développer des petites applications telle que celle que vous décrivez.

A moins d'utiliser les bibliothèque graphiques C (curses, GTK, etc), je ne vois pas trop l'intérêt de mener un projet tel que le votre en C.

J'ai vu qu'on pouvait avec Visual faire l'appli en C avec une interface graphique

[Emmanuel Delahaye]

J'ai bien bossé la théorie en C pour apprendre mais là partie pratique laisse à désirer. C'est pour ça que j'aimerais faire une petite application alliant l'utile à l'agréable.

J'aimerais faire un gestionnaire de comptes. J'ai réfléchi sur le papier à ce dont j'aimerais arriver. En gros ce serait pouvoir ajouter, supprimer des comptes, ajouter de nouveaux mouvements (date, libellé, montant, retrait, dépôt, total) et gérer les virements de compte à compte.

Ce n'est pas vraiment une 'petite application'. Commence par un truc simple genre carnet d'adresse...

Je pense que d'autres fonctionnalités pourraient etre imaginées mais je préfère faire "simple" comme application. Mon soucis est la sauvegarde des données.

... surtout si tu ne sais pas sauvegarder des données.

Pour sauvegarder des données, on utilise des fichiers. Mais les fichiers sont très rustiques en C, et nécessitent pas mal de traitements.

On peut simplifier avec l'usage d'une vrai base de données comme MySQL (portable). Mais il faut apprendre le langage SQL (standard ?).

[kromartien]

Visual est el compilateur de microsoft, mais je ne connais pas ses spécificités. J'aurai plus tendance à spontanément me tourner vers la programmation Linux. Mais les bibliothèque graphique Python sont peut être aussi sympathique et sûrement moins galères à utiliser que le C.

Sauf si l'objectif est de faire du C.

Je crois me souvenir du discours d'un prof d'info :

1) d'abord faire le programme
2) Après quand il est fini, l'interface graphique.

En gros ce que j'ai compris c'est que l'architecture et les méthodes doivent être rigoureusement distinctes de l'interface graphique, mais je ne sais pas si cette vision est correcte.

[Jiraiya42]

<...>pourrais tu donner des pistes pour l'usage d'une base de donnée MySQL par le biais du C stp ?

[-mod- Nettoyage]

[Emmanuel Delahaye]

mais pourrais tu donner des pistes pour l'usage d'une base de donnée MySQL par le biais du C stp ?

http://www-fr.mysql.com/

[Jiraiya42]

Visual est el compilateur de microsoft, mais je ne connais pas ses spécificités. J'aurai plus tendance à spontanément me tourner vers la programmation Linux. Mais les bibliothèque graphique Python sont peut être aussi sympathique et sûrement moins galères à utiliser que le C.

Sauf si l'objectif est de faire du C.

Je crois me souvenir du discours d'un prof d'info :

1) d'abord faire le programme
2) Après quand il est fini, l'interface graphique.

En gros ce que j'ai compris c'est que l'architecture et les méthodes doivent être rigoureusement distinctes de l'interface graphique, mais je ne sais pas si cette vision est correcte.

Oui mais sur un autre forum, une personne avait fait un gros projet en C et lorsqu'il a voulu l'adapter avec une interface graphique il s'y est cassé les dents dessus donc je sais pas trop s'il faut faire en meme temps. Vous me direz qu'il faut pas tout mélanger mais lorsque je faisais du VB avec interface graphique on m'a appris à faire les deux en meme temps donc j'hésite

[Emmanuel Delahaye]

Allez à plus j'ai pas ma réponse<...>

Quelle était la question sur le langage C ?

[Jiraiya42]

Quelle était la question sur le langage C ?

Est-il possible d'exporter le compte rendu des mouvements de compte par semaine par exemple, dans un fichier PDF pour l'utilisateur ? Autre question, qu'elle est la meilleure solution sachant que je suis débutant en C entre une sauvegarde par un fichier .txt contenant tous les enregistrements (fichier séquentiel) qui remplace la base ?

[Emmanuel Delahaye]

Est-il possible d'exporter le compte rendu des mouvements de compte par semaine par exemple, dans un fichier PDF pour l'utilisateur ?

En C, on sait écrire dans un fichier. Pour 'PDF', il faut connaitre le format...

http://www.wotsit.org/

il y a peut être des bibliothèques spécialisées, je n'en connais pas.

Un format XML est sans doute préférable et plus portable.

OpenOffice sait créer du PDF à partir du XML ... Il a un langage de programmation similaire à VBA...

Autre question, qu'elle est la meilleure solution sachant que je suis débutant en C entre une sauvegarde par un fichier .txt contenant tous les enregistrements (fichier séquentiel) qui remplace la base ?

Un simple fichier texte correctement spécifié peut suffire (CSV) :

• 1 enregistrement par ligne
• Chaque champ est séparé par un ';'

[Jiraiya42]

En C, on sait écrire dans un fichier. Pour 'PDF', il faut connaitre le format...

http://www.wotsit.org/

il y a peut être des bibliothèques spécialisées, je n'en connais pas.

Un format XML est sans doute préférable et plus portable.

OpenOffice sait créer du PDF à partir du XML ... Il a un langage de programmation similaire à VBA...

Un simple fichier texte correctement spécifié peut suffire (CSV) :

• 1 enregistrement par ligne
• Chaque champ est séparé par un ';'

Oki merci bien pour la réponse. En ce qui concerne les formats je vais m'y penché de plus près Et je vais opter pour le fichier texte je pense. Bon je sais ce que je veux obtenir maintenant, reste plus qu'à appliquer

Merci pour les conseils

[souviron34]

Je crois me souvenir du discours d'un prof d'info :

1) d'abord faire le programme
2) Après quand il est fini, l'interface graphique.

En gros ce que j'ai compris c'est que l'architecture et les méthodes doivent être rigoureusement distinctes de l'interface graphique, mais je ne sais pas si cette vision est correcte.

Eh ben j'espère que ton prof ne développe pas de logiciels professionnels....

C'est EXACTEMENT le contraire (enfin presque).

Si tu commences par .. ébaucher ce que tu veux faire sur le papier (si c'est ton programme) ou par interroger les utilisateurs sur ce qu'ils voudraient et comment ils le voudraient (programme à usage externe), tu "dessines" une interface. C'est le rôle premier de l'ergonomie du logiciel.

Attention !! Tu ne définis pas l'outil, mais la suite d'actions et éventuellement d'écrans.

De ça découle directement l'arborescence principale des fonctions / fonctionalités .

Partant de cette arborescence, plus des contraintes que TOI ou ton PROJET a (matériel, maintenance, autres demandes, nécessités techniques..), tu déduis une architecture...

Ensuite, et ensuite seulement, tu rentres dans la partie plus technique.

Et c'est vrai que les méthodes doivent être séparées du GUI.

Et là, en général moi je pars du GUI. Je fabrique les fenêtres, les boutons, les menus, en préparant tout de suite les actions correspondantes (callbacks, ou méthodes GUI).

Et ensuite je remplis chacune des actions possibles, avec l'ordre imposé par l'analyse, en appellant pour chaque action de GUI une action distincte dans le code applicatif.

De cette manière-là, d'abord tu peux MONTRER l'avancement, avoir un retour d'utilisation... Et donc en particulier pour un logiciel professionnel avoir une démo prête, même si certaines fonctionalités ne sont pas encore codées ou débuggées.


Et contrairement à la pensée de ton prof, et de beaucoup de boites, l'ergonomie (et donc le GUI) est primordial .

Un logiciel avec une mauvaise interface n'est pas utilisé, donc, si c'est un produit, pas vendu. Et changer de GUI en cours de route est extrêmement couteux (car, comme indiqué ci-dessus, l'arborescence du GUI recouvre une arborescence des fonctionalités, ce qui implique, lors d'une refonte du GUI, une refonte d'une majeure partie de l'architecture).

Je peux te citer des 10aines d'exemples de projets qui ont échoués ou ont coûté des fortunes à cause de ça..

D'ailleurs, les banques et assurances françaises viennent de découvrir ça depuis peu, avec leurs appels pour des MOA, qui sont en fait chargés de faire ce lien entre utlisateurs et projets en AMONT du développement.

[Emmanuel Delahaye]

Eh ben j'espère que ton prof ne développe pas de logiciels professionnels....

C'est EXACTEMENT le contraire (enfin presque).

Si tu commences par .. ébaucher ce que tu veux faire sur le papier (si c'est ton programme) ou par interroger les utilisateurs sur ce qu'ils voudraient et comment ils le voudraient (programme à usage externe), tu "dessines" une interface. C'est le rôle premier de l'ergonomie du logiciel.

Attention !! Tu ne définis pas l'outil, mais la suite d'actions et éventuellement d'écrans.

De ça découle directement l'arborescence principale des fonctions / fonctionalités .
<...>

Je suis assez d'accord avec l'énoncé de ce principe de réalité...

Ceci-dit, les traitements peuvent être complètement indépendantes d'un GUI si ils sont implémentés intelligemment avec une/des API(s) évènementielle(s) comportant des entrées sous forme de fonctions et des sorties sous forme de callback (càd exactement comme un GUI). Ce que j'appelle un "Composant Logiciel"

http://emmanuel-delahaye.developpez.com/complog.htm

On "fait la colle" entre les deux API avec une surcouche 'application' qui implémente les callbacks et qui, seule, est dépendante des 2 bibliothèques (GUI et traitememts).

[kromartien]

(je ne suis pas une formation d'informaticien)
En fait, la phrase exacte, c'est

"vous êtes programmeur, ne vous préoccupez pas de l'interface graphique, d'abord tapez votre code et l'algorithmique correspondante"

C'était de l'informatique scientifique, donc pas à destination d'un usager quelconque.

Oui c'est certain que les applications à destination d'un utilisateur final doivent être léchées pour être les plus agréables, intuitives et complètes.

[souviron34]

Bien sûr, entièrement d'accord avec toi, Emmanuel. Mais avec l'utilisation massive de RAD cette approche "intellectuelle" et "réfléchie" est à mon avis encore plus battue en brêche qu'avant. Mais nous sommes d'accord sur le fond, c'est à dire qu'une TRES bonne analyse est essentielle, et que autant le choix de l'outil GUI est secondaire, autant le choix / la détermination de la manière dont on va se servir du logiciel (et donc de la suite de fonctionalités et/ou de la présence simultanée d'autres informations sur l'écran) est primordiale, et que ne pas prndre en compte ce facteur dès le début peut amener à des débordements catastrophiques.

C'était de l'informatique scientifique, donc pas à destination d'un usager quelconque.

Parce que les scientifiques ne sont pas des utilisateurs ???

Je suis scientifique, j'ai beaucoup fait de programmation scientifique, et je dirais même au contraire, par rapport à des utilisateurs n'ayant pas de choix d'utilisation (par exemple des employés d'une banque n'ont aucun choix (sauf exprimer leur mécontentement) par rapport à l'utilisation d'un logiciel), autant un scientifique, comme tout utilisateur spécialisé, n'utilisera QUE le logiciel lui permettant de faire le mieux possible son travail (le seul vrai contre-exemple que je connaisse est LaTeX..).

Pour tout le monde, un logiciel est un outil de travail, facilitant le travail sur des tâches fastidieuses ou demandant beaucoup de calculs. Mais pour un scientifique, c'est d'autant plus vrai que pour beaucoup, ces tâches se pratiquaient avant l'ordinateur, et qu'ils ont par conséquent développé des outils/façons de faire optimisé(e)s, qu'il faut reproduire au mieux.. (ce n'est pas un hasard si Photoshop est l'outil le plus utilisé par les graphistes, ce n'et pas un hasard si ArcView ou ArcInfo sont les outils les plus utilisés par les cartographes, etc..).

Pour conclure, bien sûr que l'algorithmique est essentielle. Mais encore une fois, souvent la présence d'informations supplémentaires dans l'écran, en dehors de la fonctionalité principale utilisée, est ce qui fait la force d'attraction des logiciels, en particulier scientifiques, pour leurs utilisateurs...

[kromartien]

(je ne suis pas une formation d'informaticien)

[MON AVIS]Oui, la commmunication est importante, cependant pour un "petit programmeur" comme moi, penser d'abord aux sorties à l'écran d'un petit programme C par exemple ne me facilitera jamais la tâche et parasitera bien plus ma réflexion.

L'exemple qui illustre le mieux ce que je dis sont les utilitaires de compression/décompression. Évolués au niveau algorithmique, faisant appel à une mathématique poussée, le but du programme n'est pas ici d'être interactif avec l'utilisateur mais plutôt de gérer au mieux et de façon optimisée les calculs à mener.

Ici l'intérêt premier de l'utilisateur n'est pas une sortie à l'écran compliquée sur le fonctionnement du processus en cours mais une compression/décompression rapide et fiable, sans erreurs.

Il sera toujours bon après de rajouter des options concernant des fichiers de log et des sorties à l'écran une fois que le programme fonctionnera

De plus (encore une fois je ne suis pas du tout programmeur) l'affichage à l'écran parasite la conception du programme dans le sens ou il introduit une difficulté qui a mon sens devrait être séparée de la conception, car je crois qu' un programme a d'abord un but, une fonction, et que l'interface utilisateur doit s'implémenter en fonction des possibilités du programme, et non le programme qui doit s'implémenter en fonction d'une interface graphique. Sinon tout ce beau travail aura été fait pour rien L'interface graphique, c'est pour aider l'utilisateur.

Donc oui, l'utilisateur (le client) peut avoir une demande (ça doit marcher comme ça, avec ça comme fonctionnalité) mais le programmeur lui va d'abord penser à implémenter ces fonctionnalités et former l'interface graphique en fonction de l'architecture de son programme[/MON AVIS]

[souviron34]

Bon, on ne va pas épiloguer, car cette discussion aurrait plus sa place dans le forum général (et il y en a d'ailleurs).

Simplement quand tu dis :

[MON AVIS]
...
De plus (encore une fois je ne suis pas du tout programmeur) l'affichage à l'écran parasite la conception du programme dans le sens ou il introduit une difficulté qui a mon sens devrait être séparée de la conception, car je crois qu' un programme a d'abord un but, une fonction, et que l'interface utilisateur doit s'implémenter en fonction des possibilités du programme, et non le programme qui doit s'implémenter en fonction d'une interface graphique. Sinon tout ce beau travail aura été fait pour rien L'interface graphique, c'est pour aider l'utilisateur.

Donc oui, l'utilisateur (le client) peut avoir une demande (ça doit marcher comme ça, avec ça comme fonctionnalité) mais le programmeur lui va d'abord penser à implémenter ces fonctionnalités et former l'interface graphique en fonction de l'architecture de son programme[/MON AVIS]

Encore une fois c'est le CONTRAIRE, à part pour des utilitaires comme compression/décompression.

Contrairement à ce que tu dis, un programme a un but, oui, mais c'est qu'on s'en serve ...

Donc l'utilisateur est central.

Oui la fonctionalité est importante. Mais le fait que quand l'utilisateur s'en sert, il s'en serve correctement pour son travail est encore plus important. Et ceci nécessite que cela corresponde à son cheminement dans son travail, avec les à-côtés nécessaires, etc..

Prenons un exemple : tu vas voir ton médecin généraliste. Sans informatique, il dispose de : 1) ses connaissances 2) sur son bureau le dictionnaire des pathologies , celui des médicaments, celui des contre-indications 3) les formulaires de la Sécu.

Il te pose des questions, s'en pose lui-même, établit un diagnostic, prévois une prescrption, vérifie dans ses dictionnaires (au besoin) si il y a la bonne forme/dose qu'il veut, rempli le papier de la Sécu, son rodonnance, et tu t'en vas.

Maintenant, fais un logiciel qui s'occupent de toutes ces fonctionalités, mais ne présente pas au moment de la prescription les dictionnaires. Le médecin arrive sur l'écran de prescription, réfléchis.... puis ressort de l'écran pour fouiller dans les autres fonctionalités en pestant comme un beau diable "mais où ils ont bien pu f.utre ces f.utus dictionnaires ???"... Une fois qu'ils les a trouvés, il lui faut refaire je ne sais combien de clics pour revenir sur l'écran duquel il est parti..

Autre exemple, que j'ai vu de mes yeux : un logiciel pour les responsables clientèle d'un équivalent d"EDF. La boîte informatique responsable du développement fait une architecture basée sur "l'analogie du bureau" : dossiers, poubelle, etc.. Quand une personne veut jeter un papier à la poubelle , il lui faut : sélectionner "poubelle", puis sélectionner le type du formulaire (par numéro), puis sélectionner le client, et quand le bon formulaire apparaît appuyer sur "jeter". Panique résultante chez les utilisateurs. Et évidence de mauvaise structuration : quand tu veux jeter quelque chose à la poubelle, tu ne commences pas par t'asseoir devant la poubelle en disant : "qu'est-ce que je vais bien pouvoir jeter à la poubelle ??"...

Et dans ce cas précis, 30 millions d'euros de développement partis en fumée, 3 ans de retard à la livraison du logiciel, car c'était toute l'architecture qu'il fallait revoir...