Discussion :

[jdsetls]

Bonjour,
Je désire changer le fichier contenu dans un champ table, facilement, par simple clic sur une combo.

J'ai tout essayé en vain.

Table mémoire = table programmable : génère des erreurs.

Donc comment utiliser la prise en main obligatoire par le gentil membre?

Quelles options choisir?

Quelles instructions utiliser sachant que Fichiers vers tableau génère chez moi des erreurs.

Merci de me donner une vraie réponse testée et non pas une récitation du mode d'emploi.

Merci

Jacques De Schryver

[tatayo]

Bonjour,
Une table mémoire est remplie par programmation, donc c'est TON code qui la remplie.
De fait je ne vois pas trop ce qui t'empêche d'en changer le contenu en fonction de ta combo.

Pour les tables fichier, je connais bien la réponse, mais comme elle est dans l'aide en ligne qu'il ne faut pas citer, je ne vois pas trop comment faire ...

Tatayo.

P.S. Pour les erreurs que tu as, désolé ma boule de Crystal n'a plus de piles.

[jdsetls]

Je ne vois pas pourquoi je ferais une boucle de 8000 tours alors que je souhaite réaliser cela en une seule instruction.


Pour ce que tu ne veux pas dire parce que c'est dans l'aide, j'ai précisé que je désire le code d'un exemple. Pas une récitation de ce qu'on peut faire ou ne pas faire, mais que c'est secret, ou interdit, tout çaaaa. Parce que c'est interdit pour les timides.


Bref je remplis une table une fois, très bien. Mais impossible de vider la table, puis de la reremplir avec un autre fichier.


Bref tu n'as pas répondu, mais je sais que tu sais. C'est très bien.

Jacques De Schryver

[tatayo]

Je n'ai pas répondu car tu ne nous donnes pas assez d'éléments pour t'aider.
Le problème est que tu nous dis "j'ai testé quelque chose, mais j'ai des erreurs", sans nous montrer ce que tu as testé, ni nous dire quelques étaient les erreurs.

Je n'ai pas pour habitude de donner du code tout fait, je préfère largement montrer le chemin.
Mais comme on est dimanche, soyons fous: C'est par ici et par là. Attention avant de cliquer, c'est l'aide en ligne, mais il y a des exemples de code...

Malheureusement tout ne peut pas être fait en une seule ligne de code, mais l'aide en ligne explique bien les différentes étapes à suivre, qui ne sont pas très nombreuses.

Tatayo.

[jdsetls]

Le problème se résout très bien avec la version 20, grâce au tableur.
Mais je suis sûr qu'on peut trouver comment contourner la difficulté.
Je veux simplement, dans une table fichier, effacer le contenu et afficher un nouveau fichier.

A chaque fois que je permute un dictionnaire (latin, anglais, culture générale, répertoire) depuis ma fenêtre dictionnaire, je désire que le fichier correspondant soit chargé dans le tableau de la fenêtre vue globale.

[jdsetls]

Bonjour,

Les circonstances de ce qui constitue ici une difficulté sont les suivantes.
- Mon programme Dictionnaires crée dans l'analyse un modèle et un seul. Ce fichier historique, le père et modèle de tous les autres, s'appelle 'Fichier_latin'.
- Ensuite, s'appuyant sur ce modèle, on crée autant de dictionnaires que l'on veut. Ce sont des clones de l'original mais ils n'en portent pas le nom.
- Pour les manipuler, il convient de tromper le système, en lui faisant croire que chaque dictionnaire est l'original. Cette opération s'effectue de façon assez rapide avec l'instruction HChangeNom. Tout fonctionne parfaitement. On peut dés lors créer un nouveau dictionnaire et vérifier qu'il est aussitôt opérationnel. Ainsi, je lis un livre de science-fiction américaine (par exemple Radix, dans sa version originale) et j'ajoute un mot nouveau après l'autre dans le dictionnaire 'Lectures_anglaises'. Je cilque sur le fichier 'Répertoire' et je donne un coup de fil après avoir vérifié le numéro. Puis je tombe sur un concept nouveau, par exemple 'télomérase', j'effectue mes recherches, j'ajoute le mot et je retourne dans le dictionnaire Lecture_anglaises. L'utilisation d'une table récapitulative est une simple commodité dont je pourrais me passer, mais cela me plait comme cela. Une sorte d'exercice de style. Et tant mieux vu les difficultés rencontrées qui instruisent mon expérience.

