> > Back when I started using delphi, I wondered what black magic was creating
> > my forms for me? Why couldn't I see and tap in to the code that created my
> > forms? I guess curiosity kills the cat.
>
> You can edit the .dfm. Just not the form and the dfm at the same time.
The DFM never told me when the components were created and freed, was what I was
getting at. I wondered, as a beginner, what black magic allocated and freed the
memory to
create those forms. Long ago I was learning about run-time component creation
and I wanted
to modify my design time forms to be run time, by finding the actual code that
freed and
allocated the design time forms. I was looking for the code so I could turn my
components
into run time ones without writing all the run time code myself. I wanted to
peak into
the code and find out where form1 was created and freed.. couldn't do it.
(could have
maybe if I knew about GEExperts component to code tool).
>
>
> > > 2) As anybody accidently deleted a component from a form. Afterwards,
> > > you don't have a clue as the what custom options where set and what
> > > other components it linked to. Have then is lines of code minimizes
> > > this issue (yes Source Control software does help in such cases, but
> > > not everybody uses source control software - poor folks).
> >
> > You still use a component pallette and visual design. You still delete
> > and link components together. All components are still linked to each
> > other the same way. You just link the components through the code instead
> > of through an object format. Take Synedit for example:
> >
> > Synedit1.highlighter:= SynPasHighlighter;
> >
> > Your highligher is linked to your synedit component. Instead of unlinking
> > it and linking it within the DFM file, you do so in the include file with
> > real code in it. There's no difference from an end user perspective who is
> > using the IDE - components being dropped on the forms will act just the
> > same as if you were using a DFM file.
>
> Binary properties can be difficult to set in code.
Like images/resources?
>
>
> > There are advantages and disadvantages of using real code versus using DFM
> > files. DFM files are a cleaner format than actual Pascal code. Real code
> > is easier to peak into and copy/paste than DFM files (but a DFM to code
> > converter can be made). DFM files make the exe bigger in size than run
> > time code, generally speaking.
>
> DFM make the exe smaller. It is the streaming code, that needs quite a lot
> of code. But this is a rather fixed amount. So for big applications or if
> the library is in a .dll/.so the DFM mke the exe smaller.
You say DFM make the exe smaller, period. But you should say - DFM make the exe
smaller in some cases only. :))))
Because I've never seen a DFM exe smaller than a non-DFM exe myself, but I'll
take your
word for it. All the applications on my hard drive are several small and only
some medium
size programs - I make a lot of small utilities with only 1-5 forms in them. I
don't make
many large applications that exist all inside one exe - most of the time I make
a
bunch of small programs - then if I have one large program where I think a
small add-on
would be useful, I make a plug in system. So it depends what the threshold is
where
the DFM does make the EXE smaller, I guess. If it requires that 5-10MB exe size
exist
before you start seeing gains in exe size - that doesn't really affect me..
with the
work I do. I generally like to make the program have a plug-in system once it
gets that
large anyway, so it would actually be more advantageous for me to have a lower
threshold.
Do you know generally what the threshold is before you have seen the exe become
smaller
from using DFM? 5MB? 6MB?
Lazarus is quite a nice and big application and is only 6MB. I would think
lazarus would be maybe 10MB in size, but it is only 6MB. So maybe we are seeing
the
threshold kick in here?
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
