Forum > General
[ANSWERED] Frames - why the difference
Badger:
I've been playing around with frames recently - wish I'd done this a long time ago!!
I have one question. My first attempt was to add a frame to my Form via the Standard toolbar which worked fine. I read about the advantages of creating the frame at run time and gave it a try and again it worked but not until I had expended a lot of energy and pulled out a lot of hair.
The problem I had was that in the first instance I did things like changing the shape and position of the frame and its components from within the program. When I tried to create the form at run time, these actions wouldn't even compile. I finally worked out that just about the only thing I could do to the frame was align. Is there a reason for this difference?
MarkMLl:
The golden rule for frames- IME at least- is that you edit a frame's properties in the form editor window dedicated to it.
Any attempt to edit a frame after it's been placed on another form will, at best, not work as expected.
Frames instantiated at runtime onto e.g. dynamically-created pages of a tabbed notebook generally work well.
MarkMLl
Thaddy:
There is a design reason behind it, although nowadays it got lost in translation:
Frames were meant to be just design-time containers which contents were made part of a run-time container control, like a form or panel, at compile-time. (This was so designed at the Borland campus.)
But as I wrote: frames can nowadays - and even then - actually be manipulated to some extend at run-time and against the intentions: well, a form created at run-time can hold frames, or better its contained controls.
Along the same lines, form inheritance was introduced, but that is even more strict, also by design.
In a professional setting, though, I always preferred form inheritance over frames, because it easier to maintain team discipline regarding general lay-out of an application.
So the design premise of "Frames" was basically that in the run-time code you could no longer refer to a "frame" because it should not be there anymore...
MarkMLl:
But the consensus appears to be that having properties of TFrame (descendant) instances editable at design time is undesirable.
The only properties which can be safely changed relate directly to the position of the instance.
MarkMLl
Thaddy:
Correct. and in line what I just added (posts crossed). I was at Borland at the time, for a short period, but not involved with frames.
OTOH Form inheritance is often a better option, but takes more effort.
Navigation
[0] Message Index
[#] Next page