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

[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]

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

[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.

[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 ?).

[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/

[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 ?