Mattias Gaertner wrote 5 lines
> * If a component changes, a simple "search and replace" can fix all
> your code.
This works in lfm too, doesn't it?
I don't know, Delphi didn't. Does it search LFM's when you do "Find in Files" and select "all files in project"? I thought it doesn't. I meant search and replace all files in a directory or all files part of a project - not just the current file in the editor.
One unit to rule them all ...
I guess, the code observer will give a lot of hints for these files. ;)
Oh yes it does. I tried to add exclude rules but gave up after a while. ;)
Do you know that the lrs files can now be deleted? Lazarus can auto
create them in the output directory.
I read something like that a while back. Very handy.
Show quoted text 5 lines
> * 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. ;-)
Can you give an example?
It's just a pet peeve of mine when I see code as follows:
lvar := EditUserForm.edName.Text;
Compared to:
lvar := EdituserForm.UserName;
In the first example, I need to know the form instance name, component name and property name of that component.
Not to mention every label, panel, groupbox etc are visible to the world. I don't design a business object model like that (all properties default as published), so why must I design my forms like that?
Then again, the forms in my applications are completely empty (almost). They are pure visual display of business objects. If I want to access the Username, I rather do it via the business class and not the GUI layer. What would happen if I wanted to create a web version of that rich client application. No code in the GUI layer, means a much quicker port to a web version. But hey, now I'm drifting to another topic here.
Why write a sophisticated hiding when you can avoid all the problems
and put it into a separate file? See below.
That's actually true... I got the idea from Visual Studio and C# which folds the auto-generated form designer code by default. But then Visual Studio does use include files. ;)
But then again, if you use include files you might need two of them. One for the Interface section and one for the Implementation section. Or roll them into one, but then you have to use some IFDEF trickery as follows...
Interface section...
{ This lets us use a single include file for both the Interface and
Implementation sections. }
{$define read_interface}
{$undef read_implementation}
{$IFDEF DUnit}
{$I DUnitCompatibleInterface.inc}
{$ENDIF DUnit}
Implementation section....
{$undef read_interface}
{$define read_implementation}
{$IFDEF DUnit}
{$I DUnitCompatibleInterface.inc}
{$ENDIF DUnit}
.... and then the include file
============[ DUnitCompatibleInterface.inc ]============== {%MainUnit fpcunit.pp}
{$IFDEF read_interface}
class procedure Check(pValue: boolean; pMessage: string = '');
{$ENDIF read_interface}
{$IFDEF read_implementation}
class procedure TAssert.Check(pValue: boolean; pMessage: string);
begin
AssertTrue(pMessage, pValue);
end;
{$ENDIF read_implementation}
==============[ end ]==================
Also if you use a source code management system like SVN or Git, it means your form history is now split over multiple files and not a single file. Though I guess this is not a major issue really.
So it rewrites the whole sections. That avoids a lot of problems.
Yes.
How much 'pascal' does the reader understand?
IFDEFs?
No
Expressions?
No, unless the property is one of the "unknown" properties, then it works fine.
With statements? Nested with statements?
Partial... The form designer generates with statements as a start - it looks neater and I don't have to debug that code (tooltip debugging doesn't support with statements).
Here is some sample code written by the form designer...
=====================================
procedure TSystemLocksForm.AfterCreate;
begin
SystemLocksForm}
Name := 'SystemLocksForm';
SetPosition(310, 242, 397, 256);
WindowTitle := 'System Locks';
grdLocks := TfpgStringGrid.Create(self);
with grdLocks do
begin
Name := 'grdLocks';
SetPosition(8, 8, 381, 208);
Anchors := [anLeft,anRight,anTop,anBottom];
FontDesc := '#Grid';
HeaderFontDesc := '#GridHeader';
RowCount := 0;
RowSelect := False;
TabOrder := 0;
end;
btnRemove := TfpgButton.Create(self);
with btnRemove do
begin
Name := 'btnRemove';
SetPosition(8, 224, 92, 24);
Anchors := [anLeft,anBottom];
Text := 'btnRemove';
FontDesc := '#Label1';
Hint := '';
ImageName := 'stdimg.remove';
TabOrder := 1;
OnClick := @btnDeleteClicked;
end;
=====================================
What about datamodules?
I don't use them. I use tiOPF for database applications.
What about VFI?
No, but I do have forms that reuse frames (embedded forms).
Like I said, the fpGUI UI Designer is crude. It was simply to help me design forms visually because hand coding them took to long. It is a stop-gap until I can implement MiG Layout Manager. I have no intention to implement yet another full-featured form designer or IDE. Lazarus IDE already works perfectly for me.
I vote for an include file. This way the reader/writer can work even if
there are errors in the unit. Just imagine, you want to save your work
and the IDE tells you have to first fix your code.
True, but fpGUI UI Designer already ignores everything outside the comment markers. So if the rest of your code doesn't compile, you can still edit your forms.
Regards,
- Graeme -
_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
