Migrer un projet de J. Colibri : AV garanti à un endroit où ça ne devrait pas

Version imprimable

Voir 40 message(s) de cette discussion en une page

1 pièce(s) jointe(s)

Migrer un projet de J. Colibri : AV garanti à un endroit où ça ne devrait pas

Bonjour,

nouvelle semaine, nouveaux problèmes...

Récupéré hier un projet de traitement graphique chez l'ami John (c'est kèk chose ses projets ! La quantité de fichiers pour faire un HelloWorld, tu te demandes... Plus la manière de nommer les choses, très particulière : faut_ s_'y_ faire_ :mrgreen:).

Bref, je demande à Laz de me le convertir, il se loupe sur certains points qu'après examen je commente (genre les lignes en rapport avec l'impression bloquent la compil : on verra ça plus tard), et quand enfin je peux lancer le prog, ben ça loupe pas : AV :aie:

Après enquête, il y a une blague dans FormCreate, et après enquête approfondie c'est "post sur le forum" parce que là, vous allez voir, c'est encore un truc de ouf'.

Soit un objet déclaré ainsi (je mets juste le début, concerné au 1^er chef) au tout début d'une unité :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 unit u_c_display; {$MODE Delphi} interface uses SysUtils, Classes, u_c_basic_object, u_c_log; type c_display= class(c_basic_object) public m_do_display: Boolean; m_indentation: Integer; m_current_string: String; m_c_strings: tStrings;
et quelques lignes plus bas on trouve cette chose, appelée (à travers une avalanche d'appels intermédiaires [c'est du John]) depuis le FormCreate, donc :
Code:

1 2 3 4 5 6 7 8 9 Constructor c_display.create_display(p_name: String; p_c_strings: tStrings; p_c_log: c_log); begin Inherited ; m_c_strings:= p_c_strings; m_do_display:= True; // <------- Fait planter sur SIGSEGV... m_c_log:= p_c_log; end; // create_display
Vu, le commentaire de l'instruction qui affecte True au boolean ? Que si je commente cette ligne ça roule ? :koi: :koi: :koi: :koi: :koi:
p_c_strings correspond à un memo.Lines, et p_c_log est passé comme nil.

Et sous Windows c'est quelque chose encore dans la même unité mais plus loin que le Create qui met la pagaille :
Pièce jointe 223213

Et la procédure g_c_display.display se contente d'afficher du texte si m_do_display est à true.

Une idée sur ce que je pourrais bien faire pour avancer ?
Une chose très curieuse, c'est que les messages d'erreur n'arrivent pas instantanément, il leur faut bien 5 à 10 secondes (si si !) même quand ils se suivent ; très bizarre...

Ah, le lien de son projet.

24/10/2016, 16h45
BeanzMaster
Salut je viens de regarder vite fait avant de retourner au boulot. ce qui me moi me "choque un peu" c'est que dans
Code:

1 2 3 4 5 6 unit u_c_display; interface uses SysUtils, Classes, u_c_basic_object, u_c_log; type c_display= class(c_basic_object) ...
"c_display" depend donc de l'unité unité u_c_basic_object et que dans celle ci on ait :
Code:

1 2 implementation uses u_c_display;
c'est un peu "une référence circulaire" qui passe peut-être sous "Delphi" mais plante sous Lazarus. Pas le temps de tester, mais si en remplaçant "type c_display= class(c_basic_object)" par "c_display= class" tout simplement ça fonctionne ? mais bon pour ton projet je penses pas que tu ais vraiment besoins de ces 2 unités :zoubi:
24/10/2016, 17h14
Jipété

Citation:

Envoyé par BeanzMaster

c'est un peu "une référence circulaire" qui passe peut-être sous "Delphi" mais plante sous Lazarus.

C'est l'impression que j'ai eue aussi, mais je n'y croyais pas : pas J.C. quand même, pas lui ! Moi je veux bien, mais, John Cé, quand même, non, quoi !

Citation:

Envoyé par BeanzMaster

Pas le temps de tester, mais si en remplaçant "type c_display= class(c_basic_object)" par "c_display= class" tout simplement ça fonctionne ?

