As anybody can test that the code crashes under the delphi debugger and in debug mode I would like to see that video.
Summary:
The code eats the access violations in release mode Both in Delphi and in Lazarus.
The code will show the access violations under debugger both in Delphi and in Lazarus.
The code uses a fixed array of pointers (16380 in Delphi, 65536 in Lazarus) that is not initialized.
The code uses Length() on a fixed array, which is the same as as one of the above numbers.
Contrary to a dynamic array Length() will not return the actual number of elements used.
Not in Lazarus and not in Delphi.
What happens is that the array likely has a lot of nil pointers left and the code tries to read records field on a nil polinter... BOOM!
What he should do and what I did for him
1. Initialize the array so you can be sure they are all nil's in the first place.
1a.The pointers are on the stack and the stack is dirty. Do use Defaut()
2. Check if you are reading a valid entry by checking for nil
3. Don't eat the exceptions, but handle them. Or write in such a way you don't need them.
4. Use proper settings for debug and release.
Now make the movie and show us how you solved it.
Maybe the best way to demonstrate this is to show you do not even need the exception if you write proper code. Works in Delphi and in Freepascal:
procedure TForm1.ListProps;
Var
ListaPropriedades : TPropList;
Contador : Integer;
begin
ListaPropriedades := Default(TPropList); // initialize
GetPropList(TypeInfo(TForm), [tkMethod, tkProcedure], @ListaPropriedades);
Memo1.Clear;
For Contador := Low(ListaPropriedades) to High(ListaPropriedades) do
if ListaPropriedades[Contador] <> nil then
memo1.Lines.Add(String(ListaPropriedades[contador]^.name)) // cast removes warning
else
Break; // We're done when we meet nil
end;