Je suis en stage, et je d=E9veloppe un logiciel... houla... dit comme
=E7a, =E7a fait professionnel... On la refait...
Je suis en stage, et je bricole un programme pour faire la saisie de
fiches techniques.
J'ai donc tent=E9 de m'attaquer =E0 la b=EAte en la prenant avec du C++ et
la biblioth=E8que Win32.
Mais je me suis rendu compte d'une chose : =E7a risque d'=EAtre rude. En
effet, vu d'ici, il faudrait que je fasse une fen=EAtre pour chaque type
de fiche (une trentaine), que je remplisse chaque fen=EAtre avec des
boutons =E0 tire-larigot (combo boxes, check boxes, etc), que je stocke
les handle de ces boutons dans des variables globales pour r=E9cup=E9rer
les saisies (infamie), et que je fournisse un effort surhumain pour ne
pas me pendre.
A moins que vous n'ayez des conseils ou des astuces =E0 me donner...
Donc, pour r=E9sumer : comment c'est qu'on fait pour faire un formulaire
avec Win32 sans trop qu'on se tracasse la t=EAte ???
D'avance, je vous remercie.
Dans l'attente de votre r=E9ponse, veuillez croire, Monsieur, en mes
sentiments les plus sinc=E8res.
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
Alain
"The ReAl damn shit" a écrit dans le message de news:
Bonjour tout le monde, ... Donc, pour résumer : comment c'est qu'on fait pour faire un formulaire avec Win32 sans trop qu'on se tracasse la tête ???
Tu peux les faire avec le "Dialog Editor" : tu places tous tes controles à la main et par copier-coller, c'est vite fait..
"The ReAl damn shit" <t.h.e.r.e.a.l.d.4.m.n.s.h.1.t@gmail.com> a écrit dans
le message de news:
d372dcd3-82a1-4d65-9a58-5bb111cd7ae4@h31g2000yqd.googlegroups.com...
Bonjour tout le monde,
...
Donc, pour résumer : comment c'est qu'on fait pour faire un formulaire
avec Win32 sans trop qu'on se tracasse la tête ???
Tu peux les faire avec le "Dialog Editor" : tu places tous tes controles à
la main et par copier-coller, c'est vite fait..
"The ReAl damn shit" a écrit dans le message de news:
Bonjour tout le monde, ... Donc, pour résumer : comment c'est qu'on fait pour faire un formulaire avec Win32 sans trop qu'on se tracasse la tête ???
Tu peux les faire avec le "Dialog Editor" : tu places tous tes controles à la main et par copier-coller, c'est vite fait..
domi
The ReAl damn shit wrote:
Mais je me suis rendu compte d'une chose : ça risque d'être rude. En effet, vu d'ici, il faudrait que je fasse une fenêtre pour chaque type de fiche (une trentaine), que je remplisse chaque fenêtre avec des boutons à tire-larigot (combo boxes, check boxes, etc), que je stocke les handle de ces boutons dans des variables globales pour récupérer les saisies (infamie), et que je fournisse un effort surhumain pour ne pas me pendre.
Il n'y a pas besoin de "stocker les handles dans des variables globales" Les handles se suffisent à eux-mêmes (GetDlgItemText ou WM_GETTEXT pour récupérer leur valeur) Sinon, tu pourrais faire les formulaires en DOC, HTML, XML, ... et les gérer par les interfaces COM, mais pas sûr que ça soit plus simple à court terme..
The ReAl damn shit wrote:
Mais je me suis rendu compte d'une chose : ça risque d'être rude. En
effet, vu d'ici, il faudrait que je fasse une fenêtre pour chaque type
de fiche (une trentaine), que je remplisse chaque fenêtre avec des
boutons à tire-larigot (combo boxes, check boxes, etc), que je stocke
les handle de ces boutons dans des variables globales pour récupérer
les saisies (infamie), et que je fournisse un effort surhumain pour ne
pas me pendre.
Il n'y a pas besoin de "stocker les handles dans des variables globales"
Les handles se suffisent à eux-mêmes (GetDlgItemText ou WM_GETTEXT pour
récupérer leur valeur)
Sinon, tu pourrais faire les formulaires en DOC, HTML, XML, ... et les
gérer par les interfaces COM, mais pas sûr que ça soit plus simple à
court terme..
Mais je me suis rendu compte d'une chose : ça risque d'être rude. En effet, vu d'ici, il faudrait que je fasse une fenêtre pour chaque type de fiche (une trentaine), que je remplisse chaque fenêtre avec des boutons à tire-larigot (combo boxes, check boxes, etc), que je stocke les handle de ces boutons dans des variables globales pour récupérer les saisies (infamie), et que je fournisse un effort surhumain pour ne pas me pendre.
Il n'y a pas besoin de "stocker les handles dans des variables globales" Les handles se suffisent à eux-mêmes (GetDlgItemText ou WM_GETTEXT pour récupérer leur valeur) Sinon, tu pourrais faire les formulaires en DOC, HTML, XML, ... et les gérer par les interfaces COM, mais pas sûr que ça soit plus simple à court terme..
ByB
The ReAl damn shit a présenté l'énoncé suivant :
Bonjour tout le monde,
Je suis en stage, et je développe un logiciel... houla... dit comme ça, ça fait professionnel... On la refait... Je suis en stage, et je bricole un programme pour faire la saisie de fiches techniques.
J'ai donc tenté de m'attaquer à la bête en la prenant avec du C++ et la bibliothèque Win32.
Mais je me suis rendu compte d'une chose : ça risque d'être rude. En effet, vu d'ici, il faudrait que je fasse une fenêtre pour chaque type de fiche (une trentaine), que je remplisse chaque fenêtre avec des boutons à tire-larigot (combo boxes, check boxes, etc), que je stocke les handle de ces boutons dans des variables globales pour récupérer les saisies (infamie), et que je fournisse un effort surhumain pour ne pas me pendre.
A moins que vous n'ayez des conseils ou des astuces à me donner...
Donc, pour résumer : comment c'est qu'on fait pour faire un formulaire avec Win32 sans trop qu'on se tracasse la tête ???
MFC ?
The ReAl damn shit a présenté l'énoncé suivant :
Bonjour tout le monde,
Je suis en stage, et je développe un logiciel... houla... dit comme
ça, ça fait professionnel... On la refait...
Je suis en stage, et je bricole un programme pour faire la saisie de
fiches techniques.
J'ai donc tenté de m'attaquer à la bête en la prenant avec du C++ et
la bibliothèque Win32.
Mais je me suis rendu compte d'une chose : ça risque d'être rude. En
effet, vu d'ici, il faudrait que je fasse une fenêtre pour chaque type
de fiche (une trentaine), que je remplisse chaque fenêtre avec des
boutons à tire-larigot (combo boxes, check boxes, etc), que je stocke
les handle de ces boutons dans des variables globales pour récupérer
les saisies (infamie), et que je fournisse un effort surhumain pour ne
pas me pendre.
A moins que vous n'ayez des conseils ou des astuces à me donner...
Donc, pour résumer : comment c'est qu'on fait pour faire un formulaire
avec Win32 sans trop qu'on se tracasse la tête ???
Je suis en stage, et je développe un logiciel... houla... dit comme ça, ça fait professionnel... On la refait... Je suis en stage, et je bricole un programme pour faire la saisie de fiches techniques.
J'ai donc tenté de m'attaquer à la bête en la prenant avec du C++ et la bibliothèque Win32.
Mais je me suis rendu compte d'une chose : ça risque d'être rude. En effet, vu d'ici, il faudrait que je fasse une fenêtre pour chaque type de fiche (une trentaine), que je remplisse chaque fenêtre avec des boutons à tire-larigot (combo boxes, check boxes, etc), que je stocke les handle de ces boutons dans des variables globales pour récupérer les saisies (infamie), et que je fournisse un effort surhumain pour ne pas me pendre.
A moins que vous n'ayez des conseils ou des astuces à me donner...
Donc, pour résumer : comment c'est qu'on fait pour faire un formulaire avec Win32 sans trop qu'on se tracasse la tête ???
MFC ?
Vincent Burel
"The ReAl damn shit" wrote in message news: J'ai donc tenté de m'attaquer à la bête en la prenant avec du C++ et la bibliothèque Win32.
Mais je me suis rendu compte d'une chose : ça risque d'être rude. En effet, vu d'ici, il faudrait que je fasse une fenêtre pour chaque type de fiche (une trentaine), que je remplisse chaque fenêtre avec des boutons à tire-larigot (combo boxes, check boxes, etc), que je stocke les handle de ces boutons dans des variables globales pour récupérer les saisies (infamie), et que je fournisse un effort surhumain pour ne pas me pendre.
A moins que vous n'ayez des conseils ou des astuces à me donner...
Si vous savez faire une boite de dialogue avec les controles windows en C/C++, je dirais que c'est la meilleure façon de faire, parce que vous allez tout maitriser (la position des controles, la taille des fontes, les couleurs, les intéractions éventuelles entre les controle) et ainsi vous allez pouvoir maintenir trés facilement votre interface dans le temps et vous pourrez répondre aisément à toute demande de modification.
Alors, effectivement si vous avez beaucoup de boites de dialogue à faire, ca va représenter un travail important. Mais l'expérience montre que quelque soit la méthode que vous allez utiliser, cela représente toujours un travail important de faire des boites de dialogue. D'une part il faut savoir que l'interface représente souvent 90% du temps de développement d'un logiciel, et d'autre part que ce temps est incompressible. Si vous mettez un semaine par formulaire (c'est le temps moyen que je mets à faire une boite de dialogue ou un écran) , si vous avez 30 boites à faire, il faudra 30 semaines. c'est le minimum.
Vous pouvez tout essayer, prendre des outils de soi-disant développement rapide, des librairies ad-hoc, vous pouvez même prendre 5 semaines à vous faire un interpréteur/browser de script spécifique au type de formulaire que vous voulez faire. Tout le temps que vous penserez gagner sur telle ou telle étape de la fabrication de vos écran, vous le perdrez ailleurs, sur d'autres aspects auxquels vous n'avez pas penser.
VB
"The ReAl damn shit" <t.h.e.r.e.a.l.d.4.m.n.s.h.1.t@gmail.com> wrote in
message
news:d372dcd3-82a1-4d65-9a58-5bb111cd7ae4@h31g2000yqd.googlegroups.com...
J'ai donc tenté de m'attaquer à la bête en la prenant avec du C++ et
la bibliothèque Win32.
Mais je me suis rendu compte d'une chose : ça risque d'être rude. En
effet, vu d'ici, il faudrait que je fasse une fenêtre pour chaque type
de fiche (une trentaine), que je remplisse chaque fenêtre avec des
boutons à tire-larigot (combo boxes, check boxes, etc), que je stocke
les handle de ces boutons dans des variables globales pour récupérer
les saisies (infamie), et que je fournisse un effort surhumain pour ne
pas me pendre.
A moins que vous n'ayez des conseils ou des astuces à me donner...
Si vous savez faire une boite de dialogue avec les controles windows en
C/C++, je dirais que c'est la meilleure façon de faire, parce que vous allez
tout maitriser (la position des controles, la taille des fontes, les
couleurs, les intéractions éventuelles entre les controle) et ainsi vous
allez pouvoir maintenir trés facilement votre interface dans le temps et
vous pourrez répondre aisément à toute demande de modification.
Alors, effectivement si vous avez beaucoup de boites de dialogue à faire, ca
va représenter un travail important. Mais l'expérience montre que quelque
soit la méthode que vous allez utiliser, cela représente toujours un travail
important de faire des boites de dialogue. D'une part il faut savoir que
l'interface représente souvent 90% du temps de développement d'un logiciel,
et d'autre part que ce temps est incompressible. Si vous mettez un semaine
par formulaire (c'est le temps moyen que je mets à faire une boite de
dialogue ou un écran) , si vous avez 30 boites à faire, il faudra 30
semaines. c'est le minimum.
Vous pouvez tout essayer, prendre des outils de soi-disant développement
rapide, des librairies ad-hoc, vous pouvez même prendre 5 semaines à vous
faire un interpréteur/browser de script spécifique au type de formulaire que
vous voulez faire. Tout le temps que vous penserez gagner sur telle ou telle
étape de la fabrication de vos écran, vous le perdrez ailleurs, sur d'autres
aspects auxquels vous n'avez pas penser.
"The ReAl damn shit" wrote in message news: J'ai donc tenté de m'attaquer à la bête en la prenant avec du C++ et la bibliothèque Win32.
Mais je me suis rendu compte d'une chose : ça risque d'être rude. En effet, vu d'ici, il faudrait que je fasse une fenêtre pour chaque type de fiche (une trentaine), que je remplisse chaque fenêtre avec des boutons à tire-larigot (combo boxes, check boxes, etc), que je stocke les handle de ces boutons dans des variables globales pour récupérer les saisies (infamie), et que je fournisse un effort surhumain pour ne pas me pendre.
A moins que vous n'ayez des conseils ou des astuces à me donner...
Si vous savez faire une boite de dialogue avec les controles windows en C/C++, je dirais que c'est la meilleure façon de faire, parce que vous allez tout maitriser (la position des controles, la taille des fontes, les couleurs, les intéractions éventuelles entre les controle) et ainsi vous allez pouvoir maintenir trés facilement votre interface dans le temps et vous pourrez répondre aisément à toute demande de modification.
Alors, effectivement si vous avez beaucoup de boites de dialogue à faire, ca va représenter un travail important. Mais l'expérience montre que quelque soit la méthode que vous allez utiliser, cela représente toujours un travail important de faire des boites de dialogue. D'une part il faut savoir que l'interface représente souvent 90% du temps de développement d'un logiciel, et d'autre part que ce temps est incompressible. Si vous mettez un semaine par formulaire (c'est le temps moyen que je mets à faire une boite de dialogue ou un écran) , si vous avez 30 boites à faire, il faudra 30 semaines. c'est le minimum.
Vous pouvez tout essayer, prendre des outils de soi-disant développement rapide, des librairies ad-hoc, vous pouvez même prendre 5 semaines à vous faire un interpréteur/browser de script spécifique au type de formulaire que vous voulez faire. Tout le temps que vous penserez gagner sur telle ou telle étape de la fabrication de vos écran, vous le perdrez ailleurs, sur d'autres aspects auxquels vous n'avez pas penser.
VB
The ReAl damn shit
> Si vous savez faire une boite de dialogue avec les controles windows en C/C++, je dirais que c'est la meilleure façon de faire, parce que vous allez tout maitriser (la position des controles, la taille des fontes, les couleurs, les intéractions éventuelles entre les controle) et ainsi v ous allez pouvoir maintenir trés facilement votre interface dans le temps e t vous pourrez répondre aisément à toute demande de modification.
Alors, effectivement si vous avez beaucoup de boites de dialogue à fair e, ca va représenter un travail important. Mais l'expérience montre que que lque soit la méthode que vous allez utiliser, cela représente toujours un travail important de faire des boites de dialogue. D'une part il faut savoir que l'interface représente souvent 90% du temps de développement d'un log iciel, et d'autre part que ce temps est incompressible. Si vous mettez un semain e par formulaire (c'est le temps moyen que je mets à faire une boite de dialogue ou un écran) , si vous avez 30 boites à faire, il faudra 30 semaines. c'est le minimum.
Vous pouvez tout essayer, prendre des outils de soi-disant développemen t rapide, des librairies ad-hoc, vous pouvez même prendre 5 semaines à vous faire un interpréteur/browser de script spécifique au type de formula ire que vous voulez faire. Tout le temps que vous penserez gagner sur telle ou te lle étape de la fabrication de vos écran, vous le perdrez ailleurs, sur d 'autres aspects auxquels vous n'avez pas penser.
VB
Elle est déprimante cette réponse... LALALAAAAALALAAAA J'ENTENDS RIEEN LA LALAAAA
En fait, en lisant vos réponses, j'ai réalisé que je n'avais vraiment pas les connaissances pour prendre ce programme comme ça. Comme je connaissais le C++, et comme j'avais pas mal de traitement à faire, j'ai cru que c'était le meilleur moyen.
Mais en fin de compte, je crois que, puisque je suis seul, je devrais essayer une méthode plus simple. J'ai commencé à voir comment faire avec Visual Basic ce week-end (et oui, je travaille en dehors des heures de boulot, ça c'est la classe...), et j'ai fait en une heure ce que j'ai pu faire en une semaine en C++. Et puis, comme j'ai besoin de manipuler des fiches Excel, je pense que c'est bien la meilleure solution. Enfin........... dites-moi si je me trompe.......
Je ne sais pas encore si je pourrai faire des traitements de données et de fichiers aussi facilement que je l'aurais fait en C++, mais ça se tente...
Merci infiniment pour vos réponses.
PS: oups....... "The ReAl damn shit" pour aller parler à des pros, c'est pas terrible, j'avais pas réalisé... Le pire, c'est que c'est une adresse professionelle............
> Si vous savez faire une boite de dialogue avec les controles windows en
C/C++, je dirais que c'est la meilleure façon de faire, parce que vous allez
tout maitriser (la position des controles, la taille des fontes, les
couleurs, les intéractions éventuelles entre les controle) et ainsi v ous
allez pouvoir maintenir trés facilement votre interface dans le temps e t
vous pourrez répondre aisément à toute demande de modification.
Alors, effectivement si vous avez beaucoup de boites de dialogue à fair e, ca
va représenter un travail important. Mais l'expérience montre que que lque
soit la méthode que vous allez utiliser, cela représente toujours un travail
important de faire des boites de dialogue. D'une part il faut savoir que
l'interface représente souvent 90% du temps de développement d'un log iciel,
et d'autre part que ce temps est incompressible. Si vous mettez un semain e
par formulaire (c'est le temps moyen que je mets à faire une boite de
dialogue ou un écran) , si vous avez 30 boites à faire, il faudra 30
semaines. c'est le minimum.
Vous pouvez tout essayer, prendre des outils de soi-disant développemen t
rapide, des librairies ad-hoc, vous pouvez même prendre 5 semaines à vous
faire un interpréteur/browser de script spécifique au type de formula ire que
vous voulez faire. Tout le temps que vous penserez gagner sur telle ou te lle
étape de la fabrication de vos écran, vous le perdrez ailleurs, sur d 'autres
aspects auxquels vous n'avez pas penser.
VB
Elle est déprimante cette réponse... LALALAAAAALALAAAA J'ENTENDS RIEEN
LA LALAAAA
En fait, en lisant vos réponses, j'ai réalisé que je n'avais vraiment
pas les connaissances pour prendre ce programme comme ça. Comme je
connaissais le C++, et comme j'avais pas mal de traitement à faire,
j'ai cru que c'était le meilleur moyen.
Mais en fin de compte, je crois que, puisque je suis seul, je devrais
essayer une méthode plus simple. J'ai commencé à voir comment faire
avec Visual Basic ce week-end (et oui, je travaille en dehors des
heures de boulot, ça c'est la classe...), et j'ai fait en une heure ce
que j'ai pu faire en une semaine en C++. Et puis, comme j'ai besoin de
manipuler des fiches Excel, je pense que c'est bien la meilleure
solution. Enfin........... dites-moi si je me trompe.......
Je ne sais pas encore si je pourrai faire des traitements de données
et de fichiers aussi facilement que je l'aurais fait en C++, mais ça
se tente...
Merci infiniment pour vos réponses.
PS: oups....... "The ReAl damn shit" pour aller parler à des pros,
c'est pas terrible, j'avais pas réalisé... Le pire, c'est que c'est
une adresse professionelle............
> Si vous savez faire une boite de dialogue avec les controles windows en C/C++, je dirais que c'est la meilleure façon de faire, parce que vous allez tout maitriser (la position des controles, la taille des fontes, les couleurs, les intéractions éventuelles entre les controle) et ainsi v ous allez pouvoir maintenir trés facilement votre interface dans le temps e t vous pourrez répondre aisément à toute demande de modification.
Alors, effectivement si vous avez beaucoup de boites de dialogue à fair e, ca va représenter un travail important. Mais l'expérience montre que que lque soit la méthode que vous allez utiliser, cela représente toujours un travail important de faire des boites de dialogue. D'une part il faut savoir que l'interface représente souvent 90% du temps de développement d'un log iciel, et d'autre part que ce temps est incompressible. Si vous mettez un semain e par formulaire (c'est le temps moyen que je mets à faire une boite de dialogue ou un écran) , si vous avez 30 boites à faire, il faudra 30 semaines. c'est le minimum.
Vous pouvez tout essayer, prendre des outils de soi-disant développemen t rapide, des librairies ad-hoc, vous pouvez même prendre 5 semaines à vous faire un interpréteur/browser de script spécifique au type de formula ire que vous voulez faire. Tout le temps que vous penserez gagner sur telle ou te lle étape de la fabrication de vos écran, vous le perdrez ailleurs, sur d 'autres aspects auxquels vous n'avez pas penser.
VB
Elle est déprimante cette réponse... LALALAAAAALALAAAA J'ENTENDS RIEEN LA LALAAAA
En fait, en lisant vos réponses, j'ai réalisé que je n'avais vraiment pas les connaissances pour prendre ce programme comme ça. Comme je connaissais le C++, et comme j'avais pas mal de traitement à faire, j'ai cru que c'était le meilleur moyen.
Mais en fin de compte, je crois que, puisque je suis seul, je devrais essayer une méthode plus simple. J'ai commencé à voir comment faire avec Visual Basic ce week-end (et oui, je travaille en dehors des heures de boulot, ça c'est la classe...), et j'ai fait en une heure ce que j'ai pu faire en une semaine en C++. Et puis, comme j'ai besoin de manipuler des fiches Excel, je pense que c'est bien la meilleure solution. Enfin........... dites-moi si je me trompe.......
Je ne sais pas encore si je pourrai faire des traitements de données et de fichiers aussi facilement que je l'aurais fait en C++, mais ça se tente...
Merci infiniment pour vos réponses.
PS: oups....... "The ReAl damn shit" pour aller parler à des pros, c'est pas terrible, j'avais pas réalisé... Le pire, c'est que c'est une adresse professionelle............
domi
The ReAl damn shit wrote:
J'ai commencé à voir comment faire
avec Visual Basic ce week-end (et oui, je travaille en dehors des heures de boulot, ça c'est la classe...), et j'ai fait en une heure ce que j'ai pu faire en une semaine en C++. Et puis, comme j'ai besoin de manipuler des fiches Excel, je pense que c'est bien la meilleure solution. Enfin........... dites-moi si je me trompe.......
Si c'est VB6, il n'est plus supporté par Microsoft (http://msdn.microsoft.com/en-us/vbrun/ms788707.aspx) mais ça peut être une option de facilité...
The ReAl damn shit wrote:
J'ai commencé à voir comment faire
avec Visual Basic ce week-end (et oui, je travaille en dehors des
heures de boulot, ça c'est la classe...), et j'ai fait en une heure ce
que j'ai pu faire en une semaine en C++. Et puis, comme j'ai besoin de
manipuler des fiches Excel, je pense que c'est bien la meilleure
solution. Enfin........... dites-moi si je me trompe.......
Si c'est VB6, il n'est plus supporté par Microsoft
(http://msdn.microsoft.com/en-us/vbrun/ms788707.aspx)
mais ça peut être une option de facilité...
avec Visual Basic ce week-end (et oui, je travaille en dehors des heures de boulot, ça c'est la classe...), et j'ai fait en une heure ce que j'ai pu faire en une semaine en C++. Et puis, comme j'ai besoin de manipuler des fiches Excel, je pense que c'est bien la meilleure solution. Enfin........... dites-moi si je me trompe.......
Si c'est VB6, il n'est plus supporté par Microsoft (http://msdn.microsoft.com/en-us/vbrun/ms788707.aspx) mais ça peut être une option de facilité...
The ReAl damn shit
On 3 août, 09:26, domi wrote:
Si c'est VB6, il n'est plus supporté par Microsoft (http://msdn.microsoft.com/en-us/vbrun/ms788707.aspx) mais ça peut être une option de facilité...
J'utilise VB.NET. Si je ne fais pas dans la facilité, je ne ferai rien du tout......
On 3 août, 09:26, domi <d...@domi.com> wrote:
Si c'est VB6, il n'est plus supporté par Microsoft
(http://msdn.microsoft.com/en-us/vbrun/ms788707.aspx)
mais ça peut être une option de facilité...
J'utilise VB.NET. Si je ne fais pas dans la facilité, je ne ferai rien
du tout......
Si c'est VB6, il n'est plus supporté par Microsoft (http://msdn.microsoft.com/en-us/vbrun/ms788707.aspx) mais ça peut être une option de facilité...
J'utilise VB.NET. Si je ne fais pas dans la facilité, je ne ferai rien du tout......
ByB
The ReAl damn shit a couché sur son écran :
Si vous savez faire une boite de dialogue avec les controles windows en C/C++, je dirais que c'est la meilleure façon de faire, parce que vous allez tout maitriser (la position des controles, la taille des fontes, les couleurs, les intéractions éventuelles entre les controle) et ainsi vous allez pouvoir maintenir trés facilement votre interface dans le temps et vous pourrez répondre aisément à toute demande de modification.
Alors, effectivement si vous avez beaucoup de boites de dialogue à faire, ca va représenter un travail important. Mais l'expérience montre que quelque soit la méthode que vous allez utiliser, cela représente toujours un travail important de faire des boites de dialogue. D'une part il faut savoir que l'interface représente souvent 90% du temps de développement d'un logiciel, et d'autre part que ce temps est incompressible. Si vous mettez un semaine par formulaire (c'est le temps moyen que je mets à faire une boite de dialogue ou un écran) , si vous avez 30 boites à faire, il faudra 30 semaines. c'est le minimum.
Vous pouvez tout essayer, prendre des outils de soi-disant développement rapide, des librairies ad-hoc, vous pouvez même prendre 5 semaines à vous faire un interpréteur/browser de script spécifique au type de formulaire que vous voulez faire. Tout le temps que vous penserez gagner sur telle ou telle étape de la fabrication de vos écran, vous le perdrez ailleurs, sur d'autres aspects auxquels vous n'avez pas penser.
VB
Elle est déprimante cette réponse... LALALAAAAALALAAAA J'ENTENDS RIEEN LA LALAAAA
En fait, en lisant vos réponses, j'ai réalisé que je n'avais vraiment pas les connaissances pour prendre ce programme comme ça. Comme je connaissais le C++, et comme j'avais pas mal de traitement à faire, j'ai cru que c'était le meilleur moyen.
Mais en fin de compte, je crois que, puisque je suis seul, je devrais essayer une méthode plus simple. J'ai commencé à voir comment faire avec Visual Basic ce week-end (et oui, je travaille en dehors des heures de boulot, ça c'est la classe...), et j'ai fait en une heure ce que j'ai pu faire en une semaine en C++. Et puis, comme j'ai besoin de manipuler des fiches Excel, je pense que c'est bien la meilleure solution. Enfin........... dites-moi si je me trompe.......
Essayez le VBA sous Access. Il y a des fonctions exprès pour importer et exporter des données Excel (DoCmd.TransferSpreadsheet) et les interfaces se créent rapidement.
The ReAl damn shit a couché sur son écran :
Si vous savez faire une boite de dialogue avec les controles windows en
C/C++, je dirais que c'est la meilleure façon de faire, parce que vous allez
tout maitriser (la position des controles, la taille des fontes, les
couleurs, les intéractions éventuelles entre les controle) et ainsi vous
allez pouvoir maintenir trés facilement votre interface dans le temps et
vous pourrez répondre aisément à toute demande de modification.
Alors, effectivement si vous avez beaucoup de boites de dialogue à faire, ca
va représenter un travail important. Mais l'expérience montre que quelque
soit la méthode que vous allez utiliser, cela représente toujours un travail
important de faire des boites de dialogue. D'une part il faut savoir que
l'interface représente souvent 90% du temps de développement d'un logiciel,
et d'autre part que ce temps est incompressible. Si vous mettez un semaine
par formulaire (c'est le temps moyen que je mets à faire une boite de
dialogue ou un écran) , si vous avez 30 boites à faire, il faudra 30
semaines. c'est le minimum.
Vous pouvez tout essayer, prendre des outils de soi-disant développement
rapide, des librairies ad-hoc, vous pouvez même prendre 5 semaines à vous
faire un interpréteur/browser de script spécifique au type de formulaire que
vous voulez faire. Tout le temps que vous penserez gagner sur telle ou telle
étape de la fabrication de vos écran, vous le perdrez ailleurs, sur d'autres
aspects auxquels vous n'avez pas penser.
VB
Elle est déprimante cette réponse... LALALAAAAALALAAAA J'ENTENDS RIEEN
LA LALAAAA
En fait, en lisant vos réponses, j'ai réalisé que je n'avais vraiment
pas les connaissances pour prendre ce programme comme ça. Comme je
connaissais le C++, et comme j'avais pas mal de traitement à faire,
j'ai cru que c'était le meilleur moyen.
Mais en fin de compte, je crois que, puisque je suis seul, je devrais
essayer une méthode plus simple. J'ai commencé à voir comment faire
avec Visual Basic ce week-end (et oui, je travaille en dehors des
heures de boulot, ça c'est la classe...), et j'ai fait en une heure ce
que j'ai pu faire en une semaine en C++. Et puis, comme j'ai besoin de
manipuler des fiches Excel, je pense que c'est bien la meilleure
solution. Enfin........... dites-moi si je me trompe.......
Essayez le VBA sous Access. Il y a des fonctions exprès pour importer
et exporter des données Excel (DoCmd.TransferSpreadsheet) et les
interfaces se créent rapidement.
Si vous savez faire une boite de dialogue avec les controles windows en C/C++, je dirais que c'est la meilleure façon de faire, parce que vous allez tout maitriser (la position des controles, la taille des fontes, les couleurs, les intéractions éventuelles entre les controle) et ainsi vous allez pouvoir maintenir trés facilement votre interface dans le temps et vous pourrez répondre aisément à toute demande de modification.
Alors, effectivement si vous avez beaucoup de boites de dialogue à faire, ca va représenter un travail important. Mais l'expérience montre que quelque soit la méthode que vous allez utiliser, cela représente toujours un travail important de faire des boites de dialogue. D'une part il faut savoir que l'interface représente souvent 90% du temps de développement d'un logiciel, et d'autre part que ce temps est incompressible. Si vous mettez un semaine par formulaire (c'est le temps moyen que je mets à faire une boite de dialogue ou un écran) , si vous avez 30 boites à faire, il faudra 30 semaines. c'est le minimum.
Vous pouvez tout essayer, prendre des outils de soi-disant développement rapide, des librairies ad-hoc, vous pouvez même prendre 5 semaines à vous faire un interpréteur/browser de script spécifique au type de formulaire que vous voulez faire. Tout le temps que vous penserez gagner sur telle ou telle étape de la fabrication de vos écran, vous le perdrez ailleurs, sur d'autres aspects auxquels vous n'avez pas penser.
VB
Elle est déprimante cette réponse... LALALAAAAALALAAAA J'ENTENDS RIEEN LA LALAAAA
En fait, en lisant vos réponses, j'ai réalisé que je n'avais vraiment pas les connaissances pour prendre ce programme comme ça. Comme je connaissais le C++, et comme j'avais pas mal de traitement à faire, j'ai cru que c'était le meilleur moyen.
Mais en fin de compte, je crois que, puisque je suis seul, je devrais essayer une méthode plus simple. J'ai commencé à voir comment faire avec Visual Basic ce week-end (et oui, je travaille en dehors des heures de boulot, ça c'est la classe...), et j'ai fait en une heure ce que j'ai pu faire en une semaine en C++. Et puis, comme j'ai besoin de manipuler des fiches Excel, je pense que c'est bien la meilleure solution. Enfin........... dites-moi si je me trompe.......
Essayez le VBA sous Access. Il y a des fonctions exprès pour importer et exporter des données Excel (DoCmd.TransferSpreadsheet) et les interfaces se créent rapidement.
The ReAl damn shit
Hmmm.... Conseil intéressant... Je vais me renseigner de ce pas.
Merci beaucoup.
Hmmm.... Conseil intéressant... Je vais me renseigner de ce pas.
Hmmm.... Conseil intéressant... Je vais me renseigner de ce pas.
Merci beaucoup.
ByB
The ReAl damn shit a exprimé avec précision :
Hmmm.... Conseil intéressant... Je vais me renseigner de ce pas.
Merci beaucoup.
Avec Access, vous pouvez créer des liens avec les fichiers Excel de façon à ce qu'ils soient considérés par Access comme des tables de bases de données. Vous pouvez alors effectuer des requêtes SQL sur vos fichiers pour en récupérer les données (SELECT * FROM MONFICHIEREXCEL par exemble ...)
The ReAl damn shit a exprimé avec précision :
Hmmm.... Conseil intéressant... Je vais me renseigner de ce pas.
Merci beaucoup.
Avec Access, vous pouvez créer des liens avec les fichiers Excel de
façon à ce qu'ils soient considérés par Access comme des tables de
bases de données. Vous pouvez alors effectuer des requêtes SQL sur vos
fichiers pour en récupérer les données (SELECT * FROM MONFICHIEREXCEL
par exemble ...)
Hmmm.... Conseil intéressant... Je vais me renseigner de ce pas.
Merci beaucoup.
Avec Access, vous pouvez créer des liens avec les fichiers Excel de façon à ce qu'ils soient considérés par Access comme des tables de bases de données. Vous pouvez alors effectuer des requêtes SQL sur vos fichiers pour en récupérer les données (SELECT * FROM MONFICHIEREXCEL par exemble ...)
