On Tue, May 5, 2009 at 2:30 PM, Mattias Gaertner <nc-gaert...@netcologne.de> wrote: > > If you don't like the lfm format, write a TReader/TWriter for your > format.
I don't have issues with the LFM format, it's the extra file I have an issue with, plus a few others... see below. > Yes, this has the big advantage of better smart linking and that the > compiler checks the properties. Correct. Plus the following... * If a component changes, a simple "search and replace" can fix all your code. * One unit contains everything. No need for .pas, .lfm and .lrs files. * Not all form / component properties in the form need to be published. I like my components and event handlers private and only surface what is truly needed. It's called good OO design. ;-) * No need for an automated global form variable. * I can define forms or dialogs in the Implementation section as well. > It has the disadvantage that programmers will more likely try to > edit it. Hence the reason for feature request #13514. Regions that can be folded by default when opened in the editor, so I can hide the automated GUI generation code. If the developer knows what he is doing, then by all means allow him or her to edit the code manually. Who hasn't edited a *.lfm or *.dfm file every now and again. ;-) Though Lazarus is a lot more tolerant when it comes to error handling compared to Delphi. :-) http://bugs.freepascal.org/view.php?id=13514 > Does the fgui designer keep user changes or will it rewrite > the whole file every time? I launch the fpGUI UI Designer from inside Lazarus IDE using the current editor file (setup via Tools menu). The designer keeps track of changes internally and only saves the file once, when the user selects "File > Save". Once your quite the form designer, you are return to Lazarus IDE, which that auto detects the file change and prompts for a reload. This works brilliantly. Lazarus IDE is great! The fpGUI UI Designer uses comment markers to know what to read and edit. Other code is not touched at all. > I was thinking about writing a TReader/TWriter for pascal code, but it > has low priority at the moment. Interesting. Where would it save that pascal code? An external file (maybe an include file) or directly inside the .pas file? > Multiple forms per unit makes error handling much more complicated. > The one-form-per-unit concept is easy to understand and not a big > limitation. Just like the java one-class-per-file limitation. I limit myself to one form per unit as well (in my own projects). It only came in handy when I designed the fpGUI standard dialogs in the fpg_dialog.pas unit (similar to Lazarus's dialogs.pp unit). > Ehm, this sounds as if you don't use RTTI for streaming. > How does the fgui designer work? No, it doesn't for streaming. :-) I only use RTTI to detect if properties of components contain non-default values. So I can limit to generated code. The UI Designer is crude, but effective for it's needs. It's not designed to be a Delphi or Lazarus form designer - but it's still very effective. Each component I want in the form designer registers itself, what properties must appear in the object inspector and optionally and property hint. The properties that are not registered are still accessible in the object inspector via the "unknown properties" memo. For the latter you can't see visual change, but they will be there at runtime. Each property type (boolean, integer etc.) has a class that knows how to read or write object pascal code. There also exists property designer for more complex properties like Columns in a StringGrid. And in case I haven't registered a visual component with the designer, you can always fall back to using the special TOtherWidget component. When placed on a form it pops up and asks for the name and base class. You can then use the "unknown properties" memo to fill in any extra property values. A nice "catch all" feature. ;-) ================== // ComboBox wc := TVFDWidgetClass.Create(TfpgComboBox); wc.NameBase := 'ComboBox'; wc.AddProperty('FontDesc', TPropertyFontDesc, 'The font used for displaying the text'); wc.AddProperty('Items', TPropertyStringList, ''); wc.AddProperty('ParentShowHint', TPropertyBoolean, ''); wc.AddProperty('ShowHint', TPropertyBoolean, ''); wc.AddProperty('TabOrder', TPropertyInteger, 'The tab order'); wc.WidgetIconName := 'vfd.combobox'; RegisterVFDWidget(wc); ================== So yes, I believe this is a very different design to what Lazarus IDE follows. Programming is great - a 101 ways to accomplish a similar task. :) Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
