I cannot remove an object from TObjectList

But isn't the same when you set OwnsObjects to False?

Ok. Changed to TList. The error is still there.
:(

Solved by restarting Delphi/deleting DCU's and rebuilding the project (I don't know for sure which of these actually solved the problem).

Sorry. Problem not solved!

I removed FastMM4 from my Uses clause and the code worked (probably Delphi didn't see the change until I rebuilt). Now that I added the FastMM, the problem is back.

So I still need help with this one. Points increased.

I don't use FastMM so I cannot comment on that.
Your code does not show what  Cub is. I aaume that it is a TCubObj  Here are some things to try though to be honest I don't really think they should make a difference:

 for x:= Lcub.Count-1 downto 0 DO
  begin
    Cub := TCubObj( LCub.GetCub(x)); // <--- Cast as TCubObj
    if Cub.Vec.Count= 0 then then
       begin
         Cub.Free              // <--- Try Free before Delete
         LCub.Delete(x);    // <--- Should do the same thing as remove it's just the way I would do it.
       end;

GetCub is like this:

function TCubList.GetCub(Poz: Integer): TCubObj;                                
begin
 Result:= TCubObj(self[Poz]);
end;

Use Extract() instead Remove().

But remove should work... Are you sure that OwnsObjects is False?

Take a look in Notify() method of TObjectList. it free the object when Action:TListNotification is
lnDeleted but not when is lnExtracted.

If you look inside TList.Extract and remove you'll see that Extract send a lnExtracted Notifiy Action and Remove() sends a lnDeleted

Ok. I have tried only Cub.Free and still get that "Invalid pointer op".
The question is why the problem appears only when I use FastMM4?
As I said above, the code works (this is why I though for few hours that the problem was solved) if I remove FastMM4.

Have you followed the usage instructions for FastMM4?

<quote>
Usage:
 Delphi:
  Place this unit as the very first unit under the "uses" section in your
  project's .dpr file.
<end quote>

If you don't follow this, you may end up mixing the memory managers which could cause the issues you are seeing. Just a thought...
---

Russell

"Place this unit as the very first unit under the "uses" section in your project's .dpr file."

Yes. I uses it since 2007. It works really well with other projects. Unfortunately FastMM is free and the support is poor.

I use it as well, and have not had any issues with it. Most likely there is a pointer bug in your code. (stale pointer usage / double free / etc). I would suggest enabling full debug mode for FastMM. If you can narrow down the code (while still reproducing the error), then posting it here would also help.

Russell

I already activated the fulldebugmode 1-2 weeks ago.
FastMM4 generates an incredible large leak memory report which is never the same.
No single other leak detector can detect those leaks.

When an "Invalid pointer operation" appears?
What does it means?

My application is vary large (about 10 forms and over 20-30 other units), I cannot post it here.

This is caused because the memory manager has raised an EInvalidPointer exception.

>> from the help <<
EInvalidPointer is raised when an application attempts an invalid pointer operation. For example, it can occur if an application tries to dispose of the same pointer twice, or refers to a pointer which has already been disposed of.
<<

This type of error is ONLY thrown by the memory manager. As stated above, the most common occurrence is a double free on an object. It can also occur if a free'd object is later referenced, although it can be difficult to track. Take the following code (with intended pointer error) that executes without raising an exception.

var  objList:       TObjectList;
     strmMem:       TMemoryStream;
     dwIndex:       Integer;
begin

  objList:=TObjectList.Create(False);

  for dwIndex:=0 to 5 do
     objList.Add(TMemoryStream.Create);

  for dwIndex:=Pred(objList.Count) downto 0 do
  begin
     strmMem:=TMemoryStream(objList[dwIndex]);
     objList.Delete(dwIndex);
     strmMem.Free;
     strmMem.Size:=0; // <- This runs, but is a stale pointer BUG due to the object being freed
  end;

  objList.Free;

end;

There could be something wrong in the way I created those objects and insert them to the list? I REUSE the NewCub var to load more than one file from disk. Everything is fine. Right?

(full code into my initial post)
 repeat
  NewCub:= TCubObj.Create;
  Error:= NewCub.ImportFile;
  if Error<> '' then                   { if error loading this file then don't add it to the list }
     begin
       FreeAndNil(NewCub);
       Continue;
     end;
  LCub.Add(NewCub);        
 until something;

I also tried to get rid of the NewCub var and work directly with the LCub list:
TCubObj(LCub[x]).ImportFile
but I get the same error.


-------------------------------


I loaded two NewCubs into the LCub list and looked at their memory location using the @ operator.
Both have a unique address and also looking inside the object, all its data/fields are ok.
So, if the memory of those two objects is not overwritten, why I can't destroy them.
Note: If I remember correctly, in a test made few days ago, I can Free the first object (the one located at index 0 in LCub list) but not the last one.




PS: Points increased to 200.

"    strmMem.Free;
     strmMem.Size:=0; // <- This runs, but is a stale pointer BUG due to the object being freed"
rllibby


This is why I replaced one week ago all .Free operators with FreeAndNil, in the whole program (as you can also see in my initial piece of code).
From what I know, your code should immediately raise and error if the strmMem is free and NIL.

Anyway, the code where this problem appears is short and as you can see there is no place where a double call to FREE appears.

You have something going on... really hard to say without seeing full code.

Anyways, while my example SHOULD raise an exception, if you run it you will find that it DOES NOT. As already stated, pointer bugs can be insiduous and difficult to track. If you want to ensure that you don't have a double free going on behind the scenes, you could write a simple override class like below:

type
  // Your existing class definition
  TCubObj           =  class(TObject);

  // Overriden example for testing
  TCubObjEx      =  class(TCubObj)
  private
     // Private declarations
     FFreeCount:    Integer;
  protected
     // Protected declarations
  public
     // Public declarations
     constructor    Create;
     destructor     Destroy; override;
  end;

constructor TCubObjEx.Create;
begin

  // Perform inherited
  inherited Create;

  // Set free counter
  FFreeCount:=0;

end;

destructor TCubObjEx.Destroy;
begin

  // Resource protection
  try
     // Increment free counter
     Inc(FFreeCount);
     // Display message
     MessageBox(0, PChar(Format('(%p) TCubObjEx.Destroy(%d)', [Addr(Self), FFreeCount])), nil, MB_OK);
  finally
     // Perform inherited
     inherited Destroy;
  end;

end;

then in places where you are using TCubObj.Create, you would use TCubObjEx.Create (or you could add the logic from above into your existing class, choice is yours). This will visually show you the number of times the destructor is getting called.

Russell

"Anyways, while my example SHOULD raise an exception, if you run it you will find that it DOES NOT" rllibby.

Did you actually tried to run that code? Because on my Delphi 7 it gave me this error (no FastMM):

---------------------------
Project1
---------------------------
Access violation at address 00000018. Read of address 00000018.
---------------------------
OK  
---------------------------

If I activate FastMM, the AV is in "kernel32".


.


If I replace the FREE with FreeAndNil (as explained above) the error is:

---------------------------
Project1
---------------------------
Access violation at address 0041D6D1 in module 'Project1.exe'. Read of address 00000000.
---------------------------
OK  
---------------------------

Sorry, I missed your post about checking for double free in the destructor.
Thanks for the idea. I will try it right away. If there is a double free attempt then your destructor should catch it.

One question: there is a special reason to override that class? Or I can insert the code directly into the TCubObj?

I'm running D5, and I never post code without first testing. If you had checked my background you wouldn't even ask that question. And you **MISSED** the whole point to begin with.

Because the heap is managed by Delphi (using default or fast MM), a free does nothing more than run the destructor and return the memory back to the  managed heap. The memory is STILL allocated by the heap (unless / until the heap block is returned to the OS via a VirtualFree call), so in windows terms the memory is still valid. So while on your D7 system you get an exception, on a D5 system you don't. The **POINT** being that pointer bugs do not necessarily raise an exception on the line of buggy code. Did you even bother to check for double-free's using the code provided?

I would also suggest that you evaluate what you are asking for. You have pointer issues, and are expecting assistance without providing code to test/validate against.

>> then in places where you are using TCubObj.Create, you would use TCubObjEx.Create (or you could add the logic from above into your existing class, choice is yours). <<

let me restate again...

>> or you could add the logic from above into your existing class, choice is yours <<

"while my example SHOULD raise an exception, if you run it you will find that it DOES NOT"

Hey! My question was valid as the experiment shows something different that you were saying.
There is nothing wrong in questioning the information before entering it into the brain :)
If you say that you tested the code, I believe you. It just means that Delphi 5 and 7 behave in different way. There is no reason to get upset :)

