This page is "browser friendly". Make your browser window as wide as you want it. The text will flow nicely for you. It is easier to read in a narrow window. With most browsers, pressing plus, minus or zero while the control key (ctrl) is held down will change the texts size. (Enlarge, reduce, restore to default, respectively.) (This is more fully explained, and there's another tip, at my Power Browsing page.)
Sometimes the project you are planning to write today has much in common with a project you wrote previously.
It is easy to use an earlier project as the basis for a new one. You could probably figure everything out for yourself. But if you'd rather, read on, and take advantage of the fact that I've written out the steps for you.
Some of the advice below assumes you want to use my working practices. In particular, the names of folders, files, objects do not have to follow the guidelines I offer.
First, shut down the Lazarus IDE, if it happens to be running at the moment.
Then create new folder. For this example, I am going to show you how to create an application called LDN004 from one called LDN003, so the folder name would be LDN004.
Use your operating system's usual tools, copy all parts of source project, to the new folder. (The "backup" and "lib" folders do not need to be copied, nor the .exe file, but if it is just easiest to copy everything, it won't hurt. You'll be deleting the copies in a moment, anyway.)
Still assuming that the Lazarus IDE is not running... (close it if it is!)...
Take care that you do indeed merely COPY the parts. (It is easy to accidentally move instead... thus eliminating your copy of the source code, etc... not good... for the application you thought you were creating the clone of.)
All of the rest of this is done in the new folder.
Sidebar: If you are re-working an old, old project, you may not find the ".lpi" file I will mention shortly. If you don't, be particularly careful about backups, allowing you a recent "known good" version to fall back on. If there is no ".lpi" file, I hope you at least have an ".lpr" file. Use that in place of the ".lpi". if you have both, use the .lpi.
These techniques worked well for me 6/23 (Windows 10, Lazarus 2.0.0). The same techniqes that were "old" at 11/17! (Windows 7 and Lazarus 1.6.2.)
I have been using these techniques for a long time. No hassles. I don't think I've recently tried to clone from a project that had no .lpi file. They do work, even with .lpr, if that's your only option.
But work carefully! It can go wrong! In messy ways. Especially if you failed to make the separate copy, and work only with that.
If you accidentally launch the programming process by double clicking an .lpr file, when an .lpi is also present, you risk All Sorts Of Weird Stuff. Weird stuff which can "back annotate" (change) the "original", "main", copy of the code you are creating a new app from... I think. At least something like that happened to me a while back, more than once, and it gets Very Messy! (If in doubt, create a backup of the stuff you are working from before you try to create the derivative app. Just in case.)
1) While being careful that you are working with the copy in the LDN004 (or whatever you've called the new app) folder, double-click on the .lpi file. (Or .lpr file, if you don't have an .lpi file. ) That would be LDN003.lpi (or LDN003.lpr) in my example. Lazarus should open.
1b) Open the main unit of the project, the ".pas" file, if it isn't open already.
1c) It would be best of you were trying to clone something that will at least compile? Use Run/Quick Compile to make sure. (Don't use the alternate, "Compile", just yet.) It doesn't matter if you get WARNINGS. It doesn't matter if the code doesn't quite do what you want it to... but if it won't compile, the following may not work for you. But it might... press on, if you for some reason don't want to "touch" the project you are cloning.
2) Use the Object Inspector (f11) to change the name of the form, e.g. LDN003f1 to LDN004f1. Be sure to move the insertion point out of the form name edit box, to make your intended change happen. (You can have Upper Case characters here. (They aren't allowed in filenames. We'll discuss that shortly.)
3) Switch back to the window for the main UNIT, the .pas file (f12 once or twice). Click "File | Save As", and save the unit. You can't have spaces in the name, and in some cases, e.g. .pas files, if you use any UPPER CASE letters, Lazarus will, without telling you(!), convert them to lower case.
You can use underscores to turn NameLikeThis to name_like_this. Otherwise you'll be trying to read namelikethis. These "problems" arise, I believe, because Lazarus runs on Linux, Macintosh and Windows. Once you start saving things, using the OS, different rules apply in different places, so a cross-platform app needs restrictions a single platform app can eschew.
(You should be offered .pas as the default extension. If you get .frm, you still have the focus on the unit's form, probably from when you changed its name. Be sure you are in the right folder... you should be.... Save the unit (i.e. the .pas file) under the new name. (E.g. ldn004u1.pas.) You may get a message asking if you want to delete the old unit. Look closely at information in the question, and as long as it is specifying the copy in your new folder, say "yes". (Say no, if in doubt, and delete the copy-in-new-folder of the old .pas file by hand, later. It won't do harm, "lying around".)
You may also see "The unit (xyz) is used by other files. Update references automatically?". Say "Yes", or "Yes to All", if that's on offer.
4) If you created sub-units, (to "divide and conquer" your code, then for their names (and the names of their forms, when present... not every sub-unit entails a form))... Go through all of them, renaming the form and then switching back to the unit, and re-saving it with a revised name. E.g., if there was, say, a sub-unit called ldn003_drawgraph.pas, you would make that ldn004_drawgraph.
There's a "twist" in the tale of doing the above which was not intuitive to me. (Laz 2.0.0)---
I worked across the tabs open in the source editor window. (Be sure there is a tab open for each of your .pas files!)
Click in the next tab. Then press f12, f11. The f12 will switch you to the form for the .pas unit (If it has one! Not all do, of course.) The f11 takes you to the Object editor for THAT form, i.e. the right place to change its name. (If you have some .pas files with no associated form... as you may well do, to 'divide' some subroutine code to 'conquer' it, then you skip the "rename form" part, but you DO still need to resave the file under the revised filename, using the "File/Save As" that you use elsewhere.)
(If the sub-units are generic, "toolkits" you use across various projects, then all will be well, if you just leave the old names alone. But if a sub-unit has "LDN003" in the name, it is an invitation to confusion to use it under that name in LDN004! Give shared sub-units a name that reminds you that they get shared.)
=====
So far, so good, but you need to save the project specification anew as well, not just the .pas unit, which you just did. (You have also already saved the definition of the form used by the .pas unit.)
5) To save the project specification (with the new base name), use the "Project" menu item. "Project | Save Project As...". The dialog will suggest that you are saving an .lpi file, but several other files, (including (perhaps) the wretched .lpr file,) arise along the way. (By the way- if you want to use upper case letters here, it will be okay. (Always "okay", but in other contexts, Lazarus changes them to lower case.))
Almost done!
To see if you were successful....
If you use an ini file with a name derived from the main program's name, at this stage, LEAVE the old ini file in place, but create a copy of it under the new name.
If the cloned project starts up okay, then all is probably well! But don't run it until you read the next two paragraphs!
If you use ini files, go into the code, change the name as necessary. (E.g., for our example, re-code the program to look for LDN004ini.txt rather than LDN003ini.txt). If you used sub-units, you may need to change references to them. (Do a search on "LPN003". Fix as necessary... but beware of changing, say, rems saying that a feature was new in such and such a version of LPN003)
Also rename the "lib" folder "xlib". (It may hold compiled code that is essential to your project which depends on units you may not have "brought forward" into the clone, or may have unwisely put in "scraps". Once you have renamed the old lib to xlib, you may go through a season of failed compiles on the basis of fatal errors, "Cannot find [filename] used by [filename]." As soon as you find, and return the project's main folder, something that was needed, what you've just restored will make its needs known. Sigh. You can do this. The good news is that if you don't use many external units, which is how a novice is likely to work, you won't have this problem!
NOW try compiling, running the app again. (Click the green "Run" arrow on the toolbar, or press f9). A new "lib" folder should appear, if you look at what's in the folder your project is in. The app should compile and run nicely.
Tidy up...
Eventually. Before too long, when you're happy that all is well, you should delete the "Scraps" and xlib" folders. Better to discover sooner rather than later that something inside it is being used somehow! (Perhaps best just to rename it, first, to be on the safe side. Sometimes the operating system will thwart you attempt to hide the files you hope you aren't using... but at least you've tried to catch that situation.)
What Lazarus has taken care of for you is very impressive. It can be forgiven, if a few little odds and ends need to be dealt with.
As I said, use the Lazarus "Search | Find" tool to scan your code for any remaining vestiges of the old application. You may have used the application's name in a comment... which will have to be edited by hand... or, say, in the text of a label, or elsewhere. Again, that will have to be changed to the new name by hand.
I hope you will remember the system described in this tutorial... many times a "new" application can be derived from earlier work. Be a little cautious about using earlier work which wasn't done well... sometimes a fresh start gets you away from corners you painted yourself into previously. However, the more you write applications, the better your code will be, and the more often you will be doing something which can benefit from the work done on an earlier project.
You may also be interested in some notes I've written about things I like to put in every program I write. It shows you, for instance, how to tweak what is in the application's title bar.
Another skill... creating units to be used by many programs... will prove even more useful, once you are working on things that have common elements. I haven't written specifically about creating stand-alone units in Lazarus... because what I wrote in a Delphi tutorial on the subject proved sufficient for my wants.
To search THIS site.... (Go to my other sites, below, and use their search buttons if you want to search them.)
The search engine merely looks for the words you type, so....
* Spell them properly.
* Don't bother with "How do I get rich?" That will merely return pages with "how", "do", "I"....
If you visit 1&1's site from here, it helps me. They host my website, and I wouldn't put this link up for them if I wasn't happy with their service. They offer things for the beginner and the corporation.
How to email or write this page's editor, Tom Boyd. Please cite "lt2c.htm".
Page has been tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org. Mostly passes.
AND passes...
. . . . . P a g e . . . E n d s . . . . .