- Le programme comporte plusieurs fenêtres. Important : pour faire référence à un quelconque élément d'une fenêtre, cela semble une Lapalissade, cette fenêtre doit déjà être ouverte. Cependant, n'oublions pas que chaque fenêtre est ouverte par l'utilisateur et lui seul. On ne peut donc pas présumer. Cela force à tester si la fenêtre est ouverte et dans le cas contraire, à l'ouvrir par programme. Notons en passant que si je n'avais qu'un seul dictionnaire, tout cela serait inutile. La table fichier serait attachée d'origine sans exiger aucune manipulation. L'intérêt de ma question est d'offrir davantage de fluidité. Par exemple en vérifiant la chronologie des entrées grâce à l'identifiant, par nature ordinal. Je peux ainsi vérifier que j'ai d'abord entré 'télomère' puis,beaucoup plus tard, 'télomérase'. Cette comparaison peut induire un esprit critique par rapport à la validité des sources.

Bref, après des manipulations diverses, j'arrive à mes fins à l'aide du code simple suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
  PROCEDURE Change_de_dictionnaire()
HFerme()
HChangeNom(Fichier_Latin, babouin)
//Transfert bers la table dans vue Globale
SELON FenEtat(Latin_vue_globale)
	CAS Inexistant
		OuvreFille(Latin_vue_globale)	
FIN
FichierVersTableMémoire(Latin_vue_globale.Table1 , "Fichier_latin")
//Vers la fiche elle-même dans le pgm Dictionnaire
RAZ(Mon_RAZ)
HLitPremier()
FichierVersEcran()
Quoi() //Donne le nb de fiches présentes et rappelle le nom du dico actif.
Fenêtre_Dictionnaire = "Vous travaillez sur le dictionnaire " + babouin
FenEtat(Fenêtre_Dictionnaire, ActifDevant)

Ceci fonctionne à la perfection sur une table mémoire, c'est à dire gérée par programmation.
On notera que le transfert vers la table lit entièrement le fichier. la fiche active est donc la dernière alors que la fiche affichée est la première. Ceci malgré le contexte hyperfile indépendant, parce que l'ordre est donné depuis la fenêtre dictionnaire. D'où l'importance de l'ordre des instructions.

La question que je pose aux membres du forum est la suivante :

Comment réaliser cela avec une table fichier, qui offre différents avantages que n'a pas la table mémoire.

Bien cordialement,

Jacques De Schryver

Nb : Mes tests sont réalisés dans une ardoise magique, sorte d'atelier de bricolage qui utilise la compilation dynamique pour accélérer les mises au point. Vous remarquerez que ma photo est celle d'un débile, donc modifiée dans Photoshop, pour symboliser qu'à lutter contre certaines difficultés, on finit par s'arracher les cheveux, voire à devenir fou.
Mais on s'enrichit à tester les limites du système. Par exemple, chaque fenêtre étant multi instances, que se passe-t-il lorsque j'ai plusieurs fenêtres dictionnaires ouvertes en même temps ?

[tatayo]

Je trouve cette méthode "un rien compliquée pour pas grand chose".
Je pense que ton problème vient de hChangeRep().
Le contexte HF indépendant permet à plusieurs fenêtre d'avoir un pointeur différent dans un fichier, mais le fichier lui-même est commun à toute l'application.
Bref ta méthode ne peut pas fonctionner.

De mon côté j'aurai fait ainsi:
1. Une table Dictionnaire, avec un Id et un Nom
2. Une Table Mot, avec un Id, le mot (et pourquoi pas un "soundex")
3. Une Table Definition, avec l'Id du mot, l'id du dictionnaire et la définition