---------

I will try the code you provided (the destructor) right away.

Is also my intention to fix this problem but I cannot upload the full program here. As I already explained it is really large.

I'm not upset, I just don't have time to waste helping someone that did not acknowledge the advise, or take the time to read what I had already posted.

"If I replace the FREE with FreeAndNil (as explained above) the error..."

Sorry, but other people confirmed what I said: trying to access an object after you pass it to FreeAndNil will raise ALWAYS and error!

I have placed your code into the Destructor and I have found that no objects are freed twice. So, this is a good.
However, I have found that all released objects have exactly the same address: 0012FC04.

Plus I have monitored the memory taken by the application. Every time I used that procedure that *may* have the bug, the memory raises from 6.22 to 20MB. But after the procedure exits, the memory returns to 6.22. I have run the procedure 20-30 times and the memory was always released. So I think there is no leak.

Hi Fedra:
Did you tried to use Extract() instead Remove()?

Show a little bit more code, something about the constructor of TCubList.
Can you make a little project which reproduces this behavior?
Also, try installing the trial of Eurekalog: www.eurekalog.com
It has a memory leak detection which works quite well.

Hi.
1) As I explained above, I tried to free the object directly, without calling Extract or Remove and is still not working.
It looks like there is a problem in freeing the TCubObj object and not in TCubList.

