GestCompte

Je vois que j' ai attisé votre curiosité...

Mais sur quel source êtes vous ? 
Jean claude, tes numéros de lignes sont obsolètes.

Ben... celui du zip sur ton WebDav...

@ Jean Claude,

Cette SUB est le fruit de quelques minutes de réflexion.
Je me base sur ta capture d' écran pour les numéros de ligne pour la réponse.

Jean Claude a écrit:

D'autre part: les lignes 1786 et 1787 font exactement le même boulot que 1784 et 1785 (soit lire 2 fois la même ligne du fichier, pour affecter à v$ 2 fois à la même variable SolseReelAA)

Non, on est dans le cas où on lit le fichier des soldes de l' année
en ouverture et qu' il n' y a pas de fichier témoin d'une modif sur l' année précédente.

1784 : récupère la valeur $ des soldes réels de l' année anterieure ( ou départ )
1785 : transforme cette valeur $ en entier et la place dans la variable SoldeReelAA

1786 : récupère la valeur $ des soldes Banque de l' année anterieure ( ou départ )
1787 : transforme cette valeur $ en entier et la place dans la variable SoldeBankAA

Ces deux variables sont utiles pour avoir des soldes justes en fin d' année sinon, tu pars de 0 en soldes
tous les ans.

Jean Claude a écrit:

La ligne 1796 est à mon avis superflu car elle lit la même ligne du fichier que la ligne 1794.

1794 : récupère le solde de fin en $ pour le solde réel
1796 : récupère le solde de fin en $ pour le solde de banque

C est celles des soldes de fin qui évoluent tout au long de l' année donc les résultats .
Elles te permettent d' afficher les soldes dès l' ouverture.
si elles sont superflu, le reste aussi...

D' autre part :

File_Readln N,V$
lit la ligne courante et place entre "" le curseur à la ligne suivante.

Ok Klaus, on parlera des mêmes lignes.

@ Jean Claude, tu n' es pas sur la dernière version posté.
du coup les lignes n' ont plus le même numéro...

@ Klaus,

J' ai pris la modif que tu as posté plus haut.
Effectivement, c' est plus logique...

J' ai un doute sur le double_click  du TreeView, qu' en penses tu Klaus ?

J' ai fait des ajouts

off_change TVedit% après "if number_change = TVedit%"
On_change TVedit%,change avant le "end_if" correspondant


active 0 
avant les deux "exit_sub" de la sub "INIT_GRIDS()" (L 1349)

@Ygeronimi,

J'ai téléchargé à l'instant (enfin, avant ton message ci-dessus).

Cette fois ça marche mieux, j'ai encore été violé une fois sur 4 ou 5 essais.

Je constate que tu as légèrement modifié la sub INIT_SOLDES() en y ajoutant une ligne (ModifEtat%=0)

Pour file_readln, comme je ne m'en sert pratiquement jamais, je ne savais pas que le pointeur se plaçait à la ligne suivante pour lire dans le fichier.

Bon, j'ai tenté d'aider, mais je crois bien que j'étais un peu à coté de la plaque...      

A+

@ Jean Claude

Ne t' inquiète pas, cela fait deux jours que je suis à côté aussi...
Mais tu peux continuer tes investigations, plus y a d' yeux, plus on a de chance de trouver.

Pour le TreeView, c' est pas çà non plus, 
du moins ce n' est pas mes ajouts qui change quoi que ce soit.

Non, ce n'est pas TreeView qui est en cause. Je soupçonne ISAM.

J'ai trouvé !
Et non, ce n'est pas ISAM. Ce n'est pas la ToolBar non plus. En fait, ce n'est pas KGF.dll du tout, ni ta façon d'utiliser les fonctions de KGF.dll.

C'est un vieux bug de Panoramic, dont on avait déjà parlé dans ce forum à plusieurs reprises.
Tu ne peux pas utiliser des constructions SELECT...CASE...END_SELECT dans des SUBs appelées par des routines évènement.
Même si ta logique est correcte, et en l'occurrence, elle l'est.

