> > > > 2. Replace the delphi dfm with a real code init (java style).
> > >
> > > What are the advantages?
> >
> > Easier component creation control/management via ONE language.
>
> 1) Please do not forget, that then you will be able to Search /
> Replace on component properties if they are in code! Currently the
> Delphi (and Lazarus I believe) doesn't seach dfm or lfm files when you
> do a normal search.
You can still search and replace - you just store all the design time
components in an
include file.
Instead of design time components via an DFM object file, you use an include
file with
true Pascal code, not DFM object code.
When you search for stuff in your code, the include file is not searched - just
as the DFM
file is not searched when you search in Delphi. The include file hides all the
design time
code so it does not bloat up your code logic with design code.
There are real world examples out there that uses this exact system. KOL/MCK
does it
inside the Delphi IDE, and there is no difference between editing a property of
a MCK
component from editing a property with a DFM component - the only problem was
that Delphi
is designed highly around a DFM system - so KOL/MCK had to implement tricks to
get it
working in Delphi. But with an IDE that is not proprietory, no tricks would be
needed.
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.
> 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.
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.
Now the question is: what does Java do this in its Visual ide's? Does it
create an
include file with component properties stored as real Java code - or does Java
dump all
the code into your Java source files and not modularize it? I'm interested
because I
haven't tried any visual Java ide's. Or does Java use some JFM format in some
ide's ?
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
