[R] Outil Gestion Boutique

[Koumla]

Bonjour à tous,

Voila je me lance avec mon premier script, rien de bien exceptionnel.

Il s'agit de la gestion de fournisseurs, articles, clients, commande, etc. Pour moi perso dans un futur proche.

Pour le moment j'ai juste fait la partie création Fournisseur au complet.

J'ai fait au maximum pour faire propre, mais temporaire.au3 ca devient de la boucherie vu que je suis en cours de réflexion furieuse.

J'ai commence a faire un diagramme pour suivre plus facilement le cheminement du script (plus facile pour débugger) certaine parti son fausse car en cours de modif.

La partie Article est en cours, mais... la ca coince un peu (une bricole de rien) et je pige pas pourquoi!!! (arrggghhhh)

Voilà le problème, ici a la première exécution du script, l'état des combos.

Dans le code sa donne en simplifier:

Code : Tout sélectionner

func ar_creation_liste_societe()

ar_creation_liste_article()

endfunc

Je sélectionne par exemple demo2 ou demo3, voilà le resultat.
Pourquoi par defaut c'est vide au lieu du premier de la liste comme la premiere fois???
c'est les mêmes fonctions qui sont utilisées, que je sache y a rien qui change.

Code : Tout sélectionner

Func Combo_ar_liste_societeChange()

ar_creation_liste_article()

endfunc

la ou je comprend encore moins c'est pourquoi si je sélectionne de nouveau demo1, ca affiche de nouveau correctement comme la première fois (revoir l'image 1)



Pour voir l'image en grand

http://demo.koumla.com/autoit/Diagramme1.png

Après moulte recherche sur le forum, je profite pour poser quelque question.

1) - la déclaration des variables c'est galère, y a pas moyen de dire global TOUT et hop fini. Je sais (recherche sur le forum), mais pas facile certaines fois, résultat je bricole.
2) - Comment a chaque écriture dans la zone d'édition a droite qui me sert a debugger, etre positionner a la fin de la zone édit pour voir le nouveau texte afficher et nom pas le debut quand il y a la barre de défilement vers le bas???

Koumla

[Yogui]

Impressionnant c'est le premier mot qui me vient à l'esprit

la GUI est bien pensée bravo

concernant les déclarations de variable vu l'usine que vous allez faire oui c'est important de définir une portée

tuto ici.

pour les autres problèmes étant au boulot je ne vais pas avoir le temps de regarder de suite...

Par contre une remarque concernant votre moyen de sauvegarde (les .ini) je vous invite à lire ce topic:

http://www.autoitscript.fr/forum/viewto ... ichier+ini

[Koumla]

Merci, je jette un oeil dessus

C’est pas une usine a gaz (heu, si en fait) mais rien de compliquer, la seul chose c’est bien penser les fonctions et le déroulement du script, et comme je débute…

Apres le boulot si tu as le temps…

Koumla

[timmalos]

Vu la finalité du programme, je vous déconseille d'utiliser ma fonction, mais elle peut peut-être vous etre utile pour verifications:

http://www.autoitscript.fr/forum/viewto ... =21&t=3663

[Koumla]

Bon pour la déclaration des variables, après lecture, je reste en global pour tout.
Dommage qu’il n’y a pas moyen de dire GLOBAL TOUT et fini.

Pour les fichiers INI :
J’ai eu l’idée de voir du cote MySQL ou MySQLi et la il faut 20 lignes de code pour faire la même chose simple.

Pour le XML c’est idem.

Je viens de faire un test avec le fichier fg.ini avec 5000 sections dedans et ça ne charge que les 3763 premiers

Le fg.ini sera ridicule en taille.

Pour article.ini la je sais pas trop encore mais je pense pas que la taille sera énorme, dans le pire des cas il sera modifier pour servir de référence a 1 article = 1 ini

http://www.autoitscript.fr/forum/viewto ... ichier+ini a la fin de celui-ci :