Sans le type devant ? Ça ne compile pas, et avec, ça plante tout aussi violemment. :aie: :aie: :aie:

Citation:

Envoyé par BeanzMaster

mais bon pour ton projet je penses pas que tu ais vraiment besoins de ces 2 unités

2 unités ? Il n'y en a qu'une, il me semble, par contre ce c_display est utilisé au moins dans 5 unités, alors l'enlever, c'est comme enlever une carte tout en bas du château ! :mouarf:

Mais merci quand même d'avoir jeté un œil et un début de solution. :ccool:
24/10/2016, 17h40
tourlourou

Il n'y a pas référence circulaire du fait des uses en section interface d'une unité et implementation de l'autre.

Je me posais par contre la question dans le constructeur d'un inherited Create(pName); au lieu d'un inherited sec, ne renvoyant à rien (pas de méthode ancestrale) sinon au type TObject. Mais sans y croire pour résoudre le problème.

Yop !

Citation:

Envoyé par tourlourou

Je me posais par contre la question dans le constructeur d'un inherited Create(pName); au lieu d'un inherited sec, ne renvoyant à rien (pas de méthode ancestrale) sinon au type TObject. Mais sans y croire pour résoudre le problème.

Comme ça, tu veux dire ? :
Code:

1 2 3 4 5 6 7 8 9 Constructor c_display.create_display(p_name: String; p_c_strings: tStrings; p_c_log: c_log); begin //Inherited ; inherited Create(p_name); m_c_strings:= p_c_strings; m_do_display:= True; m_c_log:= p_c_log; end; // create_display
Le compilo l'est pas content :aie:

Citation:

u_c_display.pas(84,33) Error: Wrong number of parameters specified for call to "Create"

24/10/2016, 18h29
tourlourou

Bah oui :oops: elle s'appelle create_basic_object(p_name: String) ! :aie:
24/10/2016, 18h37
Jipété

Citation:

Envoyé par tourlourou

Bah oui :oops: elle s'appelle create_basic_object(p_name: String) ! :aie:

Ah, t'as dû confondre avec create_display(p_name: String; p_c_strings: tStrings; p_c_log: c_log); Virtual; et moi je ne l'ai pas vu :oops: non plus :D

Pas simples pas clairs, hein, les codes à J.C.

Bonjour,

J'ai fait un petit test simplifié (mais je dois m'absenter aujourd'hui) et ça ne plante pas si j'oublie toute la machinerie derrière (je n'ai même pas mis de destructeur tellement je suis pressé ;)) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
type
 
  { TDisplay }
 
  TDisplay = class
     m_do_display: Boolean;
     m_indentation: Integer;
     m_current_string: String;
     m_c_strings: tStrings;
     constructor  create_display(p_name: String; p_c_strings: tStrings);
  end;
 
  { TForm1 }
 
  TForm1 = class(TForm)
    Button1: TButton;
    Memo1: TMemo;
    procedure Button1Click(Sender: TObject);
  private
    { private declarations }
    ADisplay: TDisplay;
  public
    { public declarations }
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.lfm}
 
{ TForm1 }
 
procedure TForm1.Button1Click(Sender: TObject);
begin
  ADisplay := TDisplay.create_display('coucou', memo1.Lines);
end;
 
{ TDisplay }
 
constructor TDisplay.create_display(p_name: String; p_c_strings: tStrings);
begin
  inherited ;
  m_c_strings:= p_c_strings;
  m_do_display:= True; // <------- NE fait PAS planter sur SIGSEGV...
end;
 
end.

Je soupçonne la création d'être mal ficelée, mais je regarderai ça plus tard.

Bonjour,

et merci pour ton petit test. De mon côté, j'ai suivi la piste :

Dans FormCreate, la 1^re instruction c'est
initialize_display(Memo1.Lines); qui se trouve dans u_c_display.pas :

Code:

1
2
3
4
5
6
7
    procedure initialize_display(p_c_strings: tStrings);
      begin
        if Assigned(g_c_display)
          then g_c_display.Free;
 
        g_c_display:= c_display.create_display('display', p_c_strings, Nil);
      end; // initialize_display

