jvdh
Messages postés13Date d'inscriptionmardi 3 mai 2005StatutMembreDernière intervention25 octobre 2009
-
28 août 2005 à 20:12
FredArmoni
Messages postés153Date d'inscriptionvendredi 2 mai 2003StatutModérateurDernière intervention 2 avril 2010
-
8 sept. 2005 à 09:55
Salut a tous,
Je programme depuis environ 2 ans en Visual Foxpro (version 8) et j'ai
pu elaborer plusieurs systemes de gestion tant monoposte qu'en reseau
sans beaucoup de problemes vu qu'auparavant j'utilisais CLIPPER.
Il se trouve que je dois realiser un travail pour une ecole. L'idee est
de conserver l'information de plusieurs cycles scolaires. En Clipper,
pas de problemes, je cree un fichier pour chaque cycle mais en VFP je
suis paume car comme les formulaires font appel a une base de donnees
precise, je ne trouve pas la maniere de conserver ni d'accesser les
informations. Quelqu'un a -t-il une idee pour resoudre ce probleme ???
fonch001
Messages postés10Date d'inscriptionjeudi 25 août 2005StatutMembreDernière intervention16 septembre 2005 29 août 2005 à 16:01
Salut,
n'utilise jamais le "data environnement" qui garde en mémoire un chemin absolu, fait simplement un "use tablemachin" dans les méthodes load de tes formulaires.
En ayant pris soin de définir convenablement le "path" au début de ton progamme, tu ne devrait pas avoir de problème de localisation de tes tables.
jvdh
Messages postés13Date d'inscriptionmardi 3 mai 2005StatutMembreDernière intervention25 octobre 2009 29 août 2005 à 17:58
Salut,
Ce petit message pour te remercier pour avoir repondu si rapidement a mon probleme ainsi pour la solution proposee.
Je vais modifier mon projet de cette maniere.
Mike Gagnon
Messages postés381Date d'inscriptionvendredi 15 octobre 2004StatutMembreDernière intervention24 octobre 20132 30 août 2005 à 12:52
Fonch001
n'utilise jamais le "data environnement" qui garde en mémoire un chemin
absolu,
Drole d'observation. Je ne suis jamais empecher de mettre des tables dans le dataenviroment d'un formulaire pour cette raison. En sachant cette information, on n'a qu'a programmer en consequence.
fonch001
Messages postés10Date d'inscriptionjeudi 25 août 2005StatutMembreDernière intervention16 septembre 2005 30 août 2005 à 13:51
mike,
bonjour tout d'abord.
Drole d'observation
Peut-être mais c'est pourtant le cas (au moins en VFP 6 et 7)
En sachant cette information, on n'a qu'a programmer en consequence.
C'est l'essence même de mon post ???? Pour programmer en conséquence, encore faut-il avoir cette information....
Pour en remettre une couche : je trouve idiot en dangeureux d'utiliser le dataenvironnement vu qu'il conserve le chemin absolu de la table. Exemple vécu : tu mets 2 bases (et 2 applis) sur la même machine et tu te retrouves à avoir 2 applis qui pointent sur la même base (super de devoir retoucher 100 ou 150 forms pour corriger cela! et imagine si tu en oublies un...). Avec des USE, no problem.
A+
<HR>
"Quand le sage montre la lune, l'idiot regarde le doigt"
Vous n’avez pas trouvé la réponse que vous recherchez ?
Mike Gagnon
Messages postés381Date d'inscriptionvendredi 15 octobre 2004StatutMembreDernière intervention24 octobre 20132 30 août 2005 à 14:28
Bonjour.
Peut-être mais c'est pourtant le cas (au moins en VFP 6 et 7)
Et VFP5 et VFP3.0
En sachant cette information, on n'a qu'a programmer en consequence.
C'est l'essence même de mon post ???? Pour programmer en conséquence, encore faut-il avoir cette information....
Je m'avoir mal expliqué. Normallement je met tourjours les tables dand le DE de mes formulaires, à mon avis il y a beaucoup d'avantage à faire ainsi qu'autrement Il y a de nombreuses methodes qui sont utilisé dans le DE qui s'occupe des tables, que tu évite completement en utilisant ta méthode.
Pour en remettre une couche : je trouve idiot en dangeureux d'utiliser le dataenvironnement vu qu'il conserve le chemin absolu de la table. Exemple vécu : tu mets 2 bases (et 2 applis) sur la même machine et tu te retrouves à avoir 2 applis qui pointent sur la même base (super de devoir retoucher 100 ou 150 forms pour corriger cela! et imagine si tu en oublies un...). Avec des USE, no problem.
Apres 19 ans de programmation en FoxPro, le terme 'idiot' pour valider un mausaive technique de programmation n'est pas nouveau. Les chemins des tables n'est pas 'absolu' comme tu le dit si bien. Si par exemple tu crée un classe formulaire pour tout tes formualires et que tu ajoute use simple methode que remet les chemins 'a la bonne place', alors la tous tes formulaires vont réàgir de la meme façon avec une petite méthode que l'on écrit une fois. Il sans que dans ton exemple il faut forcer les chemins dans chaque formulaires (X 100). Et dans ton example si le client décide d'installé l'application sur le drive 'g', tu fait quoi? Voici une exemple d'un méthode qui remet 'les chemins à la bonne place' en se basant sur le chemin qui est indiqué dans un fichier INI.
* Use to fix the path for a table
* expC1 Name of the cursor we have to modify
* expC2 Alias (if passed will override the default cursor alias)
LPARAMETER tcCursor,tcAlias
LOCAL lcObject
lcObject="ThisForm.DataEnvironment."+tcCursor
WITH &lcObject
SELECT TABLE
* We will locate for record in TABLE.DBF
IF NOT EMPTY(tcAlias) AND TYPE('tcAlias')='C'
* We need to replace the Alias and the CursorSource properties
* because we will override the cursor
SEEK UPPER(ALLTRIM(tcAlias)) ORDER ALIAS
STORE tcAlias TO .Alias
STORE ALLTRIM(NOM) TO .CursorSource
ELSE
* If this is a view
IF UPPER(.CursorSource)='VIEW'
LOCAL lcDatabase
lcDatabase=SUBSTR(.Database,RAT('\',.Database)+1)
STORE oApp.cData+'\'+lcDatabase TO .Database
RETURN
ENDIF
LOCAL lcAlias,lnAt
lcAlias=SUBSTR(.CursorSource,RAT('\',.CursorSource)+1)
lnAt=AT('.',lcAlias)
IF lnAt>0
lcAlias=SUBSTR(lcAlias,1,AT('.',lcAlias)-1)
ENDIF
=SEEK(UPPER(lcAlias),'TABLE','ALIAS')
ENDIF
* We will replace the database property for those that are in a DBC
IF NOT EMPTY(DBC)
IF oApp.lMainIni
STORE oApp.cData+'\'+ALLTRIM(DBC)+'.dbc' TO .Database
ELSE
STORE ALLTRIM(DBC)+'.dbc' TO .Database
ENDIF
ELSE
* We will replace the CursorSource property with the full path
* for those not part of a DBC
STORE ALLTRIM(CHEMIN)+'\'+ALLTRIM(NOM)+'.dbf' TO .CursorSource
* If we are in a pick list or in a grid admin
* Because of a bug in Visual FoxPro 5, we are not allowed
* anymore to set the property of Database to blank
* This means we will use a technique to add a cursor here
* in order to have it blank at first
IF ThisForm.Name='recherche'
ThisForm.DataEnvironment.RemoveObject('Cursor1')
ThisForm.DataEnvironment.AddObject('Cursor2','Cursor')
ThisForm.DataEnvironment.Cursor2.CursorSource=ALLTRIM(CHEMIN)+'\'+ALLTRIM(NOM)+'.dbf'
ThisForm.DataEnvironment.Cursor2.Alias=ALLTRIM(NOM)
ThisForm.DataEnvironment.Cursor2.BufferModeOverride=2
ThisForm.DataEnvironment.InitialSelectedAlias=ALLTRIM(NOM)
ENDIF
* We need to remove the database
* .ResetToDefault('Database')
ENDIF
* If we are in adding mode, we have to change the buffering property to optimistic
* to have the possibility to create more than one record at a time for this form
IF TYPE('oApp.nRecnoToProcess')='N' AND oApp.nRecnoToProcess=-1
STORE 5 TO .BufferModeOverride
ENDIF
fonch001
Messages postés10Date d'inscriptionjeudi 25 août 2005StatutMembreDernière intervention16 septembre 2005 30 août 2005 à 14:56
Moi je n'ai que 5 ans de programmation FP (2.6 UNIX) et VFP (6 et 7). Je développe des progiciels et non des logiciels, mon approche est donc légèrement différente.
A la lecture de ton explication, je comprend mieux ton approche du problème et je ne crois pas que l'une ou l'autre méthode soit meilleure (est-il plus vrai qu'une bouteille est à moitié vide ou à moitié pleine? - Pour ma part elle est 2 fois trop grande désolé...).
Pour ce qui est de la "qualitée de ma méthode" (si le client décide d'installé l'application sur le drive 'g', tu fait quoi?) il suffit de mettre
"set path = path() + curdir() && désolé c'est peut-être pas la syntaxe exacte, c'est juste pour la discussion"
au début du programme pour être tranquille (si les tables sont dans ton répertoire d'installation). Pour ma part, je n'ai pas ce problème puisque je fait moi-même les installations (architecture 3 tiers ou émulation distante).
La solution que je proposait donc à JVDH n'est pas la seule solution (quelle surprise!), mais elle a le mérite de fonctionner en faisant un minimum de modifs sur des forms déjà fait (ce qui était mon cas).
A+
<HR>
"Quand le sage montre la lune, l'idiot regarde le doigt"
michelatoutfox
Messages postés828Date d'inscriptionmardi 5 octobre 2004StatutMembreDernière intervention 7 mai 20131 31 août 2005 à 09:03
Allez,
moi aussi j'en rajoute une couche... pour dire mon accord avec Mike
une particularité de Fox (que j'utilise depuis... que c'était DbaseII !), c'est qu'on trouve toujours plusieurs solutions à un problème.
mais il y en a des bonnes, et des mauvaises.
et à mon avis, ne pas utiliser le dataenvironment, c'est une très très mauvaise solution.
Pourquoi? parce qu'on se prive d'une logique OBJET. le DE est un objet, qui est encore amélioré dans VFP9 (avec la classe DE et la classe cursoradapter).
dans une démarche objet, je fourre tout ce qui concerne l'accès aux data dans l'objet qui est fait pour ça. et si je dois absolument coder en dur mes use matablemachin, ce n'est pas dans le load de mes form que je le ferai.
j'utiliserais les méthodes spécifiques du dataenvironment (beforeopentables et opentables, par exemple, avec un autoopentables à F) dans une classe DE, et j'utiliserai cette classe dans ma classe de form, etc...
le minimum de modif aujourdhui peut parfois conduire au maximum d'emm... demain.
et pour demain, (et je pense à Sedna, et à la suite) c'est du coté du dataenvironment et du cursoradapter qu'il faut regarder.
fonch001
Messages postés10Date d'inscriptionjeudi 25 août 2005StatutMembreDernière intervention16 septembre 2005 31 août 2005 à 14:29
Bonjour,
Oui, je comprend et respecte ton point de vue. Tu as raison sur pas mal de points (désolé je ne connait pas bien VFP9).
En revanche tu as tord sur un point : L'utilisation ou non du DE ne caractérise en rien un LOO (sinon où sont les DE en JAVA et C++ ? ). C'est l'utilisation des classes et des héritages qui caractérisent un LOO et je ne voit pas en quoi le fait d'utiliser des USE empêche d'utiliser un max de classes.
A+
<HR>
"Quand le sage montre la lune, l'idiot regarde le doigt"
michelatoutfox
Messages postés828Date d'inscriptionmardi 5 octobre 2004StatutMembreDernière intervention 7 mai 20131 31 août 2005 à 17:39
j'ai du mal m'expliquer, désolé:
quand on utilise un langage centré sur les données, comme l'est VFP, et qu'on a à disposition des classes "dataenvironment" et "cursoradapter", je trouve dommage de ne pas les utiliser...
FredArmoni
Messages postés153Date d'inscriptionvendredi 2 mai 2003StatutModérateurDernière intervention 2 avril 2010 8 sept. 2005 à 09:55
Exemple vécu de l'utilisation de SET PATH :
Copie des tables dans le dossier de l'application par le user qui pensait bien faire...
Fox (c'etait à l'epoque FPD26), dans sa recherche des tables, commence par le set default (qui est logiquement le dossier de l'appli). Je pense que la suite n'a pas besoin d'être dite...
[mailto:frederic.steczycki@mvps.org Fred]
membre actif d'AtoutFox MS MVP VFP