a faire et ne pas faire en VFP

Je suis utilisateur occasionnel et en lisant une contribution dans ATOUTFOX il y a un article qui s'intitule ' a faire et ne pas faire en VFP'
j'aimerais savoir pourquoi il ne faut pas utiliser un groupe de formulaire(formset) ? quand vous avez plusieurs tables ouvertes,avec de la saisie dans des textbox qui servent de parametres dans plusieurs formulaires du groupe c'est bien  pratique, ou alors est-il preferable d'utiliser plusieurs formulaires independant que l'on lance avec DO FORM .... et comment garde t-on les parametres saisies par exemple dans un formulaire 1 et que l'on veut re- utilisez dans un formulaire 5 ?  Egalement ne pas utiliser SET FILTER (qui est bien pratique je trouve),mais une vue parametrée . pourquoi ? et qu'est-ce-qu'une vue parametrée ? merci d'avance pour les conseils

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

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.

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

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

Versionde VFP? 6 peut-etre, remplace
oform1=NEWOBJECT("form1")

par

oform1=CREATEOBJECT("form1")


Mike Gagnon

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