La table sera alors basée sur une requête paramétrée, qui récupère l'Id du dictionnaire à afficher.
Ainsi:
1. tu n'as plus besoin de changer le fichier affiché dans la table
2. en passant l'id du dictionnaire en paramètre à ta fenêtre, tu peux afficher autant de dictionnaire que nécessaire en même temps
3. tu peux récupérer toutes les définitions d'un mot
4. Plusieurs mots peuvent avoir la même définition (cas des pluriels par exemple)

En ajourant une colonne "soundex" dans la table mot, tu peux de plus faire une recherche phonétique sur un mot, ou trouver les mots "ressemblant". Pratique quand on a un doute sur l'orthographe d'un mot.

En pour bien faire, tu peux ajouter une table qui lie les mots entre eux, ainsi tu peux ajouter dans une définition des liens vers d'autres définitions.
Et aussi un "type" (nom propre, nom commun, adjectif...) et un genre (masculin, féminin)...

Et cerise sur le gâteau, comme c'est plus simple tu vas garder quelques cheveux .

Tatayo.

[jdsetls]

Je trouve cette méthode "un rien compliquée pour pas grand chose".
Je pense que ton problème vient de hChangeRep().
Le contexte HF indépendant permet à plusieurs fenêtre d'avoir un pointeur différent dans un fichier, mais le fichier lui-même est commun à toute l'application.
Bref ta méthode ne peut pas fonctionner.

De mon côté j'aurai fait ainsi:
1. Une table Dictionnaire, avec un Id et un Nom
2. Une Table Mot, avec un Id, le mot (et pourquoi pas un "soundex")
3. Une Table Definition, avec l'Id du mot, l'id du dictionnaire et la définition

La table sera alors basée sur une requête paramétrée, qui récupère l'Id du dictionnaire à afficher.
Ainsi:
1. tu n'as plus besoin de changer le fichier affiché dans la table
2. en passant l'id du dictionnaire en paramètre à ta fenêtre, tu peux afficher autant de dictionnaire que nécessaire en même temps
3. tu peux récupérer toutes les définitions d'un mot
4. Plusieurs mots peuvent avoir la même définition (cas des pluriels par exemple)

En ajourant une colonne "soundex" dans la table mot, tu peux de plus faire une recherche phonétique sur un mot, ou trouver les mots "ressemblant". Pratique quand on a un doute sur l'orthographe d'un mot.

En pour bien faire, tu peux ajouter une table qui lie les mots entre eux, ainsi tu peux ajouter dans une définition des liens vers d'autres définitions.
Et aussi un "type" (nom propre, nom commun, adjectif...) et un genre (masculin, féminin)...

Et cerise sur le gâteau, comme c'est plus simple tu vas garder quelques cheveux .

Tatayo.

----
Merci Tatayo,

Tu dis : 'Ta méthode ne peut pas fonctionner'.

Or elle fonctionne à la perfection, et je peux t'envoyer le projet complet.

Ce n'est pas HChangeRep, que j'utilise ailleurs pour créer les clones, mais HChangeNom. Le pgm considère que le clone est un original. Bien qu'il ne soit pas déclaré dans l'analyse. A ce niveau, c'est parfait.

Ce qui m'a étonné, ce sont toutes les choses auxquelles je n'ai pas pensé au départ.

- Il faut revenir à la fenêtre dictionnaire, avec FenEtat, puisque la Vue Globale est passée devant.

- Le transfert du fichier vers la table dans la fenêtre Vue Globale agit sur les pointeurs dans Dictionnaire malgré le contexte hyperfile indépendant. Dangereux donc si on n'y prend pas garde car générateur d'erreurs en cas de modification de la fiche affichée à l'écran. Elle écrase la fiche du fichier. Il y a donc un décalage entre l'écran et le fichier, depuis la fenêtre dictionnaire. Et ceci après une action sur la fenêtre Vue Globale. Mais attention, c'est du au fait que l'instruction est donnée depuis la fenêtre Dictionnaire.Cela reste logique.

- Certaines instructions telles que Ouvre posaient problème parce que j'aurais dû écrire OuvreFille