J'ai fait des tests exhaustifs, en supprimant la ToolBar, le TreeView remplacépar un objet LIST, et tout le système ISAM. En fait, tout ce qui est KGF.dll. Et ça plante toujours. Et tu peux le provoquer très simplement:
1. lance ton programme
2. clique sur le menu "Fichiers" (ou le bouton correspondant - c'est pareil)
3. double-clique sur 2016 ==> on signale que le fichier est déjà ouvert
4. répète les étapes (2) et (3) 2, 3 ou 4 fois
5. réfais étape (2), puis double-clique sur 2014 ==> violation de mémoire

Mais j'ai trouvé la solution pour contourner ce problème. Je suis reparti du source en provenance du zip de ton WebDav. J'y ai apporté la petite modif signalée ci-dessus. Mais surtout, j'ai créé des routines évènement indépendantes, une pour le menu "Fichiers", l'autre pour le bouton correspondant. Et j'y ai copié les sections de code correspondants de des routines "attrape-tout" (en les adaptant bien sûr), de sorte à avoir un parcours d'exécution parfaitement séparé. Et maintenant, tout marche parfaitement pour ces fonctions-là.

Je place le source modifié dans mon WebDav, dossier Partage. C'est trop gros pour passer dans ce post - j'ai dû ressaisir mon message pour en avoir fait l'essai.

Bon, maintenant, il ne te reste plus qu'à prendre ton courage entre deux mains et séparer toutes ces routines évèmenent, et supprimant surtout tous les SELECT...CASE...END_SELECT dans ces chaînes de traitement.

Bonjour,

Curieux, Jack le 18/11/2013 a écrit:

Le problème des blocs SELECT / END_SELECT imbriqués est résolu.
La correction sera disponible dans la prochaine version.

Ygeronimi, tu vas pouvoir t'y remettre  , maintenant que Klaus t'a ouvert la voie.

A+

Merci à vous deux Klaus et Jean Claude.

Je viens de télécharger le source sur le webdav de Klaus, 
il ne me reste plus qu' à l' étudier de près.

Cette histoire de Select...End_Select me chagrine un peu.
Je pensais le problème résolu moi aussi mais bon, apparemment, 
ce n' est pas le cas.
Il est n' est pas simple de s' en rendre compte quand l' imbrication 
n' est pas au premier niveau.

En tout cas, encore merci à vous deux d' avoir pris sur votre temps
avec un plus pour Klaus qui a trouvé le bug.

Je viens de reprendre le source annoté par Klaus.
Visiblement le problème venait de mon sous-menu TOOLBAR qui comportait un SELECT ...END_SELECT.
J' ai donc supprimer celui ci et je l' ai remplacé ainsi :

Code:

'  FENETRE PRINCIPALE / TOOLBAR
  if number_change = TBedit%
      off_change TBedit%
      NbuttonTB%=val(text$(TBedit%))

      if NbuttonTB%=1
        FENETRE_OPEN_FILE()
        on_change TBedit%,change
        return
      end_if
     
      if NbuttonTB%=2
        FormNouvelleRecette()
        on_change TBedit%,change
        return
      end_if
     
      if NbuttonTB%=3
        FormNouvelleDepense()
        on_change TBedit%,change
        return
      end_if
     
      if NbuttonTB%=4
        SHOW_HISTOGRAMME()
        on_change TBedit%,change
        return
      end_if
     
      if NbuttonTB%=5
        SHOW_HISTOGRAMME_2()
        on_change TBedit%,change
        return
      end_if
     
      on_change TBedit%,change
      return
  end_if

La variable NbuttonTB% est déclaré dans les déclarations comme ses copines.
Et j' ai récupéré ma SUB : FENETRE_OPEN_FILE()
que Klaus avait doublé dans un label pour ses tests.


Je pensais que tout aller rentrer dans l' ordre, le source modifié par Klaus fonctionnant au poil.
Ben NON ! rebelote et dix de der ! Acces Violation !

Je me suis dit que Klaus avait peut-être modifié ma sub sans que je m' en aperçoive.
Que neni ! juste un préfixe sur les noms de variables pour ne pas faire de doublons.

Alors ? serait ce le fait de déclarer cette form dans un label plutôt que dans un sub qui change quelque chose ?...

Ygeronimi

Citation :

En tout cas, encore merci à vous deux d' avoir pris sur votre temps
avec un plus pour Klaus qui a trouvé le bug.

J'ai pris de mon temps parce que le sujet m'intéresse, je n'ai pas d'autre mérite.

Le plus, pour Klaus, ben c'est justifié

Citation :

Je pensais que tout aller rentrer dans l' ordre, le source modifié par Klaus fonctionnant au poil.
Ben NON ! rebelote et dix de der ! Acces Violation !

Il faut prolonger la traque, ça finira bien par aboutir.

A+

J' ai trouvé le coupable !

Aussi incroyable que cela puisse être, si la fenêtre de choix de l' année est déclaré sous une sub elle bug,
si elle est déclaré sous un label elle fonctionne.

D' ici deux minutes le source sera sur mon webdav.
tout est ligne 921 et 922

active la ligne 922 et met en rem la 921 et tu auras droit à de jolis acces violation 
inverse et tout ira bien.

Là, j' avoue que cela me dépasse.

Effectivement, Ygeronimi, il n'y a pas de raison logique pour que la création d'une form dans une SUB agisse différemment d'une form créée dans un sous-programme appelé par GOSUB. Je pense que, lentement, on est en train de pousser Panoramic dans ses limites si j'ose dire, et la gestion des SUBs étant encore relativement récente, il n'est pas interdit de penser qu'il puisse encore y avoir des anomalies.

Ce qui serait bien, ce serait que tu puisses produire un tout petit code, sans KGF.dll mais avec la même logique des appels (donc, avec un menu, mais pas de ToolBar, et dans la form créé, un objet LIST au lieu d'un TreeView), afin de reproduire ce phénomène avec un code que Jack puisse exploiter.

Ben, oui mais non.


Le problème vient quand le form contient le TreeView.
Tous les autres form du programme se comporte normalement.
Et, c' est la première fois que j' ai ce souci et surtout à ce point là.

J' ai laissé les deux possibilités dans le source.
Si Jack veut le charger pour l' étudier, il n' aura qu' à jouer avec les lignes 921 et 922 pour la "ToolBar",
1148 et 1149 pour le "Main_Menu".
Sachant que j' ai mis les deux déclaration de form de la ligne 651 à 701.


Edit : J' ai commencé un formulaire de recherche, et mis à jour mon webdav.

Citation :

Le problème vient quand le form contient le TreeView.

Pas tout à fait d'accord, Ygeronimi. J'avas supprimé totalement les références à KGF.dll (et donc pas de TreeView !), et j'avais remplacé le TreeView par un List. Et pourtant, sur le menu "Fichiers" et le bouton associé, ça ne marche pas. C'est ce qui m'a conduit à trouver la solution que j'ai postée.

Le problème est totalement indépendant de KGF.dll !

@ Klaus,
Ok, je vais essayer de faire un source bis sans le TreeView.

Là, je suis sur les recherches et ils ne me trouvent pas toujours ce que je cherche.

J' ai une petite question.
Je viens de lire la doc de ISAM et j' ai un doute sur la fonction "ReplaceIsamKey".
A chaque fois que je fais une modif dans un enregistrement, il que j' utilise cette fonction ?
Par exemple, si je corrige le montant d' une dépense.

Mon webdav est à jour.

Citation :

A chaque fois que je fais une modif dans un enregistrement, il faut que que j' utilise cette fonction ?

Non? Uniquement lorsque tu changes la valeur d'un champ qui fait partie d'une clé. Dans ce cas, il faut que tu changes aussi la clé, bien sûr.

C' est bien ce que je craignais...


Par contre, je ne comprends pas trop ce qui cloche dans mon système de recherche.
la clef est apparemment bonne dans le message avant l' appel à la dll 
mais je n' ai pas toujours de résultat.

@ Klaus,

Pourrais tu jeter un coup d' oeil à ma fonction de recherche (L 1793 - 1959).
Je ne comprends pas pourquoi elle ne me renvoie le bon résultat, quand elle en renvoie un, quand cela lui chante.

Ok, je vais regarder ça. Il faut recharger le zip du WebDav, non ?

Mais je me permets une remarque générale.
Il n'est pas simple de plonger dans un gros programme qu'on n'a pas écrit. Encore moins pour y traquer une anomalie. Je préfèrerais que tu réduises ton code au strict minimum: sans aucune interface visuelle, juste avant le END, l'ouverture du fichier concerné, chargement des variables nécessaires "à la main", puis appel de la fonction en cause. Là, on peut intervenir facilement.

La sub est toute neuve, donc il vaut mieux recharger sur le webdav.
A l' avenir, je ferai plus court quoi que compliqué avec des bases de données.

Dans le cas, la sub récupère l' "item_index" d' un combo et récupère tout d' après cet index.
Donc "normalement", tout est dans la sub.  

avant d' appeler la fonction ReadNextIsamKey , j' ai ma valeur cherchée et le n° de ma clé.
J' ai placé un message pour vérifier

Mais voilà, parfois, souvent, j' ai des sorties bizarres, voir pas de sortie.
Je me suis dit que, peut_être, il fallait une boucle sur le nombre d' enregistrement mais là 
quand j' ai un résultat, il s' affiche en double...