Possible cause of error

[egsuh]

Hi,
I know that this question is not specific enough. But I cannot explain more.
I got external errors at the following position. I assume that this is related with rtti controls.
For me, the error happens at the changing TIObject. But it is not consistent... only at specific case.

And I cannot find exactly the position of my code that caused the error.

What could possibly cause this error? This is in the  lazarus\components\ideintf\propedit.pp

Code: Pascal  [Select][+][-]

1. procedure TPropertyEditorHook.SetLookupRoot(APersistent: TPersistent);
2. var
3.   i: Integer;
4. begin
5.   if FLookupRoot=APersistent then exit;
6.   if FLookupRoot is TComponent then               // <--       External access error here
7.     RemoveFreeNotification(TComponent(FLookupRoot));
8.   FLookupRoot:=APersistent;
9.   if FLookupRoot is TComponent then
10.     FreeNotification(TComponent(FLookupRoot));
11.   i:=GetHandlerCount(htChangeLookupRoot);
12.   while GetNextHandlerIndex(htChangeLookupRoot,i) do
13.     TPropHookChangeLookupRoot(FHandlers[htChangeLookupRoot][i])();
14. end;

                                 

[jamie]

Well maybe this?

Code: Pascal  [Select][+][-]

1. if (fLookupRoot =Nil) or (FLookupRoot=APersistent) then exit;
2.  ....
3.   if FLookupRoot is TComponent then        
4.  

[egsuh]

Haha jamie, thank you very much.  I changed the file and then the error disappears.
But... this file is not written by me. Should I report to bug-tracker, or do something else?


The line is from

d:\lazarus\components\ideintf\propedits.pp   at  line 8131.

Problem is I cannot exactly reproduce the error.

[cdbc]

Hi
Report the error _and_ @jamie's fix -- please.
Regards Benny

[egsuh]

I've emailed to mailing list.

[jamie]

I don't know if that should be fixed that way because in reality NULLs should not be given to that function from what I can see.

  Maybe a better solution would be to raise an exception so that a stack track can walk back to the calling code that is given it a NILL pointer.

Jamie

[egsuh]

This is hard to explain.

In my example, I have list of objects whose addresses are linked via TTreeNode.Data.
When a new node is selected, the new object is passed to the TIObject property of rtti controls.
So far, so good. No problem.

Problem happens when I unload all the objects once --- free them all, and reload new set of objects. Normally the last item of the treeview is assigned as selected, and then its object's address should be passed to the TIobject property of rtti controls. The error happens at this moment.

To resolve this problem, I had re-defined all the properties of the object again within a dummy frame (datamodule would do the same thing as well), and assigned the TFrame to the TIObject of rtti controls. This does not cause problems. But this approach has to define the same properties twice, and I'd like to avoid this if possible.

I do not have overall understanding of the workflow of rtti controls.

[n7800]

This is hard to explain.

Maybe then you could explain what you want to do?

In my example, I have list of objects whose addresses are linked via TTreeNode.Data.

That's clear, each tree item is mapped to some object via a pointer. This is a common usage scenario.

When a new node is selected, the new object is passed to the TIObject property of rtti controls.

That's not clear. Usually, the tree items pointer (TTreeNode.Data) is cast to the required class type and used. Why use RTTI?

Problem happens when I unload all the objects once --- free them all, and reload new set of objects. Normally the last item of the treeview is assigned as selected, and then its object's address should be passed to the TIobject property of rtti controls. The error happens at this moment.

By the way, I don't know if this applies to you, but when using objects via pointers, need to be careful. Need to clearly understand how they are created, who the pointers are passed to, and who destroys them.
* For example, can one and the same object be assigned to two different tree items? If so, then the second call to Free for the same pointer will cause an error.
* If these are components (TTimer, TButton, TForm), then they have their own "Owner" who frees them independently. And when the owner is destroyed, it will free all its components at once. An attempt to free a component after its owner will also result in an error.

[egsuh]

I don't know if that should be fixed that way because in reality NULLs should not be given to that function from what I can see.

For now, I'll use modified code and will keep looking into my codes.

[egsuh]

Code: Pascal  [Select][+][-]

1. if (fLookupRoot =Nil) or (FLookupRoot=APersistent) then exit;

This code seems to make components disappear from Object Inspector in some conditions.

[jamie]

Do you have the "-CR" "verify method calls" checked, in the Debugger options?

if so, turn it off and put the original code back in.

Jamie

[egsuh]

Do you have the "-CR" "verify method calls" checked, in the Debugger options?

if so, turn it off and put the original code back in.

No, it's not checked.