Lazarus
Programming => General => Topic started by: jma_sp on October 18, 2016, 05:09:37 pm
-
Hello,
I have a doubt, in Lazarus's program it shows me occasionally the mistake:
Control '' has no parent window.
Press OK to ignore and risk data corruption.
Press Cancel to kill the program.
There is some way of obtaining more precisely to which it refers? it happens on runtime.
-
There is some way of obtaining more precisely to which it refers? it happens on runtime.
Run your program through the debugger. There is no way of telling without seeing some actual code.
Most likely reason would be that you created components/forms dynamically but forgot to set the owner/parent. But that is pure speculation.
-
There is some way of obtaining more precisely to which it refers? it happens on runtime.
Make sure you give all your GUI controls (including those created dynamically) a unique Name.
Then you'll find such error messages far more informative.
BTW, one common cause of this sort of error arises through trying to access a control's Canvas before it has been assigned a Parent.
-
BTW, one common cause of this sort of error arises through trying to access a control's Canvas before it has been assigned a Parent.
Or any HWND-based property, for that matter. If a property requires the control to have a valid HWND, but it does not have a Parent, or its Parent does not have a Parent, or so on, then the HWND cannot be created, and the property fails.
-
Thanks for the responses.
:)
The program is simple enough, has few components these and the mistake happens of random form suddenly only often.
There are no dynamic components only components created directly in the form.
Formulario_Indice: TFormulario_Indice
Panel: TGroupBox
Arbol_Indice: TTreeView
BitBtn_Salir: TBitBtn
BitBtn_Salvar_A_Fichero: TBitBtn
Etiqueta_Busqueda: TLabel
Editor_Busqueda: TEdit
BitBtn_Expandir_Ramas: TBitBtn
BitBtn_Contraer_Ramas: TBitBtn
BitBtn1: TBitBtn
ListadoImagenes: TImageList
Dialogo_Salvar_Fichero: TSaveDialog
IconoBandeja: TTrayIcon
MenuEmergente: TPopupMenu
Maximizar: TMenuItem
Salir: TMenuItem
I will try commenting on components to seeing if annulling someone of it eliminates the message.
-
The program is simple enough, has few components these and the mistake happens of random form suddenly only often.
There are no dynamic components only components created directly in the form.
Generally speaking, you should not be seeing this kind of error for components that are streamed from design-time to run-time. This usually only happens if you are creating components dynamically in code at run-time and are misusing them.
-
This is an old thread, but I have the same problem. There is no dynamic component involved in any way. I get this error at design time when trying to opening a specific form in the IDE. The form worked allright say one week ago, no changes.
Lazarus 2.0.12 on Windows 10.
Right now I am looking for corruption issues in the lfm, but at first glance the lfm seems OK, hard to tell though, it's a quite big form...
Armin.
-
I finally found the problem. This seems to be one of those rare cases when multiple small effects work together and create a big mess.
in my case, I had a TFrame embedded in a TForm containing a TVirtualStringTree. Somehow, in the frame source file (.lfm) in the definition of the TFrame the following property got set:
At design time, a Frame doesn't have a parent, hence the problem.
I also found out that there is some recursion/inheritance behaviour, sometimes (not always!) setting this property in a subcomponent (a TVirtualStringTree) contained inside the frame would give the same messages and crashes.
There must be more to this however, because if you try to set ParentFont to True using the IDE in the current Lazarus version (2.0.12), it won't accept it, you may set it in the GUI, but as soon as you save the frame the property gets silently reset to False. However, there must be a code path around this, since in my lfm source file this property was set to True. For my testing I fell back to modifying the .lfm using a text editor.
More experiments with this property revealed alarming behaviour of the IDE, the effects of this property (and probably similar other properties) beeing set were all sorts of arbitrary crashes of the IDE, sometimes vaguely pointing into the right direction, but most often not.
May this help someone in the future, so the two development days wasted on this issue may be beneficial to someone else.
Armin.