Sujet: Base b4.051 en test avec V567

[DDdeBerdeux]

Bonsoir,

Vous allez dire que je me répète, mais cette fois ci, j'espère que ce sera la bonne.

Le fichier de mise à jour est à télécharger ICI et la base vide accompagnée de la liste complète des modifications LA .

Philippe on a bien travaillé pour résoudre les problèmes de transfert des coordonnées lors du choix d'un lieu dans la fiche de saisie rapide. Quand la case à droite est décochée, la sélection du lieu se fait dans la liste des lieux favoris. La sélection d'une ligne dans cette liste, copie tous les paramètres qui s'y trouvent (ville, dept, region,pays, cp, insee, subdivision et coordonnées) dans l'évènement naissance ou décès.

Quand la case est cochée, on peut soit choisir une ville dans l'index des villes , soit taper directement le nom d'une ville.

Dans le premier cas les mêmes paramètres que ci-dessus (sauf subdivision qui reste vierge) sont copiés dans l'évènement.

Dans le deuxième, seul le nom de la ville est copié.

Les erreurs qui provoquaient des doublons dans les lieux favoris ont disparues.

Depuis la liste des lieux favoris, on peut maintenant avoir la liste des individus ayant un évènement (ou adresse) dans le couple ville-subdivision.

La fonction de transfert de dossiers que j'ai développé dans Mutancestre a été intégrée dans le menu importation. Bien que ce soit involontaire, il reste encore un petit plus à Mutancestre (développé avec Lazarus, logiciel open source ) sur sa version intégrée à Ancestrologie. Une sombre histoire de composant Delphi, ne permet pas d'importer un dossier de la même base. On a choisi de l'intégrer malgrés ce petit inconvénient.

Le point vert sur l'onglet "Unions", ne paraît que s'il y a des évènements familiaux.

En résumé, comment se servir de ces nouvelles versions?

La procédure de mise à jour complète les évènements et adresses avec les coordonnées (latitude et longitude) qui figurent dans la table de référence, dans la mesure où les noms de ville, CP et code INSEE sont identiques à ceux de cette table.

Si vous faîtes ultérieurement une importation depuis un fichier qui n'a pas ces coordonnées, la fonction "Mise à jour des coordonnées géographiques" du menu Lieux permet de faire cette même mise à jour, si la subdivsion est vide.

Comme je suis de ceux qui ont utilisé le champ "Lieu" à la place du champ "Subdivision" dans les évènements, j'utilise la fonction "Mise à jour des coordonnées géographiques" avec l'option "Avec transfert subdivision". Celà transfère le contenu de Lieu dans Subdivision, si Subdivision est vide.

Dans les lieux favoris, je peux alors constater les dégats, principalement dus à des variations dans l'écriture de Subdivision.

A l'aide de la vue satellite, on peut affiner les coordonnées du lieu (l'appel de mapquest depuis geonames permet d'obtenir les coordonnées en degrés décimaux), et mettre à jour les lieux, nom de subdivision et coordonnées, par la fonction "Modifier ce lieu favori.." depuis les lieux favoris.

Merci d'avance aux testeurs.

André

[Pierre Garnier]

Merci d'abord pour la clarté de l'exposé 19,5/20

Merci pour le gestion améliorée des lieux et sudivision.

Seul Pb avec cette version. J'ouvre Ancestrologie et sans rien faire je veux changer de base -> emplacement de la base



==> Violation d'accès à l'adresse 00534234 dans le .... Lecture de l'adresse OBCD81F8.



Cela répété plusieurs fois avec toujours les mêmes adresses. Retour à la 565 pas de problème.

[JiPSchiff]

v567: même punition.

[Facon]

Bonsoir André,

Même motif, même punition.

J'ai migré la base de test en b4.051 et j'ai mis en place v567.

J'ai commencé quelques tests selon mon principe repris maintenant moult fois, à partir d'un dossier vide puis je remplis avec ma généalogie (le début depuis moi) avec quelques modifications exotiques pour aménager quelques difficultés.



Fenêtre principale

Saisie de N, P, S, DN, LN depuis la loupe: Ok



Ajout d'un conjoint

Saisie de N, P, DN, LN depuis la loupe: Ok



Ajout d'un enfant n°1

Saisie de P, S, DN, LN depuis la loupe: Ok hormis l'affichage de l'enfant qui ne vient pas instantanément, il faut par exemple permuter les parents. Ce n'est pas réellement nouveau.



Ajout d'un enfant n°2

Saisie de P, S, DN, LN depuis le menu: Ok



Ajout d'un enfant n°3

Saisie de P, S, DN, LN depuis le menu: Ok



Ajout d'un père

Saisie de P, DN, LN, DD, LD depuis le menu: Toujours le problème d'affichage des nom et prénoms dans la fenêtre principale. C'est à corriger. Même chose pour les dates mais tolérables.