et ce c_display.create_display se trouve un peu plus haut :

Code:

1
2
3
4
5
6
7
8
9
    Constructor c_display.create_display(p_name: String; p_c_strings: tStrings; p_c_log: c_log);
      begin
        Inherited ;
 
        m_c_strings:= p_c_strings;
        m_do_display:= True;  // c'est ici que ça plante
 
        m_c_log:= p_c_log;
      end; // create_display

Le c_display, quant à lui, c'est type c_display= class(c_basic_object) et c_basic_object est déclaré dans u_c_basic_object.pas comme ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
unit u_c_basic_object;
  interface
 
    type c_basic_object= class
                           m_name: String;
                           destructor Destroy; Override;
                           constructor create_basic_object(p_name: String); Virtual;
                           constructor construct_empty;
                           procedure display_abstract(p_texte: string);
                 end;
 
  implementation
    uses u_c_display;
 
    constructor c_basic_object.create_basic_object(p_name: String);
      begin
        m_name:= p_name;
      end; // create_basic_object
 
    constructor c_basic_object.construct_empty;
      begin
      end; // construct_empty
 
    procedure c_basic_object.display_abstract(p_texte: string);
      begin
        display_bug_halt(m_name+ ' '+ p_texte+ ': abstract procedure');
      end; // display_abstract
 
    destructor c_basic_object.Destroy;
      begin
      end; // Destroy
 
    begin // u_c_basic_object
    end. // u_c_basic_object

Oui, tout est là, une unité entière juste pour ça...

Tout ça me dépasse, merci pour votre implication :ccool:

Salut question bête mais "g_c_display" il est créé quand et ou ?
car "c_display.create_display('display', p_c_strings, Nil);" pour moi c'est pas un "constructor" même si il est déclarer comme telle dans

Code:

1
2
3
4
5
6
7
8
9
  Constructor c_display.create_display(p_name: String; p_c_strings: tStrings; p_c_log: c_log);
      begin
        Inherited ;
 
        m_c_strings:= p_c_strings;
        m_do_display:= True;  // c'est ici que ça plante
 
        m_c_log:= p_c_log;
      end; // create_display

"inherited" il appel qui dans c_basic_object ????? on dirait simplement que l'objet "c_display" n'est pas instancié correctement d'ou l'erreur. A mon avis il serais judicieux de travailler sur le "constructor" et au lieu d'avoir :

Code:

1
2
3
4
5
6
7
    type c_basic_object= class
                           m_name: String;
                           destructor Destroy; Override;
                           constructor create_basic_object(p_name: String); Virtual;
                           constructor construct_empty;
                           procedure display_abstract(p_texte: string);
                 end;

on aurait :

Code:

1
2
3
4
5
6
    type c_basic_object= class
                           m_name: String;
                           destructor Destroy; Override;
                           constructor create(p_name: String); //override;
                           procedure display_abstract(p_texte: string);
                 end;

Et dans

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
    type c_display= class(c_basic_object)
                      public
                        m_do_display: Boolean;
                        m_indentation: Integer;
                        m_current_string: String;
                        m_c_strings: tStrings;
 
                        m_c_log: c_log;
 
                        Constructor create(p_name: String; p_c_strings: tStrings;
                            p_c_log: c_log); Override;
 
                        procedure clear_display;
 
                        procedure display_string(p_text: String);
                        procedure display(p_text: String);
                        procedure display_line;
 
                        procedure display_strings(p_c_strings: tStrings);
 
                        function f_save_display: Boolean;
                        procedure restore_display(p_display: Boolean);
 
                        procedure stop(p_text: String);
                        procedure display_bug(p_text: String);
                        procedure display_bug_stop(p_text: String);
                        procedure display_bug_halt(p_text: String);
 
                        Destructor Destroy; Override;
                    end;
 
