Nouvel AU SECOURS KLAUS !!!

Je suis entrain d' adapter ( enfin d'essayer d'adapter ) un de mes programme avec BDR
J'ai réussi à adapter BDR_SUB avec l'importation de BDR.dll dans KGF.dll ( gestion de plusieurs dlls)
ce fut long mais pas très compliqué.
Là, je cherche à avoir plusieurs "picture button" seulement quand je survol le deuxième, c'est le premier qui passe
en mode in ...

bref je te donne le lien

NPP.zip

Le form des boutons : "Listes\Chevaux"

Déclaration des boutons dans le *.bas (lignes 181 et 182)
Procédure des boutons dans le *.bas (lignes 428 à 449)

BDR_SUB modifié dans le *.bas ( lignes 737 à 1265 )

(le fichier *.bas est "compilé" avec les librairies pour qu'il n'y en est qu'un car je travail avec des includes )

Je regarde...

Merci Klaus...

Le pire, c'est que c'est la même procédure qui fonctionnait dans "Traducteur Franco Martien"

Même appel, même procédure mais un résultat bizarre...

Va comprendre Charles...

j'ai viré kgf.dll , fait un copier/coller de kgf.dll depuis "Traducteur Franco Martien"
d'où j'avais pris la première fois kgf.dll et....

...CA MARCHE !!!

Une histoire de

Une petite curiosité...

Mettez la case sélectionnée du grid en blanc si elle est bleu.
Survolez un des "Button_Picture" le + ou le - en observant le grid...

lien :NPP.zip

Donc, c'était un problème de version ! C'est ce que j'aurais dû contrôler immédiatement, au lieu de plonger dans le source...

La coleur bleu qui réapparaît, cela me paraît normal. Bleu est la couleur de la cellule sélectionnée dans un GRID. Dès qu'on positionne le curseur dans le grid, par un clic ou tout autre moyen, la cellule dans laquelle se trouvera le curseur alors deviendra la nouvelle cellule sélectionnée. Seulement, comme le curseur est dedans, elle reste en blanc, avec un petit cadre pointillé autour, signe de la sélection. Dès que le curseur quitte le grid (et il suffit de faire une tabulation pour cela), la cellule sélectionnée reste bien sélectionnée, mais n'est plus la cellule active, et elle reprend donc la couleur bleue, couleur de cellule sélectionnée non active.

Ok Klaus,

Je vais faire le ménage dans les kgf.dll qui se promènent dans mon ordi....
En fait, comme j'essaye que chaque programme soit autonome et transportable,
chaque dossier qui le nécessite a sa kgf.dll mais elles ne sont pas toutes de la même
version et là, çà fait des noeuds...

Pour le coup du grid je trouvais çà plus rigolo que gênant.

Par contre, je m'appercois que ma "sub" pour le bouton picture est pas au point.
Si on a des boutons sur des containers différent, le "clicksethook" ne se déclenche pas sur
les containers suivants le premier.
Pour éviter d'en avoir plusieurs sur le même container, j'avais mis une varible "survey"%
mais une fois initialisée à 1, elle empêche un autre "clicksethook" même si le bouton est sur un autre container...

J'ai vu cette variable. J'avais mis la ligne en commentaire (celle qui met cette variable à 1). Bien sûr, dans ce cas, la function ClickSetHook est exécutée chaque fois. Mais ce n'est pas grave: elle vérifie tout d'abord que ce couple des deux handles est déjà mémorisé. Si tel est le cas, elle retourne immédiatement, sans rien faire, hormis une action essentielle: garder dans une variable interne à la DLL un pointeur vers l'objet à surveiller (dans ton cas, un container). Cette variable est ensuite utilisé par tous les ClickSetLink successifs, jusqu'à ce qu'un ClickSetHook suivant la change pour pointer vers un autre objet.

Ok Klaus,

Je vais faire sauter le if...end_if.
J' avais peur que la répétition de "clicksethook" créée un bug.
Puisque tu me dis que non....je vais donc éliminer ma "survey"

Pour moi, ce sera bon comme ça.

Je confirme, pas de bug à l'horizon...

J'ai presque fini mon interface utilisateur, je vais pas tarder à commencer la partie BDR
mais çà, c'est une autre paire de manches...

Bravo !

D'après ce que j'ai pu voir, c'est prometteur !

Promettre, çà promet...
Est ce que cela tiendra ses promesses, c'est autre chose...

Une chose est certaine, avec BDR, tu n'as pas finis de m'avoir sur le dos
et moi j'ai déjà refait mon stock, je l'ai même doublé, de doliprane .

Pour commencer, et ce n'est qu'un début.
Ma base si elle était de type "csv" ressemblerait à çà :

Cheval; Lad; Site; w du 01/01/20xx; w du 02/01/20xx; ... ...; w du 31/12/20xx

Est ce que je dois déclaré toutes les cases dès le départ ?
( Cheval;"";"";"";"";"";"";....)

Après je vais chercher comment, et... ...tu risques de me revoir...

Non. Il suffit de déclarer les cellules de la manière suivante:
Imaginons qu'ai début, du connaisses la première et la quatrième cellule sur 15 cellules que devrait contenit l'enregistrement. Alors tu déclares:
Cheval;"";"";"xxx"
de sorte que les deux cellules connues soient à la bonne place. Mais tu n'as pas besoin de déclarer les cellules manquantes au-delà de la dernière cellule utilisée. C'est en tout cas ainsi que fonctionnent les objets StringList de KGF.dll.

Mais cela n'a pas de rapport avec BDR ! Lis l'introduction de BDR.chm et regarde le programme de démo pour BDR. Avec BDR, tu as des "entités" qui sont identifiées par un nom (qui est une chaîne de caractères). Ces entités peuvent avoir des "données", et ces données peuvent très bien être des enregistrements du type que tu décris. Dans ce cas, ils pourront être traités par l'objet StringList de KGF.dll.

Ce que BDR apporte, ce sont des liens entre les entités, et des moyens de suivre ces liens, en remontant ou en descendant le sens des flèches (chaque lien a une "direction" !), en regroupant des éléments etc.

Je t'avouerai que je patauge depuis ce matin.
J'ai pris l'exemple du carnet d'adresse qui me semblait le plus simple
mais même là je suis dans le flou.

En fait l'utilisateur n'a pas à créer quoi que ce soit.
il doit pouvoir créer un fiche cheval ou la détruire
il doit pouvoir ajouter ou retirer un lad de la liste
il doit pouvoir ajouter ou retirer un site de la liste

ensuite, il doit pouvoir créer ou modifier le travail d'une journée d'un cheval

toutes les relations doivent être prédéfinis avant

la fiche d'un cheval :

Nom du cheval
Nom du lad
Nom du site de stationnement du cheval

En fait, tant pis, je dois l' avouer, je crois que c'est trop compliqué pour ma petite tête...

Je vais me faire un café en ville, çà va peut être m'éclairer les neurones...

Tout ce que tu cites, peut être considéré de deux manières:
cas 1: chacun de ces éléments pour un cheval représente un champ dans un enregistrement décrivant le cheval
cas 2: pour chacun de ces éléments, tu crées un nom séparé, et tu établis un lien (une relation) entre un cheval et un lad, entre un cheval et un site de stationnement, etc.

Pour le cas 1:
Tu crées une liste dans un simple fichier texte, pour chacun de ces éléments: une liste contenant tous les lads, une liste contenant tous les lieux de stationnement, etc. Ensuite, pour le cheval, tu crées des combo pour permettre la saisie des informations, en chargeant ces combos à partir des fichiers individuels. Et lorsque tu valides la saisie pour le cheval, tu crées un enregistrement, en format CSV par exemple, en mettant comme champs le text$() de chacun de ces combos. Et lorsque tu proposes l'enregistrement d'un cheval en modification, tu charges simplement chaque champ dans les combos, avec la commande TEXT. C'est aussi simple que ça.

Tu auras alors un fichier texte contenant, dans chaque ligne, l'enregistrement "cheval" en format CSV, avec chacun de ses champs. Et KGF.dll contient des fonctions pour traiter ce type d'enregistrement.

Ou alors, il y a une solution plus élégante: tu décides de gérer les zones texte en "longueur constante". Tu détermines donc pour chaque champ texte une longueur maximale. Et tu peux alors utiliser les fonctions de gestion de fichiers binaires de KGF.dll. Ces fonctions te permettent de gérer de façon automatique la constitution d'un tel enregistrement, ainsi que le chargement des variables Panoramic après la lecture d'un tel enregistrement. Tu n'as même plus à t'occuper du formatage des données. Et tu peux même inclure des données binaires comme des entiers et des flottants ! Et ce de façon totalement transparente.

Pour le cas 2:
Tu n'a alors plus qu'un seul fichier: la base de données qui est un fichier avec l'extension *.bdr. Dans cette base, tu crées des entités pour absolument tout: les chevaux, les lads, les lieux de stationnement etc. Ensuite, tu regroupes ces entités par nature: tu auras un "ensemble" de chevaux, un "ensemble" de lads, etc. Les ensembles sont eux-même de simples entités portant un nom. Exemple:
chevaux contient (Furie, Tonnerre_de_Brest, Soleil_du_Levant, ...)
lads contient (Martin, Paul, Géraldine, ...)
lieux contient (box_1, ..., box_17, ...)
etc.
Tu crées ensuite des "relations". Ce sont à nouveau de simples entités portant un nom, mais servant à créer des liens entre deux autres entités. Exemple:
"est_soigné_par" serait la relation pour lier un cheval à un lad
'est_stationné_dans" serait la relation pour lier un cheval à un lieu de stationnement
Tu pourrais alors créer les relations
Furie est_soigné_par Martin
Furie est_stationné_dans box_17
Tonnerre_de_Brest est_soigné_par Géraldine
Tonnerre_de_brest est_stationné_dans box_1
Soleil_du_Levant est_soigné_par Martin
etc

Il y a bien sûr les fonctions de recherche selon les liens des relations. Dans le pseudo_code ci-après, chaque point d'interrogation représente l'élément à trouver:
Furie est_soigné_par ? ==> réponse: Martin
? est_stationné_dans box_1 ==> réponse: Tonnerre_de_Brest
? est soigné par Martin ==> réponse: Furie, Soleil_du_Levant

En plus de ces relations, chaque entité (cheval, lad, etc) peut avoir des données. Ce sont de simples chaînes de caractères optionnelles qui sont mémorisées avec l'entité, et à tout moment, on peut les récupérer, remplacer ou supprimer, sans modifier en quoi que ce soit les entités elles-même ni les relations entre elles. Ces données ne sont absolument pas interprétées par BDR, elles sont juste mémorisées. A toi de décider cue que tu veux mettre dedans: date d'anniversaire, soins particuliers pour un cheval, etc.

Résumé:
Comme tu vois, il y a de multiples manières de créer une application de gestion viable. Tout dépend, d'une part du "feeling", c'est-à-dire de la technique par laquelle on se sent attiré, et ensuite de la souplesse de la maintenance de l'application, une fois qu'elle est réalisée et qu'il ne faut surtout pas perdre les données lors d'une intervention, modification ou extension du logiciel.

Voilà. Est-ce que j'ai réussi à t'embrouiller totalement ? Si oui, prends un café et réfléchis-y calmement, car au fond, ces méthodes de programmation, même si elles sont peut-être nouvelles pour toi, sont nettement moins ardues et complexes que ce que tu as déjà fait avec tes procédures de création d'objets et les boutons image !

@ Klaus,

Merci pour toutes ces complications heu... explications...
Après avoir troqué mes dolipranes pour du valium, je pense que je vais
pouvoir me relancer sur BDR_Sub...

Bon, j'ai pris une décision, une grande décision...
Je vais laisser en stand-by ce projet pour me familiariser avec BDR

Je maitrise (+ ou -) tout ce qui concerne l'interface utilisateur pour faire
quelque chose de sympath mais pas assez BDR pour mélanger le tout
tout de suite sans me faire des noeuds.

Tant pis pour mon impatience à réaliser ce projet, que j'avais déjà
mis en stand-by il y a quelques mois.

C'est une sage décision de vouloir d'abord comprendre et maîtriser les outils !

Voilà où j'en suis de mon décorticage de carnet d'adresse
avec adaptation pour une base Chevaux.

Chevaux.zip

Je vais voir, si il est possible de charger mes combo depuis la base.
sinon je créerai des fichiers liste ( çà je sais le faire ).

Pour charger les combos depuis la base:
- tu crées les entités représentant les lads, les lieux etc, par la fonction Add.
- puis tu crées une entité lads et une entité lieux que tu considères comme un "ensemble" dans le sens mathématique du terme, toujours par la fonction Add.
- Tu ajoutes chaque lad à lads par la fonction SetElement, et la même chose pour les lieux.
- Puis, tu utilises la fonction ListSet pour récupérer en un seul appel, la liste de tous les éléments de lads. Le résultat se trouvera dans un mémo (de préférence non visible, caché par HIDE). Tu n'as plus qu'à copier les lignes dans le combo. Idem pour les lieux.

Simple, non ?

Klaus a dit :

Citation :

Simple,non ?

Si tu le dis, c'est que cela doit l' être...

En tout cas, je vais essayer...

Voilà où je me trouve,

Code:

Sub NewLad()
  Dim_Local s$
  if message_input("Ajouter un lad à la liste","Nom : ","")=1
      BDRstatus()
      if BDRstatus=0 :Exit_sub :message "La BDR n'est pas ouverte":end_if
      s$=message_text$
      if s$="":message "Le nom est obligatoire":exit_sub:end_if
      if variable("Lad$")=0
        dim Lad$
        Lad$="Lads_"
        BDRadd(Lad$,"")
      end_if
      BDRadd(s$,"")
      BDRsetelement(s$,Lad$)
  end_if
End_Sub

Suis je dans la bonne direction ?...

Edit : Cà sent bon cette affaire....mais maintenant, par rapport à "carnet d'adresse" je dois reprendre l'affichage du "list"
car il m'affiche les noms des chevaux mais aussi celui des lads...

heu...je souris maintenant mais j'étais pas fier il y a seulement quelques minutes...

Tu as compris le système pour gérer la création des lads avec ajout dans l'ensemble que tu as appelé "lads_". Pourquoi pas - n'importe quel nom fait l'affaire, à condition de ne l'utiliser que pour ça.

Cependant, je te conseille une légère amélioration. Pour une exécution plus fluide, et pour un code plus lisible, je te conseille de faire une procédure qui ouvre la BDR ou qui la crée vide si elle n'existe pas. Et, juste après l'ouverture, on vérifie si l'entite "lads_" existe, et si elle est absente, on la crée à ce moment. Cette vérification est faite par la fonction BDRfindname:

Code:

dim nom_BDR$ : nom_BDR$ = "MaBDR.dat"
dim nom_lads$ : nom_lads$ = "lads_"
...
sub ouvrir_la_BDR:
  BDRopen(nom_BDR$) : ' ouvre la BDR, et la crée automatiquement si elle n'existe pas
  BDRfindname(nom_lads$)
  if BDRfindname=BDR_ERROR_missing then BDRadd(nom_lads$,"")
' ici, la même chose pour les localisations, etc
end_sub

Tu pourra ainsi simplifier ta procédure de création d'un lad car tu est certain que la BDR existe et est ouverte ET que l'ensemble "lads_" existe.

Puis, tu peux faire des procédures similaires pour les autres types d'informations qui doivent être chargées dans un combo.

Je suis bien d'accord avec toi.

J'ai nommé l'ensemble "Lads_" pour que ce soit parlant et ressemble aux autres ensembles.
Pour l'instant, cela me permet d' identifier les choses plus facilement.

Pour la déclaration, j'ai tout mis dans la même procédure par prudence...
Une façon de ne pas faire des aller retours dans le source si çà plantait...