Jolyon wrote: Whilst I agree with the rest of your comments about keeping forms and business objects separate - this one caught my attention:
> This facility was afaik originally created to fix a > shortcoming in .NET which was the lack of separate resource > files to store form designs (i.e. no DFM's). Form designs > were expressed as procedural code to construct the form > object controls etc, and thus required an IDE/tool maintained > section to be embedded in your application source code. Personally, I don't see this as a shortcoming of .NET - I think it's an improvement. Storing .DFMs as a weakly bytecoded stream of constructors and property assignments in a separate pseudo-interpreter always struck me as a wart of Delphi - something it 'inherited' from VB's design without reconsidering it in the clear light of day. As least they partially saw the light and switched to text .DFMs which are only converted to bytecode at link time. Delphi could have always generated .DFMs as Delphi source code instead which it compiled and included. The advantages to .DFMs being a bytecode interpreted resource format always seemed pretty minimal to me. Frames, form inheritance and other later additions would likely have been a fair bit less awkward and fragile too. So it doesn't surprise me that Anders took the opportunity to revisit that design decision when he designed .NET. Cheers, Paul. _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
