I just want to straighten this out before I plunge into large scale form or
frame creation :) (dynamically created and assigned to parent panel)
At least in the Delphi IDE (D7) frames seem a little less "efficient" than
forms, i.e.there seems to be abit more flicker when moving frames around
compared to forms. Is this just my imagination??
At runtime - is there any advantage/disadvantage in terms of performance in
using forms compared to frames, especially when they might be nested quite a
bit?
Thanks in advance,
Rael
Have you ever tried to have a TForm parent a TForm in a
SDI application? Not that it can't be done but the VCL
doesn't like it.
> [...] there seems to be abit more flicker when moving frames
> around compared to forms. Is this just my imagination??
I never noticed it but what counts is runtime - not design time.
~ JD
Can you elaborate on this? I use TForms parenting TForms in SDI apps and
see no problems.
Using the VCL version from D6 (actually it's BCB6 but they use
the same version), the parented form was always painted as
inactive and there were other focus issues as well that I
don't recall because I immediately switched to frames.
~ JD
You only get that if you neglect to set the embedded forms Borderstyle
to bsNone. Windows simply does not like caption bars on child windows.
--
Peter Below (TeamB)
Don't be a vampire (http://slash7.com/pages/vampires),
use the newsgroup archives :
http://www.tamaracka.com/search.htm
http://groups.google.com
> Hi,
>
> I just want to straighten this out before I plunge into large scale
> form or frame creation :) (dynamically created and assigned to parent
> panel)
>
> At least in the Delphi IDE (D7) frames seem a little less "efficient"
> than forms, i.e.there seems to be abit more flicker when moving
> frames around compared to forms. Is this just my imagination??
You are comparing apples to bananas <g>. You can move frames around on
the form you drop them on at design-time, but you cannot do the same
for forms since you cannot drop a form on another form at design-time
at all. Moving the design-time frame itself makes no sense, its
position has no relation to where it appear on a host form at run-time.
> At runtime - is there any advantage/disadvantage in terms of
> performance in using forms compared to frames, especially when they
> might be nested quite a bit?
Frames were designed to be embedded (in fact they cannot be used
stand-alone since they need a parent). Forms were designed to be
stand-alone. Frames will automatically register any action lists they
contain with the host form, embedded forms will not. Many of the form
events will not fire when a form is embedded (like the OnKey events for
key preview), forms only work properly when embedded if they have no
caption bar (borderstyle bsNone preferred). On the other hand frames
lack an equivalent to the forms OnCreate event for initialization.
Problems with nesting are about the same with both types. Avoid really
deep nesting, there is a known problem that drastically degrades
performance (QC #42752) on certain operations.
I have completely switched to frames (usually dynamically created in
code, not dropped at design-time) for modularizing my forms.
Ahha.
Thanks.
~ JD
Rael
[...]
> I have completely switched to frames (usually dynamically created in
> code, not dropped at design-time) for modularizing my forms.
Is there a substantive reason other than preference for why you do it that
way? I find I rarely reuse frames so I don't really care about the ability
to have them on the toolbar at design time but I still find it useful to be
able to drop things on them so I can see what they look like before
assigning them to the parent form at runtime.
But you can do that with frames, no problem. The design interface is
very similar to forms. Just don't try to drop additional stuff on a
frame *instance* already dropped on a container.
Which I always do, so that's why I never had problems.