Here's the problem. This is a wrap up of the SELF problem and the OBjects reference…
Hey people,
If you quote the whole previous message (and several times), it's impossible to know what one is answering to. Help bandwidth saving good cause ;-)
In Editor.pp IO have a TEditor class that contains a TMemo (Memo1). If I create te Memo (Memo1 := TMemo1.Create(fmeditor)) I can access the Memo1 reference ONLY in the procedure that it was created in, not anywhere else!
This sounds very strange. Are you sure you haven't a same named local variable or something alike... sometimes, the more obvious the bug is, the most difficult to realize.
If I create the Memo1 in the TEditor.Create function then I get an error when I try to do a Memo1.Show in the openfile procedure or anywhere else I try to access it....
Hmmm... try to store an integer value, typecasting the pointer:
memo1 := TMemo( 666 );...or whatever the trick the compiler needs to eat this. Then try to peek this value doing the reverse typecast from some other point and show it with a writeln. If the value has changed you may be trashing the memory elsewhere!
Is this a problem with my code (using a TStringList to store the fmeditor object) or is it something else?
Sorry I cannot take a deeper look as of now :-(
This is making me think a little. We could use fixed then instead of these darn tables for widget placement.
If only you heard me O:)
Right. We need to send the signal to each child and then in their resize (tcontrol's resize) we need to check their alignment.
Doesn't gtk do this by itself?
I think that a TLISt is already being recorded for each parent and child.
So you aren't doing it yet!! :)
TControl should have a TList to store all its children, accesible by an array property "Controls". This is quite well done in VCL.
I would have liked to make my code work before showing it to anybody else, but I attach it to this message in the hope that it could be useful, at least in order some portions to be c&p'ed.
Be aware that the whole thing doesn't work. Also it's intended to be used with a more complex scheme than that you're currently using, to allow portable code between libraries.
Please notice too that it's untouched for the last three months. The version of gtkcontrols.pp actually in my page is rather modified (it does work BTW).
TControl and a replacement for TComponent (then I was unable to compile fcl) are provided with basic functionality.
And specially... don't laugh at my code!!! :-)
I should really look at the internal GTK code to see how that stuff is implemented.. In this way you could just set the new position during a form resize event.
I've adopted a "prudency" strategy. I store "desired" size and position using them after inserting the control in its parent to put it in place.
When the control is already attached to a parent, I use the gtk functions to retrieve actual size and position since the control could have been moved or resized by other means. It needs more work, though. I think this code is already in my page.
send a RESIZE message to it and then check it's alignment or something and resize it accordingly.
Why not encapsulating gtk boxes as panels? It would work the way as a Delphi VCL TPanel. A little complicated since boxes are here the default and "fixed approach" Delphi's.
I assume we'll want to have a TList or something of all child widgets, then send this mesdsage to each of them..... Thoughts?
My ideas surely will be unuseful without looking at the whole code. I would try to make the orchestra work with few instruments at first and add the rest only when I'm sure the basic melody is tuned. Debugging a big program could be exponentially more difficult than a little one. And having complete basic classes (like TControl) from the beginning, instead of slowly adding functionality could help too.
Just my two cents. Please take this in its worth meassure :)
greetings
Nico