What is the best way to split off a new project?

[Jud 1]

What is the best way to take an existing project, leave it exactly as it is, and start a new project (with a new name) from that point?  Save As a new project name doesn't work (files are shared).  You can't just put the files in another folder and rename them.  I've been doing this by starting a new project (VCL) and copy and paste from the old project to the new one, but that is cumbersome. 

 

Is there a better way?

[Rollo62 536]

I use a structure like this, not only for variants, but also for Updates

Packages\Rx1040\PrjVariant1

Packages\Rx1040\PrjVariant2

Packages\Rx1040\PrjVariant3

Packages\Rx1041\PrjVariant1

Packages\Rx1041\PrjVariant2

Packages\Rx1041\PrjVariant3

Src\

 

Src contains all common units.

PrjVariantX contains only the different .dproj, .dpr in the best case,

but may also contain certain bug-fixes to system units or other special units needed ONLY under that specific configuration.

 

 

 

 

 

Edited October 14, 2020 by Rollo62

[dummzeuch 1505]

If you are using relative paths and of course an SCM, you start out by creating a copy of the original project in SCM, check out that copy to a new directory and then simply do all the changes necessary: Rename the project, delete any files you don't need, optionally rename the files etc.

[FPiette 383]

In a set of projects, you have to handle differently the source for each of the individual projects and the source for libraries, components and other common files.

 

I have a common base for everything, then a subdirectory for libraries, components and common files, then a sub-directory for all projects.

The library sub-directory has one sub-directory for each group of sources (A library or component can be made of several sources).

The project sub-directory has one sub-directory for each project.

 

In the sub-directory for each project, I have different directories: for sources, for docs, for dcus, for binaries, for images,...

 

I never use search path in projects: I always add each required unit in the project. This way I see what the project really need.

 

When creating a project which is similar to an existing one, I first work on the existing one to split as much as possible the sources: some which are specific to that project and other sources which will be common. Then I move the new common files to the library directory in an appropriate sub-directory. Then I using the IDE save the project file to the directory where the new project will live and then, using the IDE, I save all specific files to the same directory. This must be done in that order so that the original project stay untouched.

 

 

I tend to have many source files of small size. Each file contain only things that are needed for the file main purpose.

 

[David Schwartz 426]

20 hours ago, FPiette said:

I tend to have many source files of small size. Each file contain only things that are needed for the file main purpose.

 

OT: I have an app that has some tabbed notebooks (pagecontrols) that have a collection of related things on them. Some have their own tabbed notebooks. They are more or less isolated functions and could probably be moved into TFrames or even embedded TForms. But they're part of the main form's overall logic.

 

I look at those chunks of related functions in the source code, say 5 to 15 methods, and wonder if I should move them into a separate unit. I'm not sure they really belong in a separate class, though.

 

I've heard that in C# it's possible to put the implementations of methods of a common class into a separate unit and that the compiler will merge all such units into one at compile time.

 

These methods are part of the main form's object, so I can't easily split them out into another unit.

 

I really dislike having huge main units because the Delphi gods don't think many Delphi users would find it helpful to be able to do the same thing C# allows and move chunks of related code into smaller independent units that get merged in at compile time.

 

Is there something you do by any chance to facilitate this sort of code disbursement?

[FPiette 383]

49 minutes ago, David Schwartz said:

They are more or less isolated functions and could probably be moved into TFrames or even embedded TForms.

I almost always use TFrame or TForm from each page of a TPageControl. And from elsewhere I don't reference the components they are made of. Instead, the frame or form expose properties, methods and events related to what is on the page.

 

Quote

I really dislike having huge main units

I strongly agree with you. Having huge main unit is how newbies are coding.

[Fr0sT.Brutal 900]

17 minutes ago, FPiette said:

Having huge main unit is how newbies are coding

OverbyteIcsWSocket: ~25500 lines 😄

[dummzeuch 1505]

38 minutes ago, Fr0sT.Brutal said:

OverbyteIcsWSocket: ~25500 lines 😄

Mine is longer than yours:

 

XDOM_3_1: 27134 lines

 

That's one of the files I use to test the GExperts code formatter with.

One advantage of having only one huge unit is that everything is in one place. You simply add that unit to your project and that's it. No need to add any entries to the search path etc. But that's not my preferred coding style.

 