Je me suis pas mal bagarré avec tout ça.

Dans une certaine mesure je suis satisfait au final, mais cela m'a perturbé de voir que j'avais du mal à penser à tout.

Mais depuis que je reprogramme, j'ai un peu amélioré mon niveau aux échecs sur chess.com

En tout cas j'aime bien ce forum, car même si on s'envoie des vannes, cela dynamise les recherches. J'y suis depuis quatre heures trente ce matin.

Cordialement à tous,

Jacques De Schryver

NB : Ma principale erreur a été de croire que la fenêtre Latin_Vue_Globale était fille, alors qu'il s'agissait d'une fenêtre libre (corrigé depuis).
Ensuite j'ai voulu utiliser FichierVersTableau alors qu'il fallait choisir FichierVersTableMémoire. Je pense qu'à ce niveau le mode d'emploi est insuffisant.

[tatayo]

Le problème avec hChangeRep est que si tu ouvre 2 fenêtres qui chacune change le répertoire du fichier, le fichier manipulé dans TOUTE l'application sera celui définit par la deuxième fenêtre.
Si en plus le hChangeRep est fait dans l'ouverture de la fenêtre, tu peux avoir le cas suivant:
J'ouvre ma fenêtre principale, et de là j'ouvre la fenêtre dictionnaire avec le dico 1.
Puis j'ouvre de nouveau la fenêtre dictionnaire, avec le dico 2.
Maintenant le dico manipulé est le 2, y compris dans la première fenêtre dico...

Bref il faut penser à changer le répertoire à chaque lecture du dictionnaire. C'est une source de bug en puissance !

Tatayo.

[jdsetls]

Bonjour,

Je viens de vérifier car je suis conscient du problème.

Je charge simultanément une fenêtre dictionnaire avec le fichier Latin, et une autre avec le fichier Répertoire.

Les deux fenetres et les deux fichiers sont actifs simultanément.

Dans la première fenêtre, Dictionnaire, Latin, j'ajoute une fiche 'Ajout Latin'. Contenu de la définition 'XXXXXXX'. J'enregistre. Je modifie alors la fiche active dans Dictionnaire Répertoire.'
Dans la seconde fenêtre, Dictionnaire Répertoire, j'ajoute une fiche 'Ajout Répertoire'. Contenu de la définition 'yyyyyyyy'. Je modifie alors la fiche active dans Latin.

J'effectue alors mes vérifications.
Je joue, je permute, j'expérimente.

Aucune influence d'une fiche d'un dictionnaire sur aucune fiche de l'autre dictionnaire.

Les deux fichiers sont bien gérés de façon indépendante. En toute sécurité.

Aucune influence de l'un sur l'autre.

Conclusion, le contexte hyperfile indépendant est bien géré par Windev et PCSoft.

Merci d'avoir attiré mon attention,

Jacques De Schryver

nb : Mes dictionnaires portent leur nom normal : CultureG, Latin, Répertoire, Anglais, etc.

L'usage de Fichier_Latin est là uniquement pour faire croire au système qu'il gère un original. Au départ le système refusait les fichiers non définis dans l'analyse. Maintenant il les accepte. Je crée les nouveaux dictionnaires dans un répertoire vide prévu à cet effet et maintenu vide après usage. Je crée mes dictionnaires avec HCréeSiInexistant. Ils portent tous alors de façon momentanée (naisle nom de Fichier_Latin. Je les rebaptise aussitôt, puis les rapatrie dans le répertoire base de données. De là il sont gérés grâce à HChangeNom. La variable Babouin porte le nom du fichier sélectionné dans la combo de choix.

[frenchsting]

J'ai lu en diagonale le sujet alors désolé si je suis en dehors de la plaque.

Question : un construitTableFichier() ne pourrait-il pas aller ?

A partir d'une table (cachée) avec une colonne.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
hchangerep("*",CheminDicoLatin)
champClone(table_AvecUnecolonne,"Table_Latin")
ConstruitTableFichier("Table_Latin",Dico_Latin)
FichierVersTableMémoire("Table_Latin",Dico_Latin)

