I see that there's a test build which fixes a 'problem with the copyright symbol'. Can you please give some more details about what precisely went so disastrously wrong? The outcome is that I seem to have 273 .RC and .RES files in my Delphi folders which now contain a C instead of the copyright symbol. In addition, the Product Version has been overwritten with the File Version (in our case they are always different). And there seem to be some other differences as well. For any project that has been opened in Delphi after building in FB7, these incorrect settings have been added to the .DPROJ file.
This is going to take some time and effort to recover from! I have a fairly recent backup VM which I can mount to run Beyond Compare against, but it's going to be tedious.
It gets worse: I have downloaded the 549 build, and although the copyright symbol is now corrected, my product version is still being overwritten with my file version, and a compile date and time is being added, together with blank fields for Comments and Original Filename. I do not want this information visible in resources.
When I check the box "Load Settings from Project File" and also check 'Version Info', this is because I want my own version info loaded from the Project file. I do NOT want stuff changed and added to it in the output executable or in the RC file.
I realise that some people may be delighted to have a compile timestamp added, but please make it an option, and please fix the problem of overwriting the product version.
I can only apologise for this issue, I totally forgot about the option to use the settings from the project file when testing build 549.
The linking of the product version to the fileversion and the compiledate are optional when version information is controlled from FB(and default to on) however there was no way to control this when using the above mentioned setting. In the next build, when using the version info from the dproj file the options behave the same as the IDE, ie the product version string is what ever is in the dproj, compile date is off (and there is no option to turn it on, as is the case in delphi).
The empty Comments and OriginalFileName seem to come from the f*ked way that the Delphi IDE manages version info. When you open a project in delphi, it loads the resource info from the .res file, and updates the dproj with anything that wasn't there. When you delete a version info string from the project in delphi, it deletes it from the res file, but it is still there in the dproj file.. and it seems the only way to remove it is manually editing the dproj file.
Managing version information in delphi projects is far harder than it should be. I suggest to anyone I talk to about this that you should let FinalBuilder fully control the version information and ignore what is in the delphi project files, that way you can always be sure what is going to happen just by looking at the action in FinalBuilder. The option to use the version info from the project files was added a few years back at the request of a user (don't remember who exactly), but it's one of those cases where I should have stood my ground and not implemented it (I did resist for a while).
Do you not use version control for your source code? If so then it should be simple to revert the dproj files back to previous versions.
I have attached a simple fb project which creates a fileset of dproj files by recursing from a root folder. First it creates a backup of the dproj file (appends .backup to the filename). It then (optionally) deletes the project.res file (which finalbuilder will regenerate). Lastly,cleans out any empty VersionInfoKeys nodes in the dproj file (it's an xml file).
We are testing a new build which should be uploaded shortly. I'll post a link on this forum when it's available.
Despite Embarcadero’s efforts to convince everyone that the unicode conversion is simple, there are many gotchas and despite going through our code with a fined tooth comb, writing unit tests etc we still missed some things. Like everyone else moving to unicode versions of Delphi, we are still learning.
Thanks, as ever, for your outstandingly prompt attention, and the fix! Build 561 seems to do the trick.
I completely agree with your apt description of Delphi version info management. It was for this reason that I built (before starting to use FB) some IDE extensions which help us to cope with this. So I have to confess that I may have been among those asking for an option to load the version-info settings unchanged! Moving the file version information (different for each project, and separate from the product version) into FB would decouple it from the action of making the change and make it more error-prone. If we were starting out today with FB’s current capabilities we would probably do things differently.