Constructor c_display.create_display(p_name: String; p_c_strings: tStrings; p_c_log: c_log);
      begin
        Inherited Create(p_name);
 
        m_c_strings:= p_c_strings;
        m_do_display:= True;  // c'est ici que ça plante
 
        m_c_log:= p_c_log;
      end; // create_display

Par trop le temps de regarder en détails, mais à mon avis c'est la que le bas blesse ;)

4 pièce(s) jointe(s)

Truc chelou je viens de vite fais de convertir le projet à JC, juste retirer le "DirectoryListBox" je compil et la pas souci j'ai

Pièce jointe 223306

Pas d'erreur à la compilation. par contre l'icone du progamme n'apparait pas encore dans la barre des taches et lorsque je clique sur ok le prog ne se ferme pas.

Le dossier "log" n'existe pas dans l'archive que nini et hop "nouveau dossier" je recompile et la :aie:

Pièce jointe 223307
Pièce jointe 223308
Code:

1 2 3 4 5 procedure display(p_text: String); begin if Assigned(g_c_display) then g_c_display.display(p_text); // Ligne 251 c'est ici donc l'erreur est dans C_display end; // display
je clique sur "OK" nouvelle fenêtre

Pièce jointe 223309
et c'est tout

apres quelque F8 et MAJ+F8 la 1ere erreur apparait ici "Application.Run; " plus le temps de debogguer plus loin je dois encore retourner au taf

Voili voilu en esperant que ca aidera.....un peu

pour info cf mon message précédent c'est sur il y a un objet qui est mal instancié :

Citation:

http://www.freepascal.org/docs-html/user/userap4.html

Runtime 210 Object not initialized
When compiled with range checking on, a program will report this error if you call a virtual method without having called its object’s constructor.

Citation:

Envoyé par BeanzMaster

Salut question bête mais "g_c_display" il est créé quand et ou ?
car "c_display.create_display('display', p_c_strings, Nil);" pour moi c'est pas un "constructor" même si il est déclaré comme tel dans [...]

Réponse :
Déclaré dans u_c_display :
Code:

1 2 // -- THE global display, used by the non-object calls var g_c_display: c_display= Nil;
il est créé là (même unité) :
Code:

1 2 3 4 5 6 7 procedure initialize_display(p_c_strings: tStrings); begin if Assigned(g_c_display) then g_c_display.Free; g_c_display:= c_display.create_display('display', p_c_strings, Nil); end; // initialize_display
qui est appelé par FormCreate, et voilà.

Il est utilisé 17 fois, une fois comme ci-dessus et 16 fois comme ci-dessous :
Code:

1 2 3 4 5 procedure start_display; begin if Assigned(g_c_display) then g_c_display.m_do_display := True; end; // start_display
les 15 autres fois sont + ou - identiques

Quant au reste, remplacement de create_display par create, le compilateur ne retrouve pas ses petits, et me jette une erreur à la figure, genre le constructor has no member blabla...

Citation:

Envoyé par BeanzMaster

Truc chelou je viens vite fait de convertir le projet à JC, juste retirer le "DirectoryListBox" je compil et la pas souci j'ai
[--snip--]
apres quelque F8 et MAJ+F8 la 1ere erreur apparait ici "Application.Run; " plus le temps de debogguer plus loin je dois encore retourner au taf

Bienvenue au club, j'ai eu exactement les mêmes... :aie:

25/10/2016, 18h00
anapurna

salut

Citation:

type
c_display= class(c_basic_object)
public
...
Constructor create(p_name: String; p_c_strings: tStrings; p_c_log: c_log); Override;
...
end;
....
Constructor c_display.create_display(p_name: String; p_c_strings: tStrings; p_c_log: c_log);

il n'y a vraiment rien qui vous choque ?
parce que pour moi c'est plantage assuré ^^

Citation:
Envoyé par anapurna
Code:

1 2 3 4 5 6 7 8 9 type c_display= class(c_basic_object) public ... Constructor create(p_name: String; p_c_strings: tStrings; p_c_log: c_log); Override; ... end; .... Constructor c_display.create_display(p_name: String; p_c_strings: tStrings; p_c_log: c_log);
il n'y a vraiment rien qui vous choque ?
parce que pour moi c'est plantage assuré ^^
T'as vu ce que j'ai écrit cet après-midi ? Tiens, je remets :

