I can change the release version from 0.9 to 1.0 in Delphi VCL, but it won't stick, and reverts back to 0.9 when I re-enter the Options / Version Info. How do I fix this?
I would recommend to create your own version resource and include it.
This makes you completely independant of the delphi version information settings and makes sure that it is always consistant also when compiling from the command line without using the .dproj file and you can use it for multiple exes if your project contains more than one.
Here please find detailed information on how to do it. It is easy.
Related
When I need to move to a new build of Indy 10, the instructions are to remove files in all sorts of places, download, reinstall, etc. Even when the version itself does not change. I get very nervous about this, since things have gone wrong in the past and I am not at all familiar with packages.
I am not using the IDE components. Is it an option in that case to just add the Indy source files to my project and let Delphi do the compilation/linking?
Delphi 10.1 Berlin; Indy 10.6.2 build 5341.
Yes, you can do that. You need the packages only if you want to install the components into the IDE.
Simply add the source code to your project(s) and you are ready to go.
I would still make sure to remove any old Indy sources and DCUs from the search path(s) in the IDE to avoid compiling stale sources (in particular: Ancient include files). It has burned me too many times.
I write a lot of components and libraries for Delphi, most of which require the use of BPL Packaging so that they may be installed into the IDE.
This is simple enough and works well, right up until you want to maintain a single set of Package Project Files (in a single Project Group), but also want to compile and distribute those same packages for different Delphi versions.
Up to now I've been creating a different Package Project for each version of Delphi, and explicitly defining a Delphi Version Identifier as a suffix (e.g. Kinect_XE.bpl and Kinect_XE2.bpl).
I am aware that, in the Project Options for a Package Project, under Description, there are the fields LIB prefix and (more importantly for my needs) LIB suffix.
I am further aware that if I place a value in LIB suffix, it'll be appended to the end of the compiled BPL's filename.
My question, however, is first whether it is possible to have the IDE automatically populate the LIB suffix field with the IDE/RTL Version number, and if so... how?
I'm fairly certain this is possible, as it would appear that vcl120.bpl (and its counterparts for each respective version of Delphi) can be Referenced (as requirements) of your own packages using just vcl rather than having to type the full vcl120. It is, in fact, this same behaviour I'm hoping to achieve... where my packages can intra-reference eachother (as neccessary) without having to provide version-specific references to accommodate the suffixes.
Equally important is that resolving this will enable me to maintain a single set of Project Files in a single Project Group (with the obvious exception of XE2 where its Project Files don't necessarily behave very well with previous versions of Delphi due to the Platforms addition).
I suspect that I may need to put a value like $(VER) (or something similar) in the LIB suffix field, but this appears not to work and I've scoured Google looking for the correct solution.
Hope you can help!
UPDATE 1
I am now writing an IDE plugin to be used with (in the very least) Delphi 2007 to XE2, which gives DLL and BPL projects a new option called AutoSuffix. When toggled On, any IDE with the AutoSuffix plugin installed will immediately apply the correct IDE version suffix to the project.
The AutoSuffix plugin will be made available (freely) for everyone within the next 24 hours, and this question updated accordingly.
UPDATE 2
Okay... Delphi 2007 is being a pain! I've made AutoSuffix work with 2009 to XE2, so far, but 2007 requires a little more time (patience appreciated).
UPDATE 3
It would appear as though Embarcadero have heard our collective cry for simplier package unification between versions.
Mark is going to push this through to see if future versions of Delphi can accommodate a {$LIBSUFFIX AUTO} feature. I hope to hear back very soon whether this will be the case. If so, it certainly affects the way AutoSuffix will need to work on XE2 and older versions (as presently it doesn't provide the simple AUTO switch.. it has its own method).
My hope now is that EMB will take this request seriously, provide it as an integral feature going forward, so that it becomes a simple case of using AutoSuffix on existing versions to unify the process accross all versions!
AFAIK for Delphi up to XE2 there is no automatism for doing this.
Concerning the requires clause: when you require another package you are actually using the dcp, which doesn't inherit the LIBSUFFIX. Thus it is sufficient to require VCL.dcp during compile time, while VCL160.bpl is actually used during runtime. The DCP includes the complete BPL name to resolve that.
This makes the LIBSUFFIX approach superior to the simple "rename the package for each version of Delphi" one.
A solution like that suggested in QC83229 would make it easier to port a package to a newer Delphi version, but then you are still stuck with dproj files that are not backwards compatible.
I normally use different folders for each Delphi version, where only the project files are stored. For a new Delphi version I only have to copy a folder and change the LIBSUFFIX.
LIBSUFFIX directive is in *.dpk file, and you can edit *.dpk file manually.
You can write, for example
{$IFDEF CONDITIONALEXPRESSIONS}
{$IF CompilerVersion = 20.0}
{$LIBSUFFIX '120'}
{$IFEND}
{$IF CompilerVersion = 21.0}
{$LIBSUFFIX '140'}
{$IFEND}
{$ENDIF}
The bad thing is that IDE does not respect your manual edits of *.dpk file and deletes them then you make changes in a package. That is why some component vendors that use conditional defines in *.dpk file say in installation instruction if asked to save changes say 'NO'.
My suggestion would be to add this as a configurable option to project option sets (see QC #86491.) Rather than updating all the packages it would be sufficient to update a single option set file.
In fact, it seems the DllSuffix tag is recognized by the option set files in Delphi XE/XE2. Adding <DllSuffix>160</DllSuffix> to the <PropertyGroup> section of an option set file will cause the suffix to be appended to the package in the project manager. However, you still have to open the project options and click OK in order for it to be saved to the .dpk file.
I agree that it would be extremely useful with this feature (I would think also for the packages in the RTL.)
{$LIBSUFFIX AUTO} feature was added in Delphi 10.4.1:
In previous versions (version 10.3 and earlier) of C++Builder and
Delphi developers building packages needed to manually set their
package’s library suffix setting. The DocWiki “What’s new in version
10.4.1” mentions a new IDE projects option for setting the library suffix:
“Package AUTO libsuffix: packages can now have an automatic version
suffix, instead of manually updating and specifying the right version
suffix with each new release. (The compiler quietly supported this in
10.4, but full support for the feature in the IDE and package project settings is introduced in 10.4.1.)”
Just a quick question for those of you that know. Is it possible to have both Delphi (ver 7) and Lazarus installed at the same time. I want to make sure the Lazarus install will not interfere with my current Delphi install in ANY WAY. I would have asked this on the Lazarus fourms but thought I would get quicker reply here.
Anyway if you have both Delphi & Lazarus installed please tell me any problems you have encountered (if any) thanks.
Chris
Lazarus does not interfere with any version of Delphi, they can live along very happily.
The only interference is for commandline building, both projects have a make.exe file which are not the same.
This is easily solvable by not adding FPC to the path (removing it via control-panel system), and do a
set PATH=c:\fpc\2.5.1\bin\i386-win32;%PATH%
or wherever you installed as first line in your batch files.
I generally don't bother, but a previous employer we did a lot of cmdline building with dcc, and then it matters.
File associations are another, but already named. (but not such a big problem since the project extensions vary (.dpr vs .lpr, .dproj vs .lpi) )
Btw: Other development products (cygwin,mingw, and maybe even VS) have their own respective make.exe files and the same kind of problems.
I currently have Delphi 5 and Lazarus both installed on my Windows 7 laptop. As near as I can tell they don't interfere with each other.
I don't really use Lazarus though, as I prefer Delphi 5 which is what I've used forever.
I have Delphi 2006, Delphi 2010 and Lazarus installed. No problems at all. I am sure Delphi 7 will be the same. The only problem I can see could be the use of .pas extension in Lazarus. I mean because of association problems. But you can use a different extension for Lazarus (free pascal) source files. I think the installer asks you that.
I have Lazarus "installed" on a USB drive. It interferes with nothing whatsoever. It is actually a checkout of the Git repository that mirrors the SVN repository. I installed the latest stable FPC to C:\FPC, and then copied that folder to inside my lazarus source folder, e.g. \lazarus\FPC\ (and then uninstalled the C:\FPC installation), and then whenever I like I build the latest lazarus like this:
X:\lazarus\> git fetch
[...fetch messages...]
X:\lazarus\> FPC\2.4.0\bin\i386-win32\make.exe clean all
[...compiler output messages...]
X:\lazarus\> startlazarus
[...IDE starts up...]
The main advantage of this is that if you find an IDE bug, the source is immediately available and you can make and submit a patch instantly.
We recently converted our long-running Delphi project to Open Source. Multiple people have contributed patches already, which is great, but unfortunately forms and frames when saved with Delphi 2006 (and later) contain new properties in the .dfm that are not handled by older versions. Forms are handled quite gracefully by the IDE ("ignore propery?"), but frames are loaded at runtime and result in errors. Not an option, as far as I'm concerned.
I now removed those properties from the .dmf files by hand, but I am really wondering if there is a more elegant solution. There is no way to save in a backwards compatible format from the new IDE's, is there? Are there existing tools to strip the nonsupported properties from the .dfm's ? Any other elegant solution I am missing?
Normally, with a commercial project, I'd just upgrade the project to the most recent version applicable... but as this is open source I really don't want to loose out on those developers still working on Delphi 7. That includes myself, actually.
The JEDI JVCL project uses a little utility dc.exe (delphi cleaner) and a list of properties in DFMs that are not present in older versions of delphi, mine contains the following text:
*.PopupMode
*.PopupParent
*.ExplicitLeft
*.ExplicitTop
*.ExplicitWidth
*.ExplicitHeight
*.BevelKind
*.BufferDocument
*.DoubleBuffered
*.ParentDoubleBuffered
*.DisableHyperlinks
*.AlwaysEnquoteFloats
*.PixelsPerInch
I run this dc.exe utility from a batch file which cleans my dfms before I commit
changes to subversion. The syntax in my batch file for this is:
dc.exe -s -fd10.txt *.dfm -i
You can grab my stuff at:
http://sites.google.com/site/warrenpostma/files
You can try Andy's DFMCheck. It can automatically open and close all forms and frames in a project, which makes the IDE remove unknown properties (as Marco wrote).
Well, for sake of completeness:
Open the dfms in the oldest Delphi supported, let it remove all unknown properties, change a property and save.
For your purposes, Warren's solution is better, but it can be a workaround. I did it for a while when we were dual D7-D2006ing.
Since Indy is now built-into the install process of Delphi 2009... is there a proper way to 'remove' it so it can be upgraded to the latest from the SVN repo? There isn't an automated option to remove it as far as I'm aware.
The dcu files for Indy are stored separately from the other Delphi units. To stop using them, simply remove that directory from the search path, library path, etc., and remove the source files from the browse path.
You can remove the design-time packages the same as any other design-time packages. Remove them from the IDE configuration, and then delete the bpl and dcp files. (If you just delete the files, you may get errors when you next start the IDE since it won't find the expected files.)
Once the Indy components no longer appear on the Tool Palette, the packages no longer appear on the package list, and compiling a project that references Indy units fails with a "can't find used unit" error, you're ready to start installing the latest version.
As Rob already said: Just remove the direcories from Delphi's configuration. An additional step is required though: After each update, make sure they have not been added again! Some of the Delphi 2007 updates apparently did that and I missed it for quite a while until I stumbled upon a bug that I already thought fixed.
I didn't use Delphi 2009, but in older versions of Delphi the installation of Indy components was optional. So you could try launching the setup for Delphi 2009 and see if there is an option to "Add/Remove features" or something similar and use it to remove Indy.
Also, you can customize which packages should be loaded in a project, so you can simply deselect the Indy 10 one and add the one from SVN on a per-project basis (you can also configure the default configuration for projects).
PS. Indy rocks! :-)