Too many tabs? Too much code?

I've been working on a project that has a number of tabs on the form. With two or three tabs, the full code for these can be included in the forms unit without a problem. But when you are adding more and more tabs, either you are going to have to rethink your user interface or have one big mother of a unit with a gazillion lines of code.

There is another way that I learned a number of years ago - place each tab on a different form. "What? But that's nonsense Steve, you've been smoking something!", I hear you say. Not so. Follow along for a tricky bit of coding.

Create your form with all your tabs - just don’t put anything in them for the moment. Now for each tab, create a totally separate form, place a TPanel on the form and align it to Client. Give that Panel the same name for each form so you'll remember it, like MainPanel. Then create all your components onto the MainPanel and add your logic code to that form.

Now, going back to the main form with all the tabs, in the OnChange event of the Tabs, place something like the following code...

procedure TfrmMain.pcMainTabChange(Sender: TObject);
begin
    case pcMainTab.TabIndex of
        1: FrmOne.MainPanel.Parent := tsOne;
        2: FrmTwo.MainPanel.Parent := tsTwo;
        3: FrmThree.MainPanel.Parent := tsThree;
    end;
end;

And there you have it. Simple isn't it?

the tsOne, tsTwo etc are the names you can give to the individual TTabSheet you want the form's components to appear on.

What is happening here is that you are changing the parent of the MainPanel to the TTabSheet of the tab you want it to appear in. By changing the parent, you are actually telling it that it now lives on that new tabsheet instead of the form. All the code will still apply.

All the logic code for each tab is in a separate form, kept tidy and easier to follow.

You can add code to create the form at runtime if you wish, but remember to free it again in the OnChanging event.

God bless and have a wonderful day.

Accessing multiple edit Components

I was asked by a friend how he could access all his components without a long and hard to maintain list in the Source Code. He had a number of Edits on his form and he wanted to add all the edits up, knowing the were all set to receive integer values.

Here's how he can do it...

function GetEdits : Integer;
var
    i : integer;
    comp : TComponent;
begin
    result := '';
    try
        // fMain is the main form.
        for i := 0 to fMain.ComponentCount - 1 do
        begin
            Comp := fMain.Components[i];
            if (Comp is TEdit) then // its an edit component
                if (Comp as TEdit).Text <> '' then
                    Result := result + StrToInt((Comp as TEdit).Text);
        end;
    except
        result := -1; // Oops, that edit was not a number
    end;
end;

But I don't wanna Project Group!

I've been head down on an important change to the system so have reluctantly put aside the blog. Have no fear though as I am back onto it again.

While I was working away I came across a Delphi frustration that caused some concern. I've only recently taken over a very large amount of code from a previous programmer who used the "New Directory" theory of version control. This creating a new directory for each release.

His directory structure looks something like this...

\ProjectName\01a\
\ProjectName\01b\
\ProjectName\01c\
\ProjectName\01d\

When version 01d is released, the entire directory would by copied into a new ..\01e\ directory and work would continue there.

This works fine until I set up proper version control here. However Delphi starts to insist on changing code in the previous directory even when you are working on the new one. It also starts to insist - yes absolutely INSIST, that it must create a Project Group that includes the project in the old directory.

To get around this, I deleted the *.dsk file. These are text files that hold specific directory information that Delphi uses. Delphi will recreate this file when it next loads.

Some have suggested that I also delete *.cfg and *.dof files as well, but so far these files have been innocent.

Development Tools

Having looked more into these development tools and this is my recommendations for going forward.

Issue Tracking.
Although Jira is a great tool and I highly recommend it, the expense is perhaps too great for somthing that has not been used in an organisation before, and therefore the benefits may not be known.

I will be looking closely at Gemini (http://www.countersoft.com/Default.aspx?PageID=10). It has a free 10 user configuration and seems, at least on the surface, to be a very effective and comparible tool. I'll let you know how it goes.

Version Control
After reading up about Microsoft Visual SourceSafe, I have decided not to go with this product either. There are more than several reports on its viability on large databases of code.

I will also be looking at Subversion. I hear its not as simple to use as SourceSafe but is free and has some very strong support amongst others I know. One quote I had was "I even resorted to reading the [words deleted here for family reading] manual, but now I understand it, its really good and simple to use".

Again, I'll keep you posted on how things pan out. If you have any comments or suggestions I'd love to hear from you.

On the move

This will be interesting. I'm on the move to the Bay of Plenty and a new job there programming in Borland's Delphi. Monday, Tuesday and Wednesday this week I was there to spend time with the outgoing programmer.

This seems like a dream job. I live at one of the best beaches in New Zealand, my house is less than 5 minutes to work, and I have a really nice office overlooking a park (all to myself with a couch and an air conditioner and opening windows).

The code looks interesting. The previous programmer has spent a lot of time on that code and I can see how it has grown from simple quick-fixes to full fledged programs being used in the marketplace. A very difficult, but perhaps good time for a new programmer to take over.

The applications are written in Delphi 7 and Delphi 2006. The outgoing programmer has spoken to them about Delphi 2007 so I hope to get that when it becomes available here.

The very first thing that I will be doing on Monday is to get my favorite source code formatter installed "DelForExp" (http://www.dow.wau.nl/aew/DelForExp.html). This allows me to format the code in a way that I can see what goes on.

While I'm certainly not criticising the previous programmer's layout, its MUCH better when I can readily see the code. To do this, I'll use DelForExp and format it to have 4 character indents instead of 2 - at least until I am familiar with the code.

I'll also be installing GExperts (http://www.gexperts.org/). GExperts is not a necessity (not like DelForExp), but it is a good tool that can certainly come in handy.

I'll also argue for a version control system. Here I'll go against the grain for some folks and recommend Microsoft's own Visual SourceSafe. I know, I know, no real branching etc. but it does what is required with the minimum of fuss (I have no link for this, you'll have to scan the Microsoft site to find it).

As the programmer was continually being interrupted with requests for changes and bug fixes and future ideas, I have already set one or two people there to have a look at JIRA (http://www.atlassian.com/software/jira/). I have used Jira in a large multi-programmer environment for the past year and I am very impressed. This issue tracking system will be able to take the pain out of remembering and processing bugs, new features, releases, discussions, process help desk issues, prioritise work, and process all the work flows that go behind all that. Try it, I found it one of the best.

Well that's about all for now. The truck comes to take my stuff out of my Auckland apartment in the morning and delivers it the next day to my new home in Mount Maunganui so I have lots of other things to do.