Ajout d'une mère

Saisie de N, P, DN, LN (depuis la loupe), DD, LD depuis le menu: Même commentaire que ci-dessus.



Ajout d'un enfant n°4

Saisie P, S, DN, LN depuis la loupe. Pour ce dernier lieu, j'ai retenu Dunkerque 59140, à la création, l'individu est affecté de Dunkerque 59240 (précédemment utilisé).



Ajout d'un enfant n°5

Comme ci-dessus mais en retenant via la loupe et l'index des lieux Dunkerque 59640, à la création, l'individu est affecté de Dunkerque 59240 (précédemment utilisé.



Saisie rapide - Utilisation de la case cochée

Pour créer en rapide un lieu+subdivision, j'ai saisis Lille Saint-Etienne.

J'ai ajouté quelques individus, .... à la fin j'ai voulu mettre en ordre ce lieu via l'index des lieux/lieux favoris. Dans la demi fenêtre inférieure, à l'aide de la loupe je sélectionne Lille, en subdivision j'ajoute Saint-Etienne et, impossibilité de modifier le lieu. Ceci avait déjà été notifié avec v565.



A suivre

[Pierre Garnier]

FACON c'est la saisie moi c'est les lieux!

Anomalie.

Si dans l'onglet lieu je choisi "Liste des villes en doublon dans la base"

j'obtiens comme doublon la ville de Prémillieu dans l'Ain or dans la base ouverte je n'ai qu'un dossier qui ne possède pas cette ville dans les villes favorites. Mais j'ai Prémillieu dans une autre base.

Conclusion ne rechercherait'il pas les doublons dans plusieurs bases et pas seulement dans celle qui est ouverte? (Je pense que cela existait avant la 567)

[DDdeBerdeux]

J'ouvre Ancestrologie et sans rien faire je veux changer de base -> emplacement de la base



==> Violation d'accès à l'adresse 00534234 dans le .... Lecture de l'adresse OBCD81F8.

Avec cette version, il faut absolument réinitialiser les menus et les fenêtres et redémarrer ancestro après celà.

A+

André

[DDdeBerdeux]

Conclusion ne rechercherait'il pas les doublons dans plusieurs bases et pas seulement dans celle qui est ouverte? (Je pense que cela existait avant la 567)

Effectivement rien n'a étét touché dans cette fonction. La recherche des doublons se fait dans la table de référence et non dans les lieux utilisés dans l'un ou l'autre dossier. Et il est normal d'avoir des doublons pour des villes qui ont plusieurs codes postaux par exemple.

A+

André

[Facon]

Bonsoir,

Dans mon dernier message je disais:



Saisie rapide - Utilisation de la case cochée

Pour créer en rapide un lieu+subdivision, j'ai saisis Lille Saint-Etienne (après avoir coché la case).

J'ai ajouté quelques individus, .... à la fin j'ai voulu mettre en ordre ce lieu via l'index des lieux/lieux favoris. Dans la demi fenêtre inférieure, à l'aide de la loupe je sélectionne Lille, en subdivision j'ajoute Saint-Etienne et, impossibilité de modifier le lieu. Ceci avait déjà été notifié avec v565.



Je contaste par ailleurs que les indications apportées à la 1/2 fenêtre inférieure lors de l'utilisation de la loupe n'intégrent pas la latitude et la longitude.

Le message d'erreur retourné est: " n'est pas une valeur en virgule flottante correcte.

Je ne vois pas comment un lieu défini par la ville seule (même si elle est créée) pourrait être modifié puisqu'il n'existe pas l'option de modification sur la ville seule. Cette remarque a déjà été faite pour la version v565.



Dans les lieux favoris, il existe bien la possibilité de retrouver les personnes ayant eu un événement sur ville ou ville+subdivision.



Faut-il poursuivre les tests, notamment avec les nouvelles fonctionnalités?

[Pierre Garnier]

Conclusion ne rechercherait'il pas les doublons dans plusieurs bases et pas seulement dans celle qui est ouverte? (Je pense que cela existait avant la 567)

Effectivement rien n'a étét touché dans cette fonction. La recherche des doublons se fait dans la table de référence et non dans les lieux utilisés dans l'un ou l'autre dossier. Et il est normal d'avoir des doublons pour des villes qui ont plusieurs codes postaux par exemple.

A+

André

OK alors il faudrait dans le menu avoir

"Liste des villes en doublons dans la table de référence" (ce dont on se fiche un peu)

et pas

"Liste des villes en doublons dans la base ..." (ce qui nous interesse!)



Conclusion il faut

- soit changer le libéllé

- soit changer la fonction (ce qui serait mieux, avec encore mieux la possibilité de fusionner les villes en doublons de la base)

[Facon]

Bonsoir André,

Dans les explications tu indiques:



Philippe on a bien travaillé pour résoudre les problèmes de transfert des coordonnées lors du choix d'un lieu dans la fiche de saisie rapide. Quand la case à droite est décochée, la sélection du lieu se fait dans la liste des lieux favoris. La sélection d'une ligne dans cette liste, copie tous les paramètres qui s'y trouvent (ville, dept, region,pays, cp, insee, subdivision et coordonnées) dans l'évènement naissance ou décès.

Quand la case est cochée, on peut soit choisir une ville dans l'index des villes , soit taper directement le nom d'une ville.



Dans le cas d'une case cochée, j'étais resté à l'idée que c'était pour créer une ville inexistante dans la table de référence ou pour créer une ville existante (à rectifier ensuite) afin de ne pas devoir repasser par la fenêtre principale.

J'ai coché et utilisé la loupe, mais le résultat reste le même quant à la fidélité du CP d'un lieu lorsque ce lieu dispose de plusieurs CP. Ce point est à rectifier.

Si ce n'est pas coché, où se fait la sélection d'un lieu au travers de la loupe? Dans l'index des lieux je suppose.

Je finis par me demander si la gestion de la subdivision au niveau de la fiche de saisie rapide n'apporte pas trop de difficultés.



Fiche de saisie rapide ouverte depuis le bandeau supérieur.

Rien de changé depuis v55?, après renseignement, l'action "Enregistrer" ne conduit pas vers la fenêtre principale pour montrer l'individu créé.

[Pierre Garnier]

J'ouvre Ancestrologie et sans rien faire je veux changer de base -> emplacement de la base



==> Violation d'accès à l'adresse 00534234 dans le .... Lecture de l'adresse OBCD81F8.

Avec cette version, il faut absolument réinitialiser les menus et les fenêtres et redémarrer ancestro après celà.

A+

André

C'est pourtant ce que j'avais fait.

Alors j'ai relancé Ancestrologie et pas de Pb je peux changer de base

Je veux à nouveau rechanger de base . Pb de violation

Je sors et relance Ancestrologie . Pb de violation.

Je ne comprends plus mais il semble malgré tout y avoir un pb.

[Ancestrologie]

essaie de downloader a nouveau ancestro, peut etre ca c est pas bien passé

[DDdeBerdeux]

Saisie P, S, DN, LN depuis la loupe. Pour ce dernier lieu, j'ai retenu Dunkerque 59140, à la création, l'individu est affecté de Dunkerque 59240 (précédemment utilisé).

C'est exact, quand une ville est choisie dans l'index des villes, les propriétés issues de cette table ne sont prisent que si la même ville n'existe pas dans les lieux favoris. Sinon, ce sont celles de cette dernière.

Lorsque tu dis dans ton dernier message "impossibilité de modifier le lieu", je pense que c'est à cause de l'erreur de conversion de la chaîne vide en nombre à virgule flottante? Cette erreur est justement due à l'absence des coordonnées de la ville. Si tu tapes les coordonnées, tu ne devrais pas avoir cette erreur.

Il y a donc 2 erreurs à corriger dans cette fenêtre de modification:

-prévoir des latitudes et longitudes inexistantes

-copier les latitude et longitude de l'index des villes.

Et dans la saisie rapide utiliser toutes les propriétés venant de l'index des villes, même si cette ville existe dans les favoris.

Philippe est en train de corriger çà.

A+

André

[Ancestrologie]

Rien de changé depuis v55?, après renseignement, l'action "Enregistrer" ne conduit pas vers la fenêtre principale pour montrer l'individu créé.

Normal, c est pas prévu comme ca



Imagine que tu veuilles saisir 50 fiches par la saisie rapide, et qu a chacune ca ferme pour ouvrir l index, tu va trouver ca fatigant



donc la saisie rapide a été faite dans le but de saisir plusieurs individus  a la suite, mais depuis elle a été détourné de sa fonction primaire

[DDdeBerdeux]

Je veux à nouveau rechanger de base . Pb de violation

C'est un problème récurrent, qui doit venir de la mise à jour de paramètres dans la BDR. J'ai constaté que lorsque "tout partait en quenouille" comme celà, il fallait changer le nom de la base depuis l'explorateur. A démarrage suivant, resélectionner la base sous son nouveau nom et tout repart correctement.

A+

André

[Facon]

Bonsoir André,

Saisie P, S, DN, LN depuis la loupe. Pour ce dernier lieu, j'ai retenu Dunkerque 59140, à la création, l'individu est affecté de Dunkerque 59240 (précédemment utilisé).

C'est exact, quand une ville est choisie dans l'index des villes, les propriétés issues de cette table ne sont prisent que si la même ville n'existe pas dans les lieux favoris. Sinon, ce sont celles de cette dernière.

Selon ton explication il ne semble pas possible de choisir une ville avec un CP différent dès l'instant où cette ville (avec un autre CP) a déjà été retenue et ainsi incluse dans les lieux favoris.

La loupe est donc "one shot" pour une ville indépendamment du CP.

De mon côté, j'ai tendance à penser qu'une ville avec un CP différent est une autre ville, sinon pourquoi la mettre dans la table de référence?

[Facon]

Bonsoir Philippe,

Rien de changé depuis v55?, après renseignement, l'action "Enregistrer" ne conduit pas vers la fenêtre principale pour montrer l'individu créé.

Normal, c est pas prévu comme ca



Imagine que tu veuilles saisir 50 fiches par la saisie rapide, et qu a chacune ca ferme pour ouvrir l index, tu va trouver ca fatigant



donc la saisie rapide a été faite dans le but de saisir plusieurs individus  a la suite, mais depuis elle a été détourné de sa fonction primaire

Je fonctionnais un peu machinalement. J'ai vérifié, tu as raison. Je retire mon commentaire.

[Facon]

Bonsoir André

Je veux à nouveau rechanger de base . Pb de violation

C'est un problème récurrent, qui doit venir de la mise à jour de paramètres dans la BDR. J'ai constaté que lorsque "tout partait en quenouille" comme celà, il fallait changer le nom de la base depuis l'explorateur. A démarrage suivant, resélectionner la base sous son nouveau nom et tout repart correctement.

A+

André

Je me suis amusé à essayer d'ouvrir plusieurs autres bases, je n'ai pas eu de message comparable à celui de garnierpierre.

J'ai eu des avertissements m'indiquant que des champs étaient absents, que la base était obsolète et enfin je ne suis plus parvenu à ouvrir la base de test, le message m'indiquait toujours que la base 4.013 ne pouvait pas être utilisée.

Pour avoir la paix, j'ai créé un répertoire Temp dans database, j'ai viré toutes les bases dans ce répertoire. A l'ouverture, Ancestrologie était orphelin et cherchait un bidule à ouvrir, je lui ai offert ma base de test, tout est ok.

Pratiquement, il serait plus utile d'avoir un message indiquant que la base sonnom.bdd est obsolète de manière à la retrouver plus facilement.

[Facon]

Bonsoir André

Saisie P, S, DN, LN depuis la loupe. Pour ce dernier lieu, j'ai retenu Dunkerque 59140, à la création, l'individu est affecté de Dunkerque 59240 (précédemment utilisé).

C'est exact, quand une ville est choisie dans l'index des villes, les propriétés issues de cette table ne sont prisent que si la même ville n'existe pas dans les lieux favoris. Sinon, ce sont celles de cette dernière.

Lorsque tu dis dans ton dernier message "impossibilité de modifier le lieu", je pense que c'est à cause de l'erreur de conversion de la chaîne vide en nombre à virgule flottante? Cette erreur est justement due à l'absence des coordonnées de la ville. Si tu tapes les coordonnées, tu ne devrais pas avoir cette erreur.

Il y a donc 2 erreurs à corriger dans cette fenêtre de modification:

-prévoir des latitudes et longitudes inexistantes

-copier les latitude et longitude de l'index des villes.

Et dans la saisie rapide utiliser toutes les propriétés venant de l'index des villes, même si cette ville existe dans les favoris.

Philippe est en train de corriger çà.

A+

André

A l'occasion d'une tentative de modification, j'ai renseigné manuellement latitude et longitude, je n'ai plus de message d'erreur mais la modification ne se fait pas. Je rappelle que dans le cas d'une ville créée rapidement dans la fiche de saisie rapide (case cochée), seule la fenêtre ville est renseignée. Les trois boutons de modification réclament ville+quelquechose. Dans le cas présent, seul la Ville est renseignée.

[DDdeBerdeux]

Dans le cas d'une case cochée, j'étais resté à l'idée que c'était pour créer une ville inexistante dans la table de référence ou pour créer une ville existante (à rectifier ensuite) afin de ne pas devoir repasser par la fenêtre principale.

C'est bien comme je l'ai écrit précédemment  au bug près concernant la non prise en compte des propriétés de la ville choisie dans l'index des villes.

La case à cocher ne permet que de choisir le champ qui sera utilisé pour la saisie.

Il y a en réalité 2 champs superposés que la case à cocher permet de rendre actifs et inactifs

Décochée c'est une liste déroulante contenant la liste des lieux favoris qui est active.

Cochée c'est un champ de saisie plus "normal".

La liste déroulante ne permet que de choisir un lieu de cette liste.

Le champ normal permet de saisir un nom de ville quelconque si on le tape, ou un nom venant de l'index des lieux (qui est la table de référence). Philippe corrige le bug pour que lors de ce dernier choix, toutes les propriétés venant de l'index des lieux (et non des favoris) soient prisent.

A+

André