A première vue, cette fameuse limitation des 32K ne concerne pas les fonctions IniRead, IniWrite, IniDelete, IniRenameSection et IniWriteSection mais seulement les fonctions IniReadSection et IniReadSectionNames.

Donc il semble que tant que vous n'utilisez pas ces fonctions, ou que vos section ne dépasse pas les 32k, il n'y à rien à craindre.

Merci Yogui

Koumla

[Iste]

y a pas moyen de dire global TOUT et hop fini

Han !!! Mais ca va pas bien ??

[Yogui]

Bon pour la déclaration des variables, après lecture, je reste en global pour tout.
Dommage qu’il n’y a pas moyen de dire GLOBAL TOUT et fini.

+1 pour le ça va pas non ..

Pour les fichiers INI :
J’ai eu l’idée de voir du cote MySQL ou MySQLi et la il faut 20 lignes de code pour faire la même chose simple.

Oui mais non si un jour quelqu'un (Peter Chen) à inventer des bases de données relationnel et qu'après tout le monde a utilisé c'est qu'a un moment c'est vraiment mieu ...

Outre la non limitation, la fléxibilité en cas de changement, la rapidité de traitement la simplicité de sortir des stat ... j'en passe le truc c'est le gain de place une information d'un table n'est 'normalement' pas dans une autre (sauf clef étrangère ...)

A première vue, cette fameuse limitation des 32K ne concerne pas les fonctions IniRead, IniWrite, IniDelete, IniRenameSection et IniWriteSection mais seulement les fonctions IniReadSection et IniReadSectionNames.

Donc il semble que tant que vous n'utilisez pas ces fonctions, ou que vos section ne dépasse pas les 32k, il n'y à rien à craindre.

Merci Yogui

De rien

[Tlem]

Je dirais moi aussi, +1 pour le ça va pas non ..

A première vue, cette fameuse limitation des 32K ne concerne pas les fonctions IniRead, IniWrite, IniDelete, IniRenameSection et IniWriteSection mais seulement les fonctions IniReadSection et IniReadSectionNames.

Donc il semble que tant que vous n'utilisez pas ces fonctions, ou que vos section ne dépasse pas les 32k, il n'y à rien à craindre.

J'ai effectivement dit ça, mais un fichier .INI reste un fichier de configuration et non de stockage d'une grande quantité de donnée.

Comme l'a signalé Yogui, si il existe les bases de données, c'est pas pour faire joli.
Certes votre code sera plus long et sans doute plus complexe dans les fonctions, mais une fois écrites, l'appel à ces fonctions sera simple et rapide.
Pensez aussi à l'avenir. Si vous venez à avoir de plus en plus de données à gérer, comment allez-vous faire ? Un fichier par table ?
Ça va vite devenir lent et lourd ...

Bref, comme vous pouvez le constater, nous sommes plusieurs à vous conseiller la base de donnée. Prenez votre temps pour réfléchir et ne soyez pas trop pressé d'avoir quelque chose de fonctionnel, car si vous passez à coté de quelque chose, vous le regretterez plus tard, lorsque vous perdrez du temps à tout refaire parce que ça ne fonctionne plus correctement.

[Koumla]

Merci beaucoup pour les explications et information.
J’arrête la pour le moment, afin d’étudier le SQL.
Je vais tout reprendre de zéro en garder la base du script.

Le plus simple d’utilisation le SQL ou SQLi ???

Pour l’histoire des variables, j’ai bien compris.
Je voulais simplement dire que c’est dommage que par défaut AutoIt ne déclare pas automatiquement les variables en GLOBAL a l’exécution, et que ci on déclare une variable dans le script quelque soit le type qu’il le prenne en compte, c’est tout.

A part ça, une idée sur ma question 2 et le problème des combos ???

Encore Merci.

koumla

[Tlem]

Pour le combo, c'est à vous de déterminer la valeur de début.
Dans votre code, vous faites ceci :

Code : Tout sélectionner

Global $Combo_fg_liste_societe = GUICtrlCreateCombo("", 209, 155, 180, 25)

et donc vous dites que la valeur de démarrage est ... vide.

