Control '' has no parent - A Very Strange Bug 1

[Naktibalda]

This is a bug which has been driving me crazy! I have a base custom frame which is inherited by other classes. The code has functioned properly for a long time, but sometimes it "acts up". Strange things will cause an error message to appear upon instantiating a derived class of the base custom frame. The error is "Project_nnVasculatureGeneration.exe raised exception class EInvalidOperation with message 'Control 'Label5' has no parent window'. Process stopped."

Now if i delete label5, it will raise the same error for label4. If i delete all the labels it will operate normally again (sometimes). This is strange because there are other controls in the derived class (buttons, panels, toolbars etc). If i then put the label back into the derived class it will often work normally.

Once the error is raised the code seems to be irreversibly broken. I've found that things such as adding a space after the ; sign in a seemingly unrelated unit will sometimes cause this error to show up. If I undo all the changes i made, the error still persists.

Perhaps Delphi does or saves something at runtime which would cause this error to persist even after I've undone any changes I made to the code to restore it back to the state it was in before the error..

The actual error is brought about by a line which instantiates the custom frame. I will list it below, but it works most of the time..


In the derived class

Application.CreateForm(TCustomForm, customForm);
self := create(customForm,0,0);


which is sent to the base class's constructor (which is a custom frame)


constructor TBaseMeshFrame.create(aParent: TWinControl; aLeft, aRight:double);
begin
inherited create(aParent);
self.Parent := aParent;




At this point, ANY advice would really be appreciated. I've been pulling my hair out about this one..

Thanks in advance

 

[whosrdaddy]

the line
self := create(customForm,0,0);
is a bit akward for me and does not seem right

please show the complete code section of this part

/Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[Naktibalda]

This code is meant to create a form on which the custom frame is placed..

constructor TCustomForm.createInternalForm;
begin
Application.CreateForm(TCustomForm, customForm);
self := create(customForm,0,0);
self.parent := customForm;


the ":self := create..." line could be replaced with "self.create...", but it would lead to the same following code:


constructor TBaseMeshFrame.create(aParent: TWinControl; aLeft, aRight:double);
begin
inherited create(aParent);
self.Parent := aParent;

 

[Glenn9999]

  Application.CreateForm(TCustomForm, customForm);
  self := create(customForm,0,0);

Is there any particular reason why you are creating two memory references to this form? I concur, the second one definitely doesn't sound right. Comment it out and try your code.

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[Naktibalda]

So the first line

"Application.createForm(TCustomForm, customForm);"

creates the form, and the second line

"self := create(customForm,0,0);"

creates the frame which is placed on the form created in the first line. The second line of code is not creating another form, it is just referencing the form as the parent of the frame.

I guess i'm not sure what exactly the difference is between an owner and a parent with respect to frames. But the problem doesn't seem to directly come from the code itself. Like I said, these lines of code normally work just fine. The bug only seems to come out when I make big changes in derived classes of the custom frame. But all of these derived classes use the same method of creating a form and then placing the frame on that form.

Again, once I delete the "offending" labels, the bug goes away, even though there may be all sorts of other components in the frame. It just doesn't seem to like the labels for some reason...

Furthermore, once I've deleted the labels and ran the program, I can usually add them back in and the program will run bug-free again. This to me suggests something deeper at work here, something perhaps outside of my code... but i'm really at a loss to say exactly what...

 

[whosrdaddy]

I still stand by my point.

first of all

constructor TBaseMeshFrame.create(aParent: TWinControl; aLeft, aRight:double); has no return value!!!!

so if you do "self := create(customForm,0,0);"
you are effectivly overwriting the variable that holds your CustomForm with some garbage (or nil, not sure though)

the moment you customform is destroyed things will go all wrong...

so self := x; is NOT the same as Self.Create(x)

to make things clear about owner/parent stuff:

To be crystal clear:
- The Owner is responsible for the existence of its owned Components and frees them when it destroys itself (they are part of the owner and cannot exist without it).
- The Parent is in charge of showing its children (Controls - without a Parent their Visible property has no effect) and as such will also free its Controls when it destroys itself because nobody would be able to show them anymore.

/Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!