But I am sure that somebody somewhere has already hit the maximum file size of the IDE or the compiler (if there is one apart from the obvious 4 GB limit of a 32 bit program, I don't know). I have definitely read of somebody who has hit the maximum number of lines in a method.

Edited October 15, 2020 by dummzeuch

[David Heffernan 2345]

This is a branch or a fork in your SCM system. If you aren't using SCM then that's your problem right there. Solve that problem first.

[Fr0sT.Brutal 900]

1 hour ago, dummzeuch said:

Mine is longer than yours:

That was a joke. The unit I mentioned is one from ICS library which was created by Francois himself.

I don't practice making huge units neither. Probably the biggest is SimpleXML which I adopted and deeply modified and it has only 6500 lines.

Edited October 15, 2020 by Fr0sT.Brutal

[David Heffernan 2345]

1 hour ago, dummzeuch said:

Mine is longer than yours:

 

XDOM_3_1: 27134 lines

 

That's one of the files I use to test the GExperts code formatter with.

One advantage of having only one huge unit is that everything is in one place. You simply add that unit to your project and that's it. No need to add any entries to the search path etc. But that's not my preferred coding style.

 

But I am sure that somebody somewhere has already hit the maximum file size of the IDE or the compiler (if there is one apart from the obvious 4 GB limit of a 32 bit program, I don't know). I have definitely read of somebody who has hit the maximum number of lines in a method.

I have a unit with 53kloc (hangs head in shame)

[FPiette 383]

2 hours ago, Fr0sT.Brutal said:

2 hours ago, FPiette said:

Having huge main unit is how newbies are coding

OverbyteIcsWSocket: ~25500 lines 😄

😞

 

OverbyteIcsWSocket is not a main unit. And it includes 18 other units (not counting the standard Delphi units). The first code line is line 4800. There are THOUSANDS of comment lines. The rest is what is really necessary to have a significant socket class which serves as the base for higher protocols.

 

The first version of OverbyteIcsWSocket  is dated April 1996. Probably today, 24 years later, I would not write it the same way. I gained some experience during all those years after all.

[aehimself 396]

On 10/15/2020 at 8:17 AM, David Schwartz said:

But they're part of the main form's overall logic.

That's a lesson I learned through a number of painful refactorings. NEVER put business logic to UI controls.

 

On 10/15/2020 at 8:17 AM, David Schwartz said:

and move chunks of related code into smaller independent units that get merged in at compile time.

Like...

Unit Helper;

Interface

Function MyFunction: String;
Procedure DoSomething;

Implementation

Function MyFunction: String;
Begin
 Result := 'Hello, world';
End;

Procedure DoSomething;
Begin
 Sleep(1000);
End;

End.

And then just put Helper in the uses classes of your form, and simply call ShowMessage(MyFunction); ?

 

[David Schwartz 426]

On 10/17/2020 at 4:44 PM, aehimself said:

Like...

And then just put Helper in the uses classes of your form, and simply call ShowMessage(MyFunction); ?

 

No, they're not that independent. I think I mentioned they do refer to some data vars in the main form as well as a few screen elements (although those are usually hidden inside of methods).

[Jud 1]

Sorry, I was overwhelmed by the number of responses and haven't been able to get to them (yet).  I know that you can't simply copy the files to another folder and rename them.  I know that you don't need the DSK file because the IDS will make a new one.  Also, saving the project with a new name doesn't work because of problems with file names.

 

The day after I posted the question, I needed to do this.  This is what works for me, but it should be easier:

 1. Start a new Windows VCL app
  2. Save it with the new name in a new folder
  3: Compile to generate the RES file (etc)
  4. Temporarily rename the forms to the same name as the old ones
  5. copy and paste the VCL components from the old forms to the new forms
  6. Compile for good measure, to make sure all is OK (probably not necessary)
  7. Copy and paste the source code after the UNIT statement to the new source
     files; delete what was in the new file except for the UNIT statement.
  8. Compile for good measure
  9. Rename the forms as desired
  10. Set the events - make sure the OnClick of buttons go to the right place, etc
  11. Compile
  12. Make changes to the new project

 

[xstrider 1]

Wow, looks like a lot of work that way. I do it this way:

 

- 'save as' for the project file

- 'save as' for every unit in the project (you can mark them all in the project window)

- manually copy files like icons or ini-files to the new location

 

Would be nice though if there were a project mover tool.

[Lars Fosdal 1792]

Make sure that any unit or resource path in the project has a relative path and/or use internal environment variable overrides.

That enables you to safely copy the project folder to a new folder.

If you are going to copy/paste a form from an old project to a new project - why rename the form at all? 

Can't the form be reused or be made to be reusable?

 

 

[Jud 1]

On 10/19/2020 at 3:49 AM, Lars Fosdal said:

If you are going to copy/paste a form from an old project to a new project - why rename the form at all? 

Can't the form be reused or be made to be reusable?

 

 

The purpose of renaming the form is that in the original project, the forms have specific names.  Starting a new VCL project names it Form1, etc.  If you just paste code into the new one, every reference to the old form name will cause an error.  The best way I know to avoid that is to rename the new form from Form1 to the same name as the old form - that avoids all of the errors.   And generally there will be changes to the form once it is in the new project.

 

Thanks for all of the replies.

Edited October 24, 2020 by Jud