Initialisez les valeurs du combo avant et attribuez les lors de la création de la GUI ou alors utilisez GUICtrlSetData pour initialiser toutes les valeurs au moment de votre choix (voir l'exemple de la commande GUICtrlCreateCombo).

[jchd]

Il serait urgentissime de totalement dissocier le fonctionnel de tous les autres aspects, sinon je parie que l'ensemble tombera à l'eau et sera 100% non-maintenable.
On n'architecture pas une gestion commerciale avec un vague diagramme portant sur les aspects GUI. L'application elle-même ne devrait pas changer si tout était réalisé en mode console. Désolé mais c'est un non-sens. Le GUI n'est qu'un habillage, certes commode, mais dont on peut totalement se passer. C'est vraiment la dernière chose à réaliser.

Se lancer dans une telle réalisation pour un premier script est, disons, _très_ téméraire.

Réalise déjà un solide schéma SQL complet et correctement normalisé, puis fais-le tourner "à la main" avec un gestionnaire de BDD SQLite (genre SQLite Expert). Cela donnera déjà une idée plus précise des pré-requis pour réaliser ce que tu souhaites. Euh, pour SQL, un schéma n'est _pas_ un dessin !

Ne pas non plus oublier qu'une activité peut demander rapidement à être multi-utilisateurs, multi-stocks, etc.

Ceci dit, j'ai bien peur que cela ne vaille pas le coup de développer soi-même l'intégralité d'une gestion commerciale. Pour être franc, je pense même que, en dehors d'une équipe de développeurs professionnels disposant d'un financement suffisant, c'est à peu près comme sauter du troisième étage de la "Dame de Fer" sans parapente...

Ne pas omettre les contraintes légales non plus, sinon ça peut un jour mordre à un endroit sensible.

[Koumla]

Bonjour,

Désole de ne pas répondre plus tôt

Pour l’histoire du diagramme, c’est pour le debugage et suivre le cheminement du script, éventuellement cela peut permettre a une personne qui débute en AutoIt, pour comprendre et utiliser un bout de script.

La création de ce programme n’a rien de compliquer et de bien téméraire, certes il faut bien réfléchir avant sur les besoins et les actions à réaliser, comme la BDD par exemple. J’ai opté pour une BDD SQLite après divers test.

Je fais ça uniquement pour le plaisir de faire un programme et apprendre AutoIt par la même occasion, et qui me servira par la suite a moi seul, il est évident que je vais utiliser un programme du commerce dédie a cela et le mien sera pour le plaisir de voir que cela fonctionne.

Pour mes deux autres questions, le problème est réglé.

Koumla

[jchd]

Bon, je suis rassuré !

Ne prends pas mal mes remarques (que je n'ai certes pas beaucoup "enrobé"), mon but n'était certainement pas de te vexer ni de te décourager.

Disons que j'ai eu l'occasion de rencontrer un nombre certains d'horreurs qui ont tôt ou tard coûté la peau des ******** à leur créateur(s).

Le plus délirant que j'aie jamais vu était une feuille de calcul Excel qui était devenue tout à la fois si grosse (> 480Mo cellules), si complexe et si vitale pour l'entreprise (pourtant une multinationale !) qu'elle ne tournait plus sur un PC (à l'époque) depuis belle lurette. La "solution" retenue avait été de faire développer une émulation Windows (partielle) et Excel sur un ... mainframe pour s'affranchir des limitations mémoire (où cette "chose" tournait quand même une fois par semaine en plus de 30h de calcul, haha !). A l'époque la plaisanterie avait coûté un pognon absolument astronomique (vraiment énormément de zéros significatifs), sans aucune garantie de cohérence des résultats. Je ne citerai aucun nom, l'action se casserait la gueule immédiatement.

[Koumla]

Y a pas de mal, ont est la pour apprendre et avoir des conseils.

Dans le genre truc délirant c’est pas mal du tout, moi aussi dans un autre style, j’ai vu et je vois encore des trucs pas possibles à tous les niveaux.

Koumla