2) I didn't changed the constructor/destructor of TCubList. TCubList has just few extra properties that help me to access easily its items.

3) I think I stated this also above: only when I use FastMM4 (latest version) I have this "invalid pointer" error. If I remove FastMM, the program works perfectly (it worked for 3 years). No single other memory debugger can detect the leaks that FastMM detects (I have tried other 4, including Eureka).

4) As you have asked, the code will come soon.

what options do you have set for FastMM if you use it. Any more info in the exception (what addresses)?

As rllibby instructed, I added his piece of code in the destructor of TCubObj. It is not Freed twice! So the problems is not here. Anyway, as you can see from my code, there is no place where Cub.Free is called twice.

Points increased.
Thanks for help guys!

TYPE
 TCubList = class(TObjectList)
   private
   protected
   public
     function  GetCub(Poz: Integer): TCubObj;                                  
     function  AllDeadOrDone: Boolean;
     function  AllHaveChroma: boolean;                                         
     procedure FreeObject(Poz: Integer); overload;                             
     procedure FreeObject(Obj: TCubObj); overload;                             
     procedure SortByPosInGrid;
 end;
 
procedure TCubList.FreeObject(Poz: Integer);                                    
var Cub: TCubObj;
begin
 Cub:= GetCub(Poz);
 FreeAndNil(Cub);
 Delete(Poz);
end;
 
 
procedure TCubList.FreeObject(Obj: TCubObj);                                    
begin
 Extract(Obj);                                                                  
 FreeAndNil(Obj);
end;
 
 
function TCubList.GetCub(Poz: Integer): TCubObj;
begin
 Result:= TCubObj(self[Poz]);
end;
 
 
 
{-------------------------------------------------------------------------------
                                    USING LCUB
-------------------------------------------------------------------------------}
 
 
 