Citation:

Envoyé par Jipété

Quant au reste, remplacement de create_display par create, le compilateur ne retrouve pas ses petits, et me jette une erreur à la figure, genre le constructor has no member blabla...

1 pièce(s) jointe(s)

Bonsoir, bonsoir, piouf je rentre du boulot il y a 1h, me prend une bonne douche et hop je me remet sur ce petit truc.

1 - Je remplace les create_????? comme je le disais dans mon précédent post
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 type c_basic_object= class m_name: String; destructor Destroy; Override; // constructor create_basic_object(p_name: String); Virtual; constructor Create(p_name: String);//virtual; type c_display= class(c_basic_object) public ... Constructor create(p_name: String; p_c_strings: tStrings; p_c_log: c_log); ... end; ... // Constructor c_display.create_display(p_name: String; p_c_strings: tStrings; p_c_log: c_log); Constructor c_display.create(p_name: String; p_c_strings: tStringlist; p_c_log: c_log); begin Inherited Create(p_name); m_c_strings := p_c_strings; m_do_display:= True; m_c_log:= p_c_log; end; // create_display
ainsi que tous les appels de "create_basic_object" par "create" jusque la pas de soucis ca compile et paf :aie: toujours ce jolie runtime 210

Je progresse un peu, je vais voir dans le dossier log, ok le fichier est bien créé et rempli. Je vais sur la form et je me met sur l'onglet "display_" je lance le bouzin et la miracle ca fonctionne et le log est bien affiché :weird:
Je clique sur le bouton "Clear" et la :aie: runtime 210 :mur: . je retourne dans l'unité "C_display " je regarde un peu plus dans les fonctions et la je m'aperçois que c'est la variable "m_c_strings: tStrings; " qui lève l'exception.

Il semblerai que "m_c_strings" ne soit plus "accessible" je met "accessible"

car si on fait, dans
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 procedure c_display.clear_display; begin if assigned(m_c_strings) then begin showmessage('Log cleared'); //---> Ici pas de soucis notre message est bien affiché //m_c_strings.Clear; -------------------> C'est la que ca plante, c'est comme si "m_c_strings" avait disparu comme par magie, Une erreur d'adressage au niveau compilation ? end else begin showmessage('no Log Assigned'); end; end; // clear_display
et dans
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 procedure c_display.display(p_text: String); var l_text: String; l_length: Integer; begin if not m_do_display then exit; l_length:= Length(p_text); if (l_length> 0) and (p_text[1]= '<') then begin dec(m_indentation, 2); if m_indentation< 0 then begin display('*** negative indent'); m_indentation:= 0; end; end; // -- if no Write, add indentation if m_current_string= '' then l_text:= f_spaces(m_indentation) else l_text:= ''; // -- compute the indentation, the current strings, and this parameter l_text:= l_text+ m_current_string+ p_text; // -- add the result to the tStrings Showmessage('c_display.Display : '+l_text); // ---> la pas de soucis notre boite s'affiche et le programme fonctionne et le fichier log est correctement écrit (cf ci-dessous) //m_c_strings.Add(l_text); //------> c'est la que ca plante // -- flush to the log if Assigned(m_c_log) then m_c_log.write_line(l_text); if (l_length> 0) and (p_text[1]= '>') then inc(m_indentation, 2); m_current_string:= ''; end; // display
Citation:

// -- D:\Documents\projets\Lazarus\Test\colibri\graphic\color_correction\log/log_posteffect.log 26/10/2016 00:22:35

5 94 764
5 76 636

104 193 764
5 76 636

203 292 764
5 76 636

5 94 764
86 157 636

104 193 764
86 157 636

203 292 764
86 157 636

5 94 764
167 238 636

104 193 764
167 238 636

203 292 764
167 238 636
repaint
create_bitmap

et voila ce que ça donne
en ne commentant pas la ligne " //m_c_strings.Add(l_text); //------> c'est la que ca plante"

