A faire et ne pas faire en VFP
Résolu
cs_brunaux
Messages postés
34
Date d'inscription
jeudi 25 novembre 2004
Statut
Membre
Dernière intervention
19 octobre 2006
-
5 juil. 2005 à 13:55
Mike Gagnon Messages postés 381 Date d'inscription vendredi 15 octobre 2004 Statut Membre Dernière intervention 24 octobre 2013 - 11 juil. 2005 à 15:55
Mike Gagnon Messages postés 381 Date d'inscription vendredi 15 octobre 2004 Statut Membre Dernière intervention 24 octobre 2013 - 11 juil. 2005 à 15:55
A voir également:
- Documentater
- Strconv vfp ✓ - Forum Foxpro
- Vfp ✓ - Forum Foxpro
- Vfp substr - Forum Foxpro
- Vfp pharmacy ✓ - Forum Foxpro
- Vfp runtime - Forum Foxpro
8 réponses
Mike Gagnon
Messages postés
381
Date d'inscription
vendredi 15 octobre 2004
Statut
Membre
Dernière intervention
24 octobre 2013
2
11 juil. 2005 à 15:55
11 juil. 2005 à 15:55
Peut-etre oublié une ligne au tout début, change le début avec ce qui suit et laisse reste comme il est (Il faut ouvrir la table)
USE HOME(2)+'\tastrade\data\orders' SHARED AGAIN IN 0
PUBLIC oform1
oform1=createobj("form1")
oform1.Show
RETURN
Mike Gagnon
USE HOME(2)+'\tastrade\data\orders' SHARED AGAIN IN 0
PUBLIC oform1
oform1=createobj("form1")
oform1.Show
RETURN
Mike Gagnon
Mike Gagnon
Messages postés
381
Date d'inscription
vendredi 15 octobre 2004
Statut
Membre
Dernière intervention
24 octobre 2013
2
5 juil. 2005 à 16:21
5 juil. 2005 à 16:21
La réponse la plus simple à donner? Le temps d'exécution.
1. Pour le formset. Si par exemple tu as un formset avec 10 formes à l'intérieur. Lorsque tu créer un instance de ce formset, VFP doit générer toutes les formes du formset (meme si l'utilisera pas les dit formulaires), qu'il soit visible ou non. Très lent. Je te conseille de commencer par un formulaire principal et le reste des classes formulaire que tu instancie et détruit à mesure.
2. Pour ce qui est du SET FILTER TO, la situation est la meme, un SET FILTER TO sur une table de 500,000 records (il m'arrive souvent de gérer des tables de cette dimension), va prendre presque dix fois plus lentement à trouver un record qu'un SQL statement ou une vue parametrée.
Si les techniques proposées ne te sont pas famillier, pose des questions.
Mike Gagnon
1. Pour le formset. Si par exemple tu as un formset avec 10 formes à l'intérieur. Lorsque tu créer un instance de ce formset, VFP doit générer toutes les formes du formset (meme si l'utilisera pas les dit formulaires), qu'il soit visible ou non. Très lent. Je te conseille de commencer par un formulaire principal et le reste des classes formulaire que tu instancie et détruit à mesure.
2. Pour ce qui est du SET FILTER TO, la situation est la meme, un SET FILTER TO sur une table de 500,000 records (il m'arrive souvent de gérer des tables de cette dimension), va prendre presque dix fois plus lentement à trouver un record qu'un SQL statement ou une vue parametrée.
Si les techniques proposées ne te sont pas famillier, pose des questions.
Mike Gagnon
cs_brunaux
Messages postés
34
Date d'inscription
jeudi 25 novembre 2004
Statut
Membre
Dernière intervention
19 octobre 2006
6 juil. 2005 à 07:56
6 juil. 2005 à 07:56
Merci Mike pour les réponses
Encore faut-il tout comprendre !!! Pour nous autres utilisateurs occasionnels c'est pas évident.
Quelle différence entre un Formulaire normal et une "classe Formulaire (comment cree t-on une classe formulaire ?) que l'on instancie et détruit au fur et a mesure " ? Qu'est-ce-que cela veut dire ?
Si je saisie dans un champs une valeur (dans mon formulaire principal ) exemple:un departement , et que je lance mon formulaire 5 avec do form 5 (dans le code click d'un bouton ,exemple 'Afficher les villes'),comment je garde la valeur saisie dans form1 ?
alors que la dans mon groupe de formulaire quand j'active mon form 5 (thisformset.form5.show) et que je suis dans mon form 5 je fais juste par exemple :set filter to monDepartement = thisformset.form1.text3.value (ou j'ai saisie mon numero de département) , et dans une grille du form 5 j'affiche toutes les villes du departement choisi et quand je veut revenir dans mon form 1 je fais dans un bouton Quitter du form 5 : thisform.hide et je reviens tout de suite dans mon formulaire principal. C'est tout,c'est simple et rapide, alors ou est l'avantage de creer des classes formulaire independantes que l'on utilise et detruit au fur et a mesure ?
les plus gros fichiers que j'utilise font 20 000 enregis. donc le set filter est rapide .
voir plus haut ,si dans j'ai une grille(un grid) dans un formulaire et que j'affiche les villes (et autres caracteristiques)du departement, c'est rapide avec le set filter to .
set filter to monDepartement = thisformset.form1.text3.value
thisform.refresh
comment afficher les memes données avec un SQL statement (qu'est-ce-c'est ?) ou une vue parametrée (meme chose ?) et ou est vraiment l'avantage ?
ce n'est pas evident de s'exprimer par message ,j'espere que je ne suis pas trop confus dans les explications,
et j'attends les réponses avec impatience et plaisir !!
bonne journée
Encore faut-il tout comprendre !!! Pour nous autres utilisateurs occasionnels c'est pas évident.
Quelle différence entre un Formulaire normal et une "classe Formulaire (comment cree t-on une classe formulaire ?) que l'on instancie et détruit au fur et a mesure " ? Qu'est-ce-que cela veut dire ?
Si je saisie dans un champs une valeur (dans mon formulaire principal ) exemple:un departement , et que je lance mon formulaire 5 avec do form 5 (dans le code click d'un bouton ,exemple 'Afficher les villes'),comment je garde la valeur saisie dans form1 ?
alors que la dans mon groupe de formulaire quand j'active mon form 5 (thisformset.form5.show) et que je suis dans mon form 5 je fais juste par exemple :set filter to monDepartement = thisformset.form1.text3.value (ou j'ai saisie mon numero de département) , et dans une grille du form 5 j'affiche toutes les villes du departement choisi et quand je veut revenir dans mon form 1 je fais dans un bouton Quitter du form 5 : thisform.hide et je reviens tout de suite dans mon formulaire principal. C'est tout,c'est simple et rapide, alors ou est l'avantage de creer des classes formulaire independantes que l'on utilise et detruit au fur et a mesure ?
les plus gros fichiers que j'utilise font 20 000 enregis. donc le set filter est rapide .
voir plus haut ,si dans j'ai une grille(un grid) dans un formulaire et que j'affiche les villes (et autres caracteristiques)du departement, c'est rapide avec le set filter to .
set filter to monDepartement = thisformset.form1.text3.value
thisform.refresh
comment afficher les memes données avec un SQL statement (qu'est-ce-c'est ?) ou une vue parametrée (meme chose ?) et ou est vraiment l'avantage ?
ce n'est pas evident de s'exprimer par message ,j'espere que je ne suis pas trop confus dans les explications,
et j'attends les réponses avec impatience et plaisir !!
bonne journée
Mike Gagnon
Messages postés
381
Date d'inscription
vendredi 15 octobre 2004
Statut
Membre
Dernière intervention
24 octobre 2013
2
6 juil. 2005 à 12:04
6 juil. 2005 à 12:04
Tes questions
reviennent aux principes fondamentaux de OOP (Object Oriented Programming). Et
le principe de base de OOP est : Chaque objet (formulaire) dans ce cas-ci
doivent être capable de fonctionner seul sans l'aide du restant de
l'application). Dans le cas du Formset ce la brise le principe de
l'encapsulation (qui veut dire ce que je viens d'écrire)
Je reprends ton texte par morceaux.
>>Quelle différence entre un Formulaire normal et une "classe
Formulaire (comment crée t-on une classe formulaire ?) Que l'on instancier
et détruit au fur et a mesure " ? Qu'est ce que cela veut dire ?
Il y a deux façons de créer une classe formulaire. Par code ou en créant un
classe formulaire dans une librairie de classes, que l'on peut réutiliser
n'importe ou dans l'application (Deuxième principe de OOP - la réutilisation
des objets). Mais ce site étant ce qu'il est je ne peu que te montrer comment
créer un formulaire via code. Voici un petit example
(roule ceci dans un prg).
PUBLIC oform1
oform1=NEWOBJECT("form1")
oform1.Show
RETURN
DEFINE CLASS form1 AS form
Height = 194
Width = 375
DoCreate = .T.
AutoCenter = .T.
Caption = "Identification"
MaxButton = .F.
MinButton = .F.
AlwaysOnTop = .T.
Name = "Form1"
ADD OBJECT text1 AS textbox WITH ;
ControlSource =
"orders.order_id", ;
Height = 23, ;
Left = 36, ;
Top = 36, ;
Width = 100, ;
Name = "Text1"
ADD OBJECT label1 AS label WITH ;
AutoSize = .T., ;
Caption = "Order ID", ;
Height = 17, ;
Left = 48, ;
Top = 12, ;
Width = 48, ;
Name = "Label1"
ADD OBJECT text2 AS textbox WITH ;
ControlSource =
"orders.customer_id", ;
Height = 23, ;
Left = 156, ;
Top = 36, ;
Width = 156, ;
Name = "Text2"
ADD OBJECT label2 AS label WITH ;
Caption = "Customer ID", ;
Height = 17, ;
Left = 156, ;
Top = 12, ;
Width = 84, ;
Name = "Label2"
ADD OBJECT combo1 AS combobox
WITH ;
RowSourceType = 1, ;
RowSource = "A,B,C,D", ;
Height = 24, ;
Left = 36, ;
Top = 84, ;
Width = 100, ;
Name = "Combo1"
ADD OBJECT label3 AS label WITH ;
AutoSize = .T., ;
Caption = "Disctrict", ;
Height = 17, ;
Left = 48, ;
Top = 66, ;
Width = 46, ;
Name = "Label3"
ADD OBJECT command1 AS commandbutton WITH ;
Top = 132, ;
Left = 145, ;
Height = 27, ;
Width = 84, ;
Caption = "Fermer", ;
Name = "Command1"
PROCEDURE command1.Click
RELEASE thisform
ENDPROC
ENDDEFINE
>>>>Si je saisie dans un champs une valeur (dans mon formulaire
principal ) exemple:un departement , et que je lance mon formulaire
5 avec do form 5 (dans le code click d'un bouton ,exemple 'Afficher les
villes'),comment je garde la valeur saisie dans form1 ?
alors que la dans mon groupe de formulaire quand
j'active mon form 5 (thisformset.form5.show) et que je suis dans mon form
5 je fais juste par exemple :set filter to monDepartement =
thisformset.form1.text3.value (ou j'ai saisie mon numero de département) , et
dans une grille du form 5 j'affiche toutes les villes du departement choisi
et quand je veut revenir dans mon form 1 je fais dans un bouton Quitter du
form 5 : thisform.hide et je reviens tout de suite dans mon formulaire
principal. C'est tout,c'est simple et rapide, alors ou est l'avantage de
creer des classes formulaire independantes que l'on utilise et detruit au fur
et a mesure ?<<<<
L'avantage? Un formset est lourd (en tant que taille de fichier), et comme
mentionné, VFP doit générer tous les formulaires du formset. Il est plus
difficile à gérer, il trahit les règles de l'encapsulation etc...Honnêtement
Microsoft n'aurait du jamais laissé ce truc dans VFP. Ici tu as 5 formes, mais peut-être
un jour tu aura 20 formes, et la tu vas voir la différence. Il faut apprendre à
programmer en prévoyant le futur. Ton code doit fonctionner sous n'importe quel
circonstance. Pour reprendre l'exemple ci-haut, si a la toute première ligne tu ajoute ceci:
USE HOME(2)+"tastrade\data\orders" SHARED AGAIN IN 0
Et que tu roule le formulaire, on peu voir que les données son montrées dans les deux textboxes.
>>>> les plus gros fichiers que j'utilise font 20 000 enregis. donc le set filter est rapide .voir
plus haut ,si dans j'ai une grille(un grid) dans un formulaire et que
j'affiche les villes (et autres caracteristiques)du departement, c'est
rapide avec le set filter to .
set filter to monDepartement = thisformset.form1.text3.value
thisform.refresh
Encore là, aujourd'hui 20,000 et demain 200,000. Donc aujourd'hui ton
code fonctionne, mais demain il ne fonctionne plus (ou est trop lent).
Et attend, demain il y a 200,000 records sur un réseau de 300
utilisateurs. Donc on programme pour demain.
>>comment afficher les memes données avec un SQL statement
(qu'est-ce-c'est ?) ou une vue parametrée (meme chose ?) et ou
est vraiment l'avantage ?
Rapidité d'exécution, bon principe de programmation. Pour reprendre la
table ci-haut, en faire un SQL (sequencial query language). Encore un
fois aujourd'hui tu traite une petite table VFP et demain tu va taiter
une table SQL (pas VFP) sur un serveur en réseau. Ton code ne vas plus
fonctionner.
USE HOME(2)+"tastrade\data\orders" SHARED AGAIN IN 0
SELECT * FROM orders WHERE customer_id = 'FOLKO' INTO CURSOR moncurseur
SELECT moncurseur
BROWSE
Ce que je viens de démontér est un SQL dans un curseur (strictement
pour voir le résultat de la recherche sans possibilité de modifier la
table originale). Un vue par code est similaire (en tant quie code),
mais elle te donne la possibilité de modifier les records et ce que
affecte la table parent. Difficile à montrer une vue paramètrer ici,
mais il y a un designer (wizard) dans VFP que peut t'aider a en crée
une.
Et la tu a un curseur avec seulement les records que tu as besoin, qui peuvent etre montrés dans une grille.
>>ce n'est pas evident de s'exprimer par message ,j'espere que je ne suis pas trop confus dans les explications,
Non, je ne crois pas. Mais n'oubli pas, ce qui est facile n'est
peut-etre pas la solution idéale. Mais une fois que tu métrise un petit
morceau, tu passe à un autre, et tu étudie le code que tu vois
(Exemples avec VFP, ici, sur les newsgroups etc) et tu l'applique à ton
programme.
Et en passant, moi aussi j'utlisait des formsets et des SET FILTER TO
par ce que c'était facile, mais a mesure que je progressais, je pouvais
voir que mon code ne ferait plus.
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->
reviennent aux principes fondamentaux de OOP (Object Oriented Programming). Et
le principe de base de OOP est : Chaque objet (formulaire) dans ce cas-ci
doivent être capable de fonctionner seul sans l'aide du restant de
l'application). Dans le cas du Formset ce la brise le principe de
l'encapsulation (qui veut dire ce que je viens d'écrire)
Je reprends ton texte par morceaux.
>>Quelle différence entre un Formulaire normal et une "classe
Formulaire (comment crée t-on une classe formulaire ?) Que l'on instancier
et détruit au fur et a mesure " ? Qu'est ce que cela veut dire ?
Il y a deux façons de créer une classe formulaire. Par code ou en créant un
classe formulaire dans une librairie de classes, que l'on peut réutiliser
n'importe ou dans l'application (Deuxième principe de OOP - la réutilisation
des objets). Mais ce site étant ce qu'il est je ne peu que te montrer comment
créer un formulaire via code. Voici un petit example
(roule ceci dans un prg).
PUBLIC oform1
oform1=NEWOBJECT("form1")
oform1.Show
RETURN
DEFINE CLASS form1 AS form
Height = 194
Width = 375
DoCreate = .T.
AutoCenter = .T.
Caption = "Identification"
MaxButton = .F.
MinButton = .F.
AlwaysOnTop = .T.
Name = "Form1"
ADD OBJECT text1 AS textbox WITH ;
ControlSource =
"orders.order_id", ;
Height = 23, ;
Left = 36, ;
Top = 36, ;
Width = 100, ;
Name = "Text1"
ADD OBJECT label1 AS label WITH ;
AutoSize = .T., ;
Caption = "Order ID", ;
Height = 17, ;
Left = 48, ;
Top = 12, ;
Width = 48, ;
Name = "Label1"
ADD OBJECT text2 AS textbox WITH ;
ControlSource =
"orders.customer_id", ;
Height = 23, ;
Left = 156, ;
Top = 36, ;
Width = 156, ;
Name = "Text2"
ADD OBJECT label2 AS label WITH ;
Caption = "Customer ID", ;
Height = 17, ;
Left = 156, ;
Top = 12, ;
Width = 84, ;
Name = "Label2"
ADD OBJECT combo1 AS combobox
WITH ;
RowSourceType = 1, ;
RowSource = "A,B,C,D", ;
Height = 24, ;
Left = 36, ;
Top = 84, ;
Width = 100, ;
Name = "Combo1"
ADD OBJECT label3 AS label WITH ;
AutoSize = .T., ;
Caption = "Disctrict", ;
Height = 17, ;
Left = 48, ;
Top = 66, ;
Width = 46, ;
Name = "Label3"
ADD OBJECT command1 AS commandbutton WITH ;
Top = 132, ;
Left = 145, ;
Height = 27, ;
Width = 84, ;
Caption = "Fermer", ;
Name = "Command1"
PROCEDURE command1.Click
RELEASE thisform
ENDPROC
ENDDEFINE
>>>>Si je saisie dans un champs une valeur (dans mon formulaire
principal ) exemple:un departement , et que je lance mon formulaire
5 avec do form 5 (dans le code click d'un bouton ,exemple 'Afficher les
villes'),comment je garde la valeur saisie dans form1 ?
alors que la dans mon groupe de formulaire quand
j'active mon form 5 (thisformset.form5.show) et que je suis dans mon form
5 je fais juste par exemple :set filter to monDepartement =
thisformset.form1.text3.value (ou j'ai saisie mon numero de département) , et
dans une grille du form 5 j'affiche toutes les villes du departement choisi
et quand je veut revenir dans mon form 1 je fais dans un bouton Quitter du
form 5 : thisform.hide et je reviens tout de suite dans mon formulaire
principal. C'est tout,c'est simple et rapide, alors ou est l'avantage de
creer des classes formulaire independantes que l'on utilise et detruit au fur
et a mesure ?<<<<
L'avantage? Un formset est lourd (en tant que taille de fichier), et comme
mentionné, VFP doit générer tous les formulaires du formset. Il est plus
difficile à gérer, il trahit les règles de l'encapsulation etc...Honnêtement
Microsoft n'aurait du jamais laissé ce truc dans VFP. Ici tu as 5 formes, mais peut-être
un jour tu aura 20 formes, et la tu vas voir la différence. Il faut apprendre à
programmer en prévoyant le futur. Ton code doit fonctionner sous n'importe quel
circonstance. Pour reprendre l'exemple ci-haut, si a la toute première ligne tu ajoute ceci:
USE HOME(2)+"tastrade\data\orders" SHARED AGAIN IN 0
Et que tu roule le formulaire, on peu voir que les données son montrées dans les deux textboxes.
>>>> les plus gros fichiers que j'utilise font 20 000 enregis. donc le set filter est rapide .voir
plus haut ,si dans j'ai une grille(un grid) dans un formulaire et que
j'affiche les villes (et autres caracteristiques)du departement, c'est
rapide avec le set filter to .
set filter to monDepartement = thisformset.form1.text3.value
thisform.refresh
Encore là, aujourd'hui 20,000 et demain 200,000. Donc aujourd'hui ton
code fonctionne, mais demain il ne fonctionne plus (ou est trop lent).
Et attend, demain il y a 200,000 records sur un réseau de 300
utilisateurs. Donc on programme pour demain.
>>comment afficher les memes données avec un SQL statement
(qu'est-ce-c'est ?) ou une vue parametrée (meme chose ?) et ou
est vraiment l'avantage ?
Rapidité d'exécution, bon principe de programmation. Pour reprendre la
table ci-haut, en faire un SQL (sequencial query language). Encore un
fois aujourd'hui tu traite une petite table VFP et demain tu va taiter
une table SQL (pas VFP) sur un serveur en réseau. Ton code ne vas plus
fonctionner.
USE HOME(2)+"tastrade\data\orders" SHARED AGAIN IN 0
SELECT * FROM orders WHERE customer_id = 'FOLKO' INTO CURSOR moncurseur
SELECT moncurseur
BROWSE
Ce que je viens de démontér est un SQL dans un curseur (strictement
pour voir le résultat de la recherche sans possibilité de modifier la
table originale). Un vue par code est similaire (en tant quie code),
mais elle te donne la possibilité de modifier les records et ce que
affecte la table parent. Difficile à montrer une vue paramètrer ici,
mais il y a un designer (wizard) dans VFP que peut t'aider a en crée
une.
Et la tu a un curseur avec seulement les records que tu as besoin, qui peuvent etre montrés dans une grille.
>>ce n'est pas evident de s'exprimer par message ,j'espere que je ne suis pas trop confus dans les explications,
Non, je ne crois pas. Mais n'oubli pas, ce qui est facile n'est
peut-etre pas la solution idéale. Mais une fois que tu métrise un petit
morceau, tu passe à un autre, et tu étudie le code que tu vois
(Exemples avec VFP, ici, sur les newsgroups etc) et tu l'applique à ton
programme.
Et en passant, moi aussi j'utlisait des formsets et des SET FILTER TO
par ce que c'était facile, mais a mesure que je progressais, je pouvais
voir que mon code ne ferait plus.
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
michelatoutfox
Messages postés
828
Date d'inscription
mardi 5 octobre 2004
Statut
Membre
Dernière intervention
7 mai 2013
1
6 juil. 2005 à 12:23
6 juil. 2005 à 12:23
Bonjour,
quelques réponses, quelques pistes de réflexion...
Sur le Formset:
L'intéret du formset, c'est de pouvoir partager un environnement de données privé entre plusieurs formulaires. C'est à dire que les actions apportés sur les alias depuis un formulaire (par exemple un set filter to... sur un alias) sont visibles depuis tous les formulaires du formset.
Je n'ai pas l'impression que tu utilises cette spécificité ; si tu veux "lire" le contenu du textbox text3 du form form1 depuis le form form5 pour actualiser le contenu d'un grid, tu peux parfaitement te passer de formset (au passage, j'en profite pour te conseiller d'utiliser des noms plus parlant que text3, form1, etc...). Tu vas utiliser des forms ordinaires, avec leur environnement de données privé, et tu vas dire :
dans l'init du form5, set filter to form1.text3.value
ou bien, dans le click du bouton du form1 qui lance le form5, un do form5 with thisform.text3.value, et tu met dans l'init du form5 un Lparameters departement, suivi d'un set filter to mondepartement=departement
(en fait, il faut d'abord vérifier que le paramètre existe, et qu'il est du type requis pour le set filter).
L'avantage des form indépendants par rapport au formset? en dehors de ce que Mike indique (et qui est vrai, les temps de chargement peuvent devenir longs), c'est d'abord la maintenance et l'évolution du programme.
Par exemple, ton form de choix de ville par département va être utilisable partout où tu en auras besoin, sans réécriture, alors que dans le formset, il n'existe pas sans le formset. Si tu as une modification à faire sur ce form, tu ne touches à rien d'autre, tu n'as pas d'effets secondaires non désirés.
Sur le Set Filter:
L'intéret des requetes SQL et des vues parametrées, c'est leur rapidité et les possibilités qu'elles apportent, en matière de maintenance et d'évolution là aussi.
Cette rapidité n'est probablement pas perceptible dans ton cas, tu as raison. Et si tu n'es pas à l'aise avec la syntaxe SQL, alors ta maintenance n'en sera pas facilitée, au contraire! De nombreuses applications tournent dans le monde depuis des années, sans contenir une seule vue ou requête SQL, tu peux continuer avec les set filter.
Celà dit, pour la suite, il serait bon de te mettre à SQL...
Est-ce clair ? si besoin est, n'hésite pas à poser toutes les questions qui te semblent nécessaires, mais essaie d'être précis (donne les lignes de code, par exemple).
quelques réponses, quelques pistes de réflexion...
Sur le Formset:
L'intéret du formset, c'est de pouvoir partager un environnement de données privé entre plusieurs formulaires. C'est à dire que les actions apportés sur les alias depuis un formulaire (par exemple un set filter to... sur un alias) sont visibles depuis tous les formulaires du formset.
Je n'ai pas l'impression que tu utilises cette spécificité ; si tu veux "lire" le contenu du textbox text3 du form form1 depuis le form form5 pour actualiser le contenu d'un grid, tu peux parfaitement te passer de formset (au passage, j'en profite pour te conseiller d'utiliser des noms plus parlant que text3, form1, etc...). Tu vas utiliser des forms ordinaires, avec leur environnement de données privé, et tu vas dire :
dans l'init du form5, set filter to form1.text3.value
ou bien, dans le click du bouton du form1 qui lance le form5, un do form5 with thisform.text3.value, et tu met dans l'init du form5 un Lparameters departement, suivi d'un set filter to mondepartement=departement
(en fait, il faut d'abord vérifier que le paramètre existe, et qu'il est du type requis pour le set filter).
L'avantage des form indépendants par rapport au formset? en dehors de ce que Mike indique (et qui est vrai, les temps de chargement peuvent devenir longs), c'est d'abord la maintenance et l'évolution du programme.
Par exemple, ton form de choix de ville par département va être utilisable partout où tu en auras besoin, sans réécriture, alors que dans le formset, il n'existe pas sans le formset. Si tu as une modification à faire sur ce form, tu ne touches à rien d'autre, tu n'as pas d'effets secondaires non désirés.
Sur le Set Filter:
L'intéret des requetes SQL et des vues parametrées, c'est leur rapidité et les possibilités qu'elles apportent, en matière de maintenance et d'évolution là aussi.
Cette rapidité n'est probablement pas perceptible dans ton cas, tu as raison. Et si tu n'es pas à l'aise avec la syntaxe SQL, alors ta maintenance n'en sera pas facilitée, au contraire! De nombreuses applications tournent dans le monde depuis des années, sans contenir une seule vue ou requête SQL, tu peux continuer avec les set filter.
Celà dit, pour la suite, il serait bon de te mettre à SQL...
Est-ce clair ? si besoin est, n'hésite pas à poser toutes les questions qui te semblent nécessaires, mais essaie d'être précis (donne les lignes de code, par exemple).
cs_brunaux
Messages postés
34
Date d'inscription
jeudi 25 novembre 2004
Statut
Membre
Dernière intervention
19 octobre 2006
7 juil. 2005 à 14:16
7 juil. 2005 à 14:16
Merci Mike et Michel pour vos réponses et vos réflexions.
Pour commencer j'ai essayer de faire marcher ton petit programme mike et erreur pour oform1=NEWOBJECT("form1")
message "erreur d'instanciation de l'objet" ??
c'est vrai que la programmation ou technique que j'emploie ne sont pas tres orthodoxe,mais je n'ai aucune formation informatique,je ne connais aucun autre langage et VFP je l'ai appris tout seul avec un petit livre et l'aide en ligne, alors c'est vrai je vais au plus facile mais on fait avec ce que l'on sait faire et ce que l'on comprend en lisant.
Rien ne remplacera une personne qui vous apprends et qui peut vous montrer de visu des choses qui nous semblent vraiment abstrait en lisant l'aide en ligne de VFP.je ne fais que des petits programmes et des formulaires de saisie ou de toutes petites applications (ou j'utilise quand meme des fois des 'select xxx fom xxx into curseur xxx order by xxx' etc...pour des listes deroulantes avec des choix) donc pour l'instant ca passe et honnetement je sais que je n'aurais jamais a utiliser des tables de 300 000 enregis. ou faire une application en reseau alors .... mais je comprends que vous puissiez restez parfois interloqués en voyant des programmes venant d'utilisateurs occasionnels autoditacte !!!
merci encore de votre aide et je n'hesiterais pas à demander encore des conseils sur votre site
Pour commencer j'ai essayer de faire marcher ton petit programme mike et erreur pour oform1=NEWOBJECT("form1")
message "erreur d'instanciation de l'objet" ??
c'est vrai que la programmation ou technique que j'emploie ne sont pas tres orthodoxe,mais je n'ai aucune formation informatique,je ne connais aucun autre langage et VFP je l'ai appris tout seul avec un petit livre et l'aide en ligne, alors c'est vrai je vais au plus facile mais on fait avec ce que l'on sait faire et ce que l'on comprend en lisant.
Rien ne remplacera une personne qui vous apprends et qui peut vous montrer de visu des choses qui nous semblent vraiment abstrait en lisant l'aide en ligne de VFP.je ne fais que des petits programmes et des formulaires de saisie ou de toutes petites applications (ou j'utilise quand meme des fois des 'select xxx fom xxx into curseur xxx order by xxx' etc...pour des listes deroulantes avec des choix) donc pour l'instant ca passe et honnetement je sais que je n'aurais jamais a utiliser des tables de 300 000 enregis. ou faire une application en reseau alors .... mais je comprends que vous puissiez restez parfois interloqués en voyant des programmes venant d'utilisateurs occasionnels autoditacte !!!
merci encore de votre aide et je n'hesiterais pas à demander encore des conseils sur votre site
Mike Gagnon
Messages postés
381
Date d'inscription
vendredi 15 octobre 2004
Statut
Membre
Dernière intervention
24 octobre 2013
2
8 juil. 2005 à 19:50
8 juil. 2005 à 19:50
>>>Pour commencer j'ai essayer de faire marcher ton petit programme mike et erreur pour oform1=NEWOBJECT("form1")
message "erreur d'instanciation de l'objet" ??
Versionde VFP? 6 peut-etre, remplace
oform1=NEWOBJECT("form1")
par
oform1=CREATEOBJECT("form1")
Mike Gagnon
message "erreur d'instanciation de l'objet" ??
Versionde VFP? 6 peut-etre, remplace
oform1=NEWOBJECT("form1")
par
oform1=CREATEOBJECT("form1")
Mike Gagnon
cs_brunaux
Messages postés
34
Date d'inscription
jeudi 25 novembre 2004
Statut
Membre
Dernière intervention
19 octobre 2006
11 juil. 2005 à 14:43
11 juil. 2005 à 14:43
Bonjour Mike
Effectivement je suis sous VFP6, mais désolé cela fait toujours le même message
"erreur d'instanciation de l'objet" ??
a moins que je ne fasse une erreur de manipulation, mais bon s j'ai juste mis tes lignes de code dans un programme et voila les resultats ??
Effectivement je suis sous VFP6, mais désolé cela fait toujours le même message
"erreur d'instanciation de l'objet" ??
a moins que je ne fasse une erreur de manipulation, mais bon s j'ai juste mis tes lignes de code dans un programme et voila les resultats ??