procedure Start;
begin
 LCub:= TCubList.Create(FALSE);                                                 { FALSE means OwnsObjects= FALSE }      {# only in v2}
 ...
 
 { START }
 InputSp:= 0;
 AlreadyShown:= FALSE;
 REPEAT
   Nume:= InputList[InputSp];
 
   { IMPORT }
   NewCub:= TCubObj.Create;
   WITH FrmSettings DO
    Msg:= NewCub.ImportSp(Name, spn1.Value, spn2.Value, spn3.Value);
 
   { REMOVE INVALID }
   if Msg<> '' then
    begin
     Out2Log('ERROR');
 
     { Move to 'INVALID' folder }
     InvalidFolder:= ExtractFilePath(CntFullName)+ 'Invalid\';
     if ForceDirectories(InvalidFolder) then
      begin
       if FrmSettings.radCopyFiles.Checked                                      
       then FileCopyTo(NewCub.FullName, InvalidFolder+NewCub.ShortName, TRUE)
       else FileMoveTo(NewCub.FullName, InvalidFolder+NewCub.ShortName);
      end; 
 
     InputList.Delete(InputSp);
     FreeAndNil(NewCub);
     CONTINUE;                                                                  { ABORT THIS LOOP }
    end;
   
   { Add cub to list }
   LCub.Add(NewCub);
   
   { CHECK FOR LOW QUALITY }                                             
   if NewCub.GetNrOfBT < 25 then
      begin
       Out2Log('Possible errors while importing');
      end;
   inc(InputSp);  
 UNTIL InputSp>= InputList.Count;      {#END IMPORT}
 
 
 LCub.GetCub(ctRefPos).IsRef:= UseRef;
 
{=============================================================================
| =                                   BLOCK                                = |
 =============================================================================                                                                                      }
 TRY
  { COMPARE }
  for x:= 0 TO Lcub.Count-2 DO
    for y:= x+1 TO Lcub.Count-1 DO
      FindW(LCub.GetCub(x), LCub.GetCub(y), WSize);
 
  { FREE non match }
  for x:= Lcub.Count-1 downto 0 DO
   begin
    Cub:= LCub.GetCub(x);
    if Cub.VList.Count= 0 then
     begin
       if Cub.IsRef
       then begin
              Out2Log('Cannot be done');
              Grid.UseRef:= FALSE;
              UseRef:= FALSE;
            end
       else begin
              StringList.Add(Cub.FullName);
              Out2Log('This file has not match');
            end;
 
       { I don't need this file anymore. Free it. }
       //Lcub.FreeObject(Cub);
       //Cub.Free
       //GetCub(x).Free;
       //Lcub.Extract(x)
       //FreeAndNil(Cub)
       *** INVALID Pointer OP HERE ***
       
     end
   end;
 
 ...
 ...
end;

                                              

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:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:
91:
92:
93:
94:
95:
96:
97:
98:
99:
100:
101:
102:
103:
104:
105:
106:
107:
108:
109:
110:
111:
112:
113:
114:
115:
116:
117:
118:
119:
120:
121:
122:
123:
124:
125:
126:
127:
128:
129:
130:
131:
132:

MerijnB:
"what options do you have set for FastMM if you use it. Any more info in the exception (what addresses)?"

Is set on full debug - it needs the FastMM_FullDebugMode.dll.
"Invalid pointer op" appears as a dialog box. There is no address or other information. I have found its position in the source code by running the program step by step until that line where I try to free the 'Cub'.

This "invalid pointer" does not appear in FastMM's leak log.

the log may look like this, but is never the same:

------------------------------------------------------
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):
5 - 12 bytes: TIdThreadSafeInteger x 1
13 - 20 bytes: TList x 1
21 - 36 bytes: TIdCriticalSection x 2
37 - 52 bytes: TStringList x 2
85 - 100 bytes: AnsiString x 2
149 - 164 bytes: TCubObj x 2
165 - 180 bytes: Unknown x 1
437 - 484 bytes: AnsiString x 1
533 - 596 bytes: AnsiString x 2
821 - 916 bytes: AnsiString x 1
1013 - 1124 bytes: Unknown x 1
1669 - 1844 bytes: Unknown x 1

The sizes of leaked medium and large blocks are (excluding expected leaks registered by pointer): 162980, 109732, 4260
Note: Memory leak detail is logged to a text file in the same folder as this application. To disable this memory leak check, undefine "EnableMemoryLeakReporting".
------------------------------------------------------

Again: Eureka sees no leaks, except the old one in a TDragAndDrop component - totally unrelated with this stuff (www.melander.dk).

something that strikes me as odd:

procedure TCubList.FreeObject(Poz: Integer);                                    
var Cub: TCubObj;
begin
 Cub:= GetCub(Poz);
 FreeAndNil(Cub);
 Delete(Poz);
end;

you write your own routine to free objects within TCubList when it's allready in the TObjectList ?
why ?

this is basically saying OwnsObjects := True ...
just set OwnsObjects = true and use the Delete(Index) or Delete(IndexOf(AObject));

something people invent something again and again and again and ...
when all they had to do was read the help to see if it existed allready or not

and when a program has a memory leak, and some other program catches it and points to something totally different, maybe the memory leak *is* in the something totally different ...

the second that i would say ...
at first glance you certainly have memory leaks
i tend to make sure i create an object and free it on the same level
i added levels to your code to show the level where you create and the level where your free
this is one of the ways to see visually where you have memory leaks ...
in 95% of the cases i just pinpoint the memory leak with keeping this in mind
because you deleted necessay parts of the code to understand the concept nobody can really help you
but some try ...

you are creating NewCub on Level1 and freeing it on Level2
lets translate it: you are allways creating it on Level1 and
(because of the if) sometimes deleting it on Level2
 
  // level 1
  { IMPORT }
  NewCub:= TCubObj.Create;
  WITH FrmSettings DO
    Msg:= NewCub.ImportSp(Name, spn1.Value, spn2.Value, spn3.Value);
 
  { REMOVE INVALID }
  if Msg<> '' then
  begin
    // level 2
   Out2Log('ERROR');
   { Move to 'INVALID' folder }
   InvalidFolder:= ExtractFilePath(CntFullName)+ 'Invalid\';
   if ForceDirectories(InvalidFolder) then
   begin
      // level 3
      if FrmSettings.radCopyFiles.Checked then
        FileCopyTo(NewCub.FullName, InvalidFolder+NewCub.ShortName, TRUE)
      else
        FileMoveTo(NewCub.FullName, InvalidFolder+NewCub.ShortName);
    end;
    // level 2
 
    InputList.Delete(InputSp);
    FreeAndNil(NewCub);
    CONTINUE;                                                                  { ABORT THIS LOOP }
  end;
  // level 1

this is just a guess as you deleted invaluable parts of your code

if you create every instance using a try finally and keep them on the same level you prevent this

aObject := TObject.Create;
try
  if blabla then
  begin
    // etc
  end;
  // etc
finally
  FreeAndNil(aObject);
end;

@Geert_Gruwez:

> you write your own routine to free objects within TCubList when it's allready in the TObjectList ? why ?
> this is basically saying OwnsObjects := True ...

see start post:

> I want to keep the objects in memory after this TObjectList is destroyed so I MUST keep the OwnsObjects= false.

There are of course other options for this, but this is fedra's motivation for doing this.

maybe it would be better for fedra to state in a functional description what is desired of the code
sometimes you start yourself blind on the code without even thinking of what is actually needed

and you end up fixing code that actually needs deleting because a different approach must be used ...

> and you end up fixing code that actually needs deleting because a different approach must be used ...

This seems to be the case here. I think fedra just can't grasp it here, too many strange things in the setup which makes it hard to help.

On the other hand, this is the best way to learn things, just receiving a proper implementation isn't :)

another thing i tend to avoid : CONTINUE and EXIT
it breaks the natural flow !

it just makes it more difficult to follow a certain flow

but that's just my 2 cents

> another thing i tend to avoid : CONTINUE and EXIT
> it breaks the natural flow !

Nice to notice the different opinions about this. I personally see this as very powerful flow control methods (if not abused of course). Just the same with goto, it's not evil by itself, but you can use it in an evil way.

i have drilled myself in finding the memory leaks on sight the way i explained above.
this resulted in not using exit, break, goto, continue, etc ...
i don't allways rewrite code, just when it gets very complex and when there are problems
i just reformat it, and usually after, it only takes a glance to see where the error is.
sometimes it does require some recoding, and then it's easy to go back to the original code
and pinpoint the error.  try finally is often forgotten in this, and adding it usually pinpoints the error

like this

NewCub:= TCubObj.Create;
try

  if x = y then
  begin
    finally
      FreeAndNil(NewCub);
    end;
  end;

  ... compiler error !

that's what i mean with same level, even the compiler doesn't like it !

MerijnB.
"But in the end, you always add the last NewCub to LCub."

I don't understand.
Let's say I have two objects and for both (Msg <> '').
In this case, for both I hit the CONTINUE and none is added into the LCub.

Can you explain?

thanks

oops, you're right, my bad

Geert
"you are creating NewCub on Level1 and freeing it on Level2"


Hi.
You said that my code is wrong. Probably you are right :)
But you never explained how to free the object at level one!

maybe it would be better for fedra to state in a functional description what is desired of the code

What I want to do is to load and decode some files from disk, find the ones that are somehow similar and display them in a grid. In the piece of code (the top) that I displayed I filter invalid files (few of them may have been incorrectly formatted). I put remaining good files in the LCub. At the bottom of the code, I search for similar files and remove from LCub, those that are not similar. There are many filters like this. In the end only very few files are left in the LCub.

Then I transfer those remaining files from LCub into the grid, in order to display them. This is why LCub.OwnsObjects must be False.

Practically I use LCub as a temporary place to store my files (objects) until I find the files I am interested in.

aha, the bait worked ...
and yer right, i didn't ...

i'll try and do it from the limited code fragments you supplied

reading the code
for the start part :
it looks like you want to move files from a source to a valid destination or an invalid destionation ?
is correct ?

procedure Start;
var 
  // maybe complete this too, so we now which are unit vars, global vars, local vars ... ?
  IsValid: Boolean;
begin
  LCub := TCubList.Create(FALSE); { FALSE means OwnsObjects= FALSE }      {# only in v2}
  try
    ...
    { START }
    InputSp := 0;
    AlreadyShown:= FALSE;
    REPEAT
      Nume := InputList[InputSp];
 
      { IMPORT }
      IsValid := True;
      NewCub := TCubObj.Create;
      try
        // What are you trying to do here ?
        // use a form to give values to the object ?
        // and allways the same values ???
        // is this the same ?
        Msg := NewCub.ImportSp(FrmSettings.Name, FrmSettings.spn1.Value, FrmSettings.spn2.Value, FrmSettings.spn3.Value);
 
        { REMOVE INVALID }
        if Msg <> '' then
        begin
          Out2Log('ERROR');
          IsValid := False;
          { Move to 'INVALID' folder }
          InvalidFolder := ExtractFilePath(CntFullName) + 'Invalid\';
          if ForceDirectories(InvalidFolder) then
          begin
            if FrmSettings.radCopyFiles.Checked then 
              FileCopyTo(NewCub.FullName, InvalidFolder+NewCub.ShortName, TRUE)
            else 
              FileMoveTo(NewCub.FullName, InvalidFolder+NewCub.ShortName);
          end;  // else What if you get an error stating the user doesn't have priviliges  enough to create a directory ?
        end else 
          // i assume the object is valid here ?
        begin
          // i get stuck here 
          // can't see where your going ...
          { CHECK FOR LOW QUALITY }                                             
          if NewCub.GetNrOfBT < 25 then
            Out2Log('Possible errors while importing');
          LCub.Add(NewCub);
        end;
      finally
        if not IsValid // hmm you don't want to delete it when adding to the list (i know not same level)
          FreeAndNil(NewCub);
      end;
      InputList.Delete(InputSp); // you delete it from the list to go to the next item ?
      inc(InputSp);  // ???
    UNTIL InputSp >= InputList.Count;      {#END IMPORT}
 
    ... rest of code is later
    ... feedback ?
 
  finally
    FreeAndNil(LCub);
  end; 
end;

                                              

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:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:

so your LCub object does the parsing of the files

cleaner way to get to same level of create / delete

NewCub.ImportSp(FrmSettings.Name, FrmSettings.spn1.Value, FrmSettings.spn2.Value, FrmSettings.spn3.Value);

add a property/field to the TCub: IsValidFile: boolean
set it in the ImportSp

at the end of the Import:
delete the invalid ones

with functional description is easy to understand:

what about below approach for storing a list of *good* files ?
it's a bit of pseudo code (doesn't actually compile)
the goodfilelist is in the form and is available as long as the form exists

type
  TForm1 = class(TForm)
  private
    fGoodFileList: TObjectList;
    LoadFilesIntoList;
  public
    constructor Create(AOwner: TComponent);
    destructor Destroy; override;
  end;
  
procedure TForm1.LoadFilesIntoList;
var aFileParser: TFileParser;
begin
  // CleanList;
  fGoodFileList.BeginUpdate;
  try
    fGoodFileList.Clear; // i don't care about the objects getting freed or not ...
    for I := 0 to ListOfFiles.Count-1 do 
    begin
      aFileParser := TFileParser.Create(ListOfFiles[I]);
      if aFileParser.IsGoodFile then 
        fGoofFileList.Add(aFileParser); 
    end;
  finally
    fGoodFileList.EndUpdate;
  end;
end;
  
constructor TForm1.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  fGoodFileList := TGoodFileList.Create(True);
end;
 
destructor TForm1.Destroy;
begin
  FreeAndNil(fGoodFileList);
  inherited Destroy;
end;
 
                                              

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:

your proc for inserting into the grid would be very easy ...
in pseudo ...

procedure TForm1.PutinGrid;
var I: Integer;
begin
  // Clean grid first off course
  Grid.Recordcount := fGoodFilesList.Count;
  for I := 0 to fGoodFilesList.Count-1 do
  begin
    recordIndex := AddRecord;
    Values[recordIndex, columnName.Index] := TFileParser(fGoodFileList[I]).FileName;
    Values[recordIndex, columnFormatting.Index] := TFileParser(fGoodFileList[I]).Formatting;
    // etc
  end;
end;

no need to bother with freeing of objects any more as the TObjectList handles them
unless off course your ObjectList is not in the same form as your grid ?
you could still move it if it isn't ...

very complex mathematical functions ???
for somebody who was the best in school at math at the age of 17,
this doesn't really mean much ...
there were off course better ones in other schools as i just missed the nationwide finals.