Pièce jointe 223337

mais des que l'on se trouve sur le 1er onglet ou si on clique sur le bouton "Clear" ça plante.

Donc, bug de FPC sur les TStrings ici, ou bien serait-il mal utilisé, ici pour FPC ???? c'est franchement bizarre car ca fonctionne bien au début

TStrings étant une classe abstraite cf : http://lazarus-ccr.sourceforge.net/d.../tstrings.html. En remplaçant ce TStrings par TStringList cela pourra peux être résoudre le problème.

voila ca sera tout pour ce soir
Je pense qu'on n'a pas fini de rire avec cet exemple de JC ! :mouarf: qui est très intéressant dans tous les cas.

Bonne nuit

26/10/2016, 12h18
ThWilliam
Salut JP & BeanzMaster.

J'ai fait un petit test en rassemblant le code utile pour c_display dans l'unité principale de mon prog.
J'ai ajouté une procédure toute simple pour le display : elle demande d'ajouter dans AText (un deuxième Memo) le contenu de m_c_strings.
Code:

1 2 3 4 5 6 7 procedure c_display.Display(AText: TStrings); var i: integer; begin for i:= 0 to m_c_strings.count - 1 do AText.Add(m_c_strings[i]); end;
et dans Form1 :
Code:

1 2 3 4 5 6 7 8 9 procedure TForm1.FormCreate(Sender: TObject); begin initialize_display(Memo1.Lines); end; procedure TForm1.Button1Click(Sender: TObject); begin g_c_display.display(memo2.lines); end;
Le FormCreate ne pose pas de problèmes.
Mais le clic sur button1 déclenche l'exception SIGSEGV !

Je rejoins ici ce que dit BeanzMaster. Le problème est uniquement lié à m_c_strings qui n'est plus "accessible".
En fait, en écrivant m_c_strings := p_c_strings , il n'y a aucune création d'objet, m_c_strings reçoit uniquement l'adresse du TStrings de Memo1.
J'ai donc pensé à un problème de synchronisation dans l'ordre de création.
En plaçant le initialize_display dans l'événement OnActivate de Form1 --> plus aucun problème avec la procédure Display.
Et si je modifie Memo1, m_c_strings va prendre en compte le nouveau contenu de Memo1 puisque ce n'est qu'un pointeur.

J'espère que J.C. ne sera pas vexé si je dis que j'aurais codé g_C_display d'une toute autre manière. ;)

Cordialement
Thierry

PS : c'est nouveau dans le forum de ne plus afficher qu'un seul message, les autres étant dans un arbre ? Je n'aime pas du tout cela.

Bonjour,

et grand merci pour ces tests qui ont bien dû te prendre la tête et du temps...

Je reviens juste sur ce point, qui me fait penser à des choses déjà vécues, genre tu testes "if assigned" et le machin ne se comporte pas comme son nom l'indique :koi:
Citation:
Envoyé par BeanzMaster
Il semblerait que "m_c_strings" ne soit plus "accessible" je met "accessible"

car si on fait, dans
Code:

1 2 3 4 5 6 7 procedure c_display.clear_display; begin if assigned(m_c_strings) then begin showmessage('Log cleared'); //---> Ici pas de soucis notre message est bien affiché //m_c_strings.Clear; -------------------> C'est la que ca plante, c'est comme si "m_c_strings" avait disparu comme par magie, Une erreur d'adressage au niveau compilation ?
Donc en gros ce "if assigned" n'est pas fiable et il faudrait alors le remplacer par autre chose, et partout !
Ben on n'est pas rendu, hein...

Citation:

Envoyé par BeanzMaster

Je pense qu'on n'a pas fini de rire avec cet exemple de JC ! :mouarf: qui est très intéressant dans tous les cas.

Comme tu dis, oui, sauf que moi je ris jaune.

Et j'ai l'impression, loin au fond de ma mémoire, d'avoir déjà lu des choses à propos de ce fourbe assigned dans le forum Delphi. :aie:

PS : je viens de retrouver ce que j'avais noté il y a quelque temps :

Citation:

