Lenghthy Procedures

[guest48180]

Before I start whacking away at Unit1, is it possible to take my long procedures and turn them into usable units that Unit1 can use? Like SysUtils and so on that are in the USES portion of Unit1. Just wondering because I have over a thousand lines of code for this one program, and sorting through it is becoming a difficult tangle to work with.

Any help on this will be appreciated.

Landslyde

[engkin]

...is it possible to take my long procedures and turn them into usable units...

Yes, sure! You should do that, and also you should turn your long procedures into more but shorter procedures.

[guest48180]

Yes, sure! You should do that, and also you should turn your long procedures into more but shorter procedures.

I took a long procedure called 'DisplayData' and put it into a new unit called unit1. In my main unit I put that unit shld be used in the USES section, but it's giving me several errors:

identifier not found "TForm1"
class identifier expected
identifier not found "sg1"

etc.

How do I make this new unit and the one procedure in it available to the main unit?

Landslyde

[engkin]

If DisplayData is a member of TForm1, then keep it. and take what's inside it to another unit. For instance, take FillGrid to another unit and make enough modifications to make it work.

Right now FillGrid is declared as:

Code: [Select]

procedure FillGrid(aRowIndex: integer);

If you move it to another unit, you should provide sg1, sg2, and CustRec as parameters:

Code: [Select]

procedure FillGrid(aRowIndex: integer; sg1, sg2: TStringGrid; CustRec: TCustRec);
I don't know the actual type for CustRec, I just assumed TCustRec, you should correct that.

[engkin]

As a side note. To make it easier for you (and others), use better names for your procedures and controls. I would change some names like this:

sg1 :
After reading the code (It should give some idea BEFORE reading the code), I realized that sg1 is dealing with customer details, so maybe a name like CustomerDetailGrid (or at least CustGrid, if I don't like long names).

sg2 :
After reading the code, OrderGrid.

FillGrid :
Fill...Grids, and it should call other procedures like FillCustGrid and FillOrderGrid

[WickedDum]

A rule of thumb that has been used compares files to a page in a book.  A paragraph (2 or 3) generally describe a specific train of thought.  There is white space on the page to improve readability, too.

FORTRAN programmers were taught to make their units 50 lines long. 

Personally?  I make mine units several pages long.  Especially my custom library file...it seems to grow.  (I did break it into two files.)

When you start to add different functionality (or it gets convoluted and difficult to remember/manage), put it in a new unit.  At the top of my main (MyUnit1) file, I list ALL units and a brief description of what they do.  I list them in the order they appear in the flow of the program.

Hope some of this helps.  It WILL get easier!

Have fun!