On Thu, 11 May 2006 12:03:59 -0600
L505 <[EMAIL PROTECTED]> wrote:
> > > > > 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.
You can edit the .dfm. Just not the form and the dfm at the same time.
> > 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.
> 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.
> 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 ?
Mattias
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