Dans mon FormDestroy j'ai mis if Assigned(UnObjet) then UnObjet.Free; et rien d'anormal jusque là, enfin, il me semble.
Ou plutôt, il me semblait...

Parce que suite à une réorganisation de code, j'ai dupliqué ailleurs cette ligne qui tue et c'est le cas de le dire car jusqu'à ce que je m'en rende compte, je me demandais pourquoi je me prenais un AV à la fermeture de l'application.
Jusqu'à ce que je supprime la ligne dans FormDestroy.

Donc deux possibilités :
- ou bien UnObjet.Free fait mal son boulot dans le sens où l'objet n'est qu'à moitié libéré, ce qui permet une seconde exécution ou plutôt tentative d'exécution se soldant par un AV,
- ou bien c'est if Assigned(UnObjet) qui foire en détectant quand même un objet libéré.

On en est là. J'aime bien la dernière ligne de ma citation, qui recoupe ce que tu as vécu cette nuit... :aie: :aie: :aie:

26/10/2016, 12h33
anapurna

salut

il arrive qu'a la libération d'un objet la valeur ne soit pas complètement "nettoyé"
car l'objet en question a redéfini le destroy mais a oublié de faire un inherited pour que le destroy libère correctement la mémoire
pour palier a ce genre de soucis après le free on affecte nil a la variable

Code:

monObj := nil;
26/10/2016, 12h33
Jipété

Ah, croisement de réponses, mais je préfère sur-poster plutôt qu'éditer mon post précédent.

Citation:

Envoyé par ThWilliam

J'ai donc pensé à un problème de synchronisation dans l'ordre de création.
En plaçant le initialize_display dans l'événement OnActivate de Form1 --> plus aucun problème avec la procédure Display.

:plusser:
Bien vu, bien joué !
:applo:
Je vais enfin pouvoir trafiquer avec ses curseurs, encore bravo et merci.

Citation:

Envoyé par ThWilliam

J'espère que J.C. ne sera pas vexé si je dis que j'aurais codé g_C_display d'une toute autre manière. ;)

:ptdr:

Citation:

Envoyé par ThWilliam

PS : c'est nouveau dans le forum de ne plus afficher qu'un seul message, les autres étant dans un arbre ? Je n'aime pas du tout cela.

:koi:

1 pièce(s) jointe(s)

Citation:

Envoyé par Jipété

Je vais enfin pouvoir trafiquer avec ses curseurs, encore bravo et merci.

Mais pas avec ses fichiers...

Après avoir adapté cette histoire de Directories dans le FormCreate :
Code:

1 2 //// set_directory_listbox_directory(DirectoryListBox1, k_path); FileListBox1.Directory := k_path;
je peux enfin voir ses fichiers, comme dans l'article sur le site (lien donné dans le 1^er post), enfin, les deux premiers, car pour le 3^e la saga continue :

Pièce jointe 223362

:aie:
Et si je clique sur "continuer", j'ai le même avec la précision "Range Check Error".

Tant que je ne touche pas au 3^e je peux passer du 1^er au 2^e et retour plusieurs fois sans souci, donc il y aurait un souci avec ce 3^e ?
Essai d'ouverture avec The Gimp --> RAS, pas de message, rien :koi:
Code:

1 2 3 4 5 6 7 8 9 10 For l_y:= l_start_y to l_end_y do for l_x:= l_start_x to l_end_x do with m_oa_hsv_lines[l_y, l_y] do begin m_saturation_min:= Min(m_saturation_min, m_saturation); m_saturation_max:= Max(m_saturation_max, m_saturation); m_intensity_min:= Min(m_intensity_min, m_intensity); m_intensity_max:= Max(m_intensity_max, m_intensity); end; // for l_x
La ligne 560 c'est celle qui commence avec with...

J'ai donc essayé de rajouter -1 après l_end_x et _y aux deux lignes qui précèdent, même résultat.
Et si je rajoute le -1 après l_start_x et _y alors c'est dès le 1^er fichier qu'il y a l'erreur...

Encore un mystère...

Voir 40 message(s) de cette discussion en une page