En rajoutant une pincée d'indirections, je pense que ce sera encore plus joli.

[jdsetls]

J'ai lu en diagonale le sujet alors désolé si je suis en dehors de la plaque.

Question : un construitTableFichier() ne pourrait-il pas aller ?

A partir d'une table (cachée) avec une colonne.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
hchangerep("*",CheminDicoLatin)
champClone(table_AvecUnecolonne,"Table_Latin")
ConstruitTableFichier("Table_Latin",Dico_Latin)
FichierVersTableMémoire("Table_Latin",Dico_Latin)

En rajoutant une pincée d'indirections, je pense que ce sera encore plus joli.

Bonjour,

J'ai envisagé la construction et la destruction. Je vais donc essayer pour voir.

Mais je n'arrivais pas à accepter qu'on ne puisse pas faire cela directement avec une seulte table fichier. Dont les avantages sont de pouvoir modifier rapidement et en direct les éventuelles coquilles dues à une frappe trop rapide.

Actuellement, mon programme couteau suisse, sept en un, je l'utilise tous les jours, y compris pour écouter de la musique.

Merci pour l'idée. Elle ajoute une alternative fonctionnelle.

Jacques De Schryver





Actuellement, tout fonctionne à la perfection mais, précisément, et merci à toi, ce forum est un apporteur d'idées.

[R&B]

Bonjour Jacques.


Si je ne me trompe (je n'ai pas pris le temps de lire en détail désolé) tu souhaites une table fichier mais dont le contexte HF change de source selon ton besoin.
De surcroit la structure des tous les fichiers est la même ("Mon programme Dictionnaires crée dans l'analyse un modèle et un seul. Ce fichier historique, le père et modèle de tous les autres, s'appelle 'Fichier_latin'")

Je ne vois qu'une solution très simple : changer le fichier de parcours et le brancher sur l'alias en cours.

C'est Noël, comme la sortie de la version 20 nous le rappelle, alors voici une proposition...

1 - Changement de l'alias
Crée une source de donnée... et s'il ne s'agit pas du fichier par défaut, utiliser HDeclareExterne sur le fichier physique pour y faire pointer ladite source de données.

2 - Table fichier (création)
A la création de la fenêtre, créer la table fichier branchée sur le fichier logique par défaut qui devrait arriver sur "Fichier_latin" qui est normalement la matérialisation de la description dans l'analyse et non un alias. Sinon utiliser la description du fichier de l'analyse et passer à la suite.

3 - Table fichier (branchement)
Si on utilisa un alias (fichier de même structure donc), on va brancher le fichier parcouru par la table sur la source de donnée et hop !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
// affecte la source au bon fichier
HAnnuledeclaration(sdFichier)
HDéclareExterne(sdFichier,répertoire+combo+".fic")
 
// Optionnel : reconstruction des liaisons
TABLE..FichierParcouru = ""
Colonne..LiaisonFichier = sdfichier..nom+".Cle"+tab+"Fichierlié.Clé:Rubrique"
 
// changement de contexte de la table (combo de sélection du fichier)
TABLE..FichierParcouru = sdfichier
 
// c'est fini

Evidemment je suis allé à l'essentiel, il faut traiter les valeurs de retours, les erreurs etc mais le principal est là.

Pour information :
- Le changement de fichier parcouru assure le réaffichage des informations, il faut alors avoir modifier la description des relation pour les colonnes sur des fichiers liés avant de procéder à ce changement (propriété ..LiaisonFichier).
- Lors du changement de contexte fichier, WinDev assure le lien par homonymie et comme les fichiers sont des alias, WinDev retrouve les même noms de rubriques pour associer aux colonnes... C'est là que réside sa puissance !

[jdsetls]

Il me semble que c'est parfait, parce que particulièrement simple.

PCSoft devrait utiliser des talents de concision pour réécrire ou améliorer ses modes d'emploi.

Merci, Je vais essayer sur une nouvelle fenêtre.

Joyeux Noël et bonne année 2015,

Jacques De Schryver