[DUG] unit source code size

[John Bird]

This is a very interesting topic - I would love to hear others ideas of 
organising source for big projects, and any other web references.

My quick thoughts:

Note as far as the Delphi compiler is concerned it is fine with units of 
thousands of lines, its still a one pass compiler, and if the IDE can allow 
you to jump to declarations of anything and find references it is still very 
usable

However in general there are lots of good reasons to separate UI and any 
processing code.

I know of two approaches - Model/View/Controller   where UI units events all 
call business unit functions of business classes in their own class units, 
and all data control details are separate in a datamodule.

Less separated is a UI where all event code is either a bit or very 
separated from all involved processing logic.

Even detailed and useful UI additional code can be separated from the UI 
(example below)

If I have more than a few lines in an event., I instead move the code into a 
separate procedure,

eg a button click might look like:

procedure TfrmJBPleditdb.btnSaveCodeClick(Sender: TObject);
begin
  SaveCodeDescList;
end;

Depending on what I want to do this routine might either still be in the 
form unit, but already can be called by other events on the form- eg from a 
DoubleClick.   Once it becomes more generally useful I move it into a 
library unit and it can be called from anywhere, probably with more 
parameters.

Or it could be an action of which the execute method gets called in an 
event - this also provides a way of abstracting the functional code from the 
UI unit.

Sometimes such abstracted functionality is still just to do with the UI 
even,  as an alternative way to making descended components - because the 
standard VCL components can  be used and extra functions can be easily added 
to them only when needed  down the track.  Here is an example which adds a 
search facility to any stringgrid.


procedure Tform1.strgrdSearchKeyDown(Sender: TObject; var Key: Word;
  Shift: TShiftState);
begin
  if (key = $43) and (ssCtrl in Shift) then
  begin
    CopyThisLine(strgrdSearch);   //CTRL+C
  end;
  if (key = $46) and (ssCtrl in Shift) then
  begin
    xcGridFind(strgrdSearch,FindStr,strFound);    //CTRL+F
  end;
  if (key = VK_F3) and not (ssShift in Shift) then
  begin
    xcGridFindNext(strgrdSearch,FindStr,strFound);    //F3
  end;
  if (key = VK_F3) and (ssShift in Shift) then
  begin
    xcGridFindPrev(strgrdSearch,FindStr,strFound);    //Shift+F3
  end;
  strgrdSearch.setfocus;
end;

The functions (Copythisline, xcGridFind etc) these call are in a library, 
which can be anywhere convenient, either in a class definition/business 
logic unit or in a standalone code only unit

eg

procedure xcGridFind(pGrid:TStringGrid;var pFindString:String;var 
pFound:Boolean);
var
lrow,lcol,rowptr,colptr,lposn:integer;
testcell:string;
begin
  lrow:=pGrid.Row;
  lcol:=pGrid.Col;
  pFindString:=pGrid.Cells[lcol,lrow];    //default to current cell contents
  pFindString:=inputBox('Find:','Text to find:',pFindString);
  pFound:=false;
  if pFindstring='' then exit;
  for rowptr := lrow+1 to pGrid.rowCount - 1 do
  begin
    if rowptr>= pGrid.RowCount-1 then break;
    for colptr := 0 to pGrid.ColCount - 1 do
    begin
      testcell:=pGrid.Cells[colptr,rowptr];
      xcstrin(testcell,pFindstring,lposn,1);            //this is a wrapper 
for AnsiPos making it non case-sensitive
      if lposn>0 then
      begin
        pFound:=true;
        break;
      end;
    end;  //col
    if pFound=true then break;
  end;  //row
  if pFound then
  begin
    pGrid.Row:=rowptr;            //position at the found cell
    pGrid.col:=colptr;
  end;
end;

In my case some of these library units might easily be 10000 lines+, but its 
not an issue either to me or the compiler, I can find stuff easily and the 
compiler only compiles and links the functions or procedures required,  all 
I have to do is add a useful library unit to the uses clause.


John