A few weeks ago, our company migrated from Delphi 5 to Delphi 10.3 Rio. After some problems, we've reached our goal to compile our solutions (many EXEs) with the new IDE. We're using DCC32 to compile our projects every day.
Unfortunately, some of them have encountered a visual issue. They are using the old VCL visual style from Delphi 5, whereas others use the newer style.
After much research, we've noticed that every executable that works has a manifest (thanks to ResourceEditor.exe), but the others which don't work don't have any manifest.
Projects seem very similar, no forced manifests files, same compiling way, same resources generator.
It seems that the default manifest (default_app.manifest) located in the Embarcadero directory is used during the generation.
Does anybody know why some EXEs contain this default manifest and others don't have it?
EDIT:
Thank you everyone for all your replies, i'm a bit late but i have managed to solve my problem.
Unfortunately one of our libraries owns a manifest on one of his res file. But some of our applications don't use this library and have this issue.
For those who point the IDE solution, we use dcc32 compilations which, tell me if i'm wrong, don't use the dproj file where the runtime theme is specified. The IDE solution works well but since we use dcc32 compilations, we can't use it.
This is probably an issue with option "Enable Runtime Themes" not being selected (Project / Options / Application / Manifest).
Related
I have developed a Delphi application (XE4) on a Windows XP machine.
When I copy all the project files to a Win 7 machine (also Delphi XE4) it will not compile.
The source has uses Vcl.Grids and the compiler complains it can't find vcl.grids.dcu.
Changing to uses grids works but I don't want to edit all the source.
I've checked the Embarcadero website for information on Namespaces but couldn't find anything useful.
I know it's possible to say uses vcl.grids under Win 7 so there must be some setting somewhere in the project that is preventing the resolution.
I've tried deleting the dproj files but that had no effect.
How do I get the source to compile with minimal changes?
The error has nothing to do with OS. It means your IDE/Projects's search paths are not configured correctly, or your project is missing references to the relevant packages, so double check that.
Also, you can use uses Grids in the code, and then make sure Vcl is listed in the Unit scope names field in the Project Options.
The information that you describe seems to be erroneous. The compiler is not affected by the operating system on which it runs. Running the same compiler on the same source code on a different operating system does not result in compiler errors.
Here are the reasonable explanations for your problem:
You are compiling the code on different versions of the compiler. Your error message matches what happens when you compile modern namespace aware code on XE or earlier.
Your are not compiling the same source code on both machines.
It is extremely hard to see beyond these two explanations.
Ok, red face time. Turns out I was running an earlier version of Delphi on the Win 7 machine. Delphi XE4 was installed along with an earlier version and I was invoking the earlier version.
Once I actually brought up XE4 on the Win 7 machine the issue vanished.
So I will don a hair shirt and crawl under my rock.
Thanks everyone who contributed.
I have upgraded a project from RAD Studio 2010 to RAD Studio XE4. The project is mostly C++ using the C++ Builder half of RAD Studio, with smatterings of Delphi.
Under 2010, the Release build was 22MB. Under XE4, the same Release build is 55MB.
This is a problem because:
55MB is remarkably large for an EXE
It takes noticeably longer to start the program (not much, but some.)
Many of our customers download new versions from remote areas or on board ship while at sea. Size matters.
What could cause this, and how do I fix it?
Notes
Oddly enough, the debug build is still only 23MB. Project settings seem very similar. I diffed an export of the option sets and saw only <UsePackages>True</UsePackages> as something present in Release not Debug; removing it made no difference. Beyond that there's code optimisation turned on and lack of a _DEBUG define.
Debug info is generated for the Release build, but goes into an external .tds file. (This will be used for EurekaLog in future, and currently allows us to debug release builds of the program.) I wondered if the linker was linking in debug info, but as far as I know the C++ linker always places the debug info in an external file, which exists, plus EurekaLog is not yet enabled in the build.
The project files (.cbproj) were created in XE4, not upgraded from old 2010 ones. I made new projects and added the old .cpp and .pas files. This was to avoid issues caused by upgrading - on the Embarcadero forums it's often recommended to create projects anew when upgrading IDE versions. Until this occurred, I had indeed encountered fewer issues than in 2010.
There are many mentions of Delphi XE2+ EXEs being noticeably larger than those produced by old versions of Delphi. (1, 2, 3, 4, 5, 6.) While the C++ linker is different to that used by Delphi, it is possible the causes are similar.
The cause there appears to mostly be RTTI used by the Delphi RTL code, which in a Delphi project can be removed by specifying {$WEAKLINKRTTI ON}. The XE4 documentation does not mention an equivalent C++ linker pragma. There is #pragma explicit_rtti (the C++ analog of {$RTTI}) and __declspec(delphirtti) (the C++ analog of {$M}/{$TYPEINFO}).
The project is linked using runtime packages and the dynamic RTL. It is a 32-bit VCL forms application. I have XE4 Update 1 installed on Windows 7.
Edit: David Heffernan asks in a comment below about the .map file sizes of each project.
The release .map size is 17MB, and .tds size is 80MB.
Debug has now stopped linking, with the linker reporting it is out of memory (an old, old bug that should have been fixed years ago.) There are no .map or .tds files generated and so I can't give a comparison size accurately. From memory the .tds was about 100MB, and unfortunately I don't recall the .map size. If I get the project linking I will update the question.
Edit again: I found the answer (sortof) - turning 'Expand inline functions' OFF reduces the EXE size to the expected value. This is puzzling itself though - see my answer below. Note that the debug build already had this turned off and still won't link, giving an out of memory error.
I haven't marked my answer as correct yet, in case someone can provide some insight into exactly what is going on, which would be a much better answer than just 'turn this option off'.
Solved (sortof.)
The Release build had "Expand inline functions" turned on. Turning this off reduced the EXE size from 55MB to 17MB.
This is an astounding difference and I don't know why the difference is so big. I find it unlikely we have 38MB worth of inlined functions, even counting templates and headers, let alone ones using the inline keyword. If there is a way to examine the linker steps, output, or obj files to see what is being expanded, please comment - I'd find this really valuable.
My general question is how do you troubleshoot "My BPL won't load due to a dependency that just won't go away, no matter how much I clean up and recompile". Update You may think you have a clean recompiled system, but thanks to the inverse-miracle that is Windows and its file system virtualization mis-features, you haven't.
When I try to load my designtime package (in this case named dclFsTee.bpl) into my Delphi IDE (it's the fast report 4 teechart wrapper component package), it complains:
The program can't start because tee7100.bpl is missing from your computer. Try reinstalling ...
That tee7100.bpl is not referenced on any DCP or DCU file on my system THAT I KNOW OF. But clearly, something is wrong, and I can't find the problem.
All Delphi users face a hundred "won't compile or won't load" problems with BPLs. The universal refrain when asked what to do is to clean up your computer.
However, I've now spent hours cleaning up my computer, and while everything compiles file, clearly there must be something out of date hiding somewhere, because the resulting BPL file that I'm trying to load still wants to load a version of a TeeChart BPL that I removed from this system days ago, along with every trace I could find.
The traces of TeeChart stuff in Delphi 2007 that I removed include everything in the $(BDS)\Lib and $(BDS)\Lib\debug folder, and all DCP and BPL folders on the system. Also every TeeChart-unit-named dcu file is gone.
Once you've gotten to the end of the road, what do you try next? (Format the hard drive, buy new computer.) Seriously. I think I'm a smart guy, but I have a 1 tb hard drive, a library path that runs to 80+ folders, and a source code repository that seems to be well organized, but clearly something is hiding where I can't find it.
I have TeeChart Standard 2012, with full source code, and as far as I know, my development machine no longer contains any old TeeChart BPLs or DCP files from the "tee chart tee7100.bpl" version that ships with delphi.
I have run the "recompile.exe" wizard that comes with teechart, which appears to just run MSBuild and build the packages, after writing a {$DEFINE x} declaration to the tee.inc files (there are two of them in the source distribution).
However, somehow, silently it seems like one of the implicit imports into one of the packages is drawing in some stale file which has not been rebuilt, and which therefore tries to load the tee7100.bpl. The new bpl name is tee911.bpl.
Rather than ask the pretty-specific-to-fastreport question, I'm only mentioning it as a specific instance of a general world of hurt that I have faced dozens of times while developing in Delphi.
I'm only giving the fast-report details so you can see that this is in fact a specific instance of a general problem that one faces sometimes inside Delphi IDE when dealing with a component source code or package, or set of packages, with dependencies. Cleaning up your computer so that your code even builds can be tricky.
So here is my Delphi package-to-package-dependency-resolution question:
What is the most effective way to find or trace implicit-load-of-some-no-longer-wanted BPL-problems so that my code (which builds and compiles just fine!) will actually load into the Delphi IDE. The BPL file that results from running Recompile seems to be linking properly to the right DCP files, and no old/stale DCP or DCU files are present. The new DCP file name is tee911.dcp, for instance.
Can you get somehow, any idea of what package is actually stale, and what is being read and linked and imported statically when the .bpl links? (I'm thinking maybe like a special MAP-like file for BPL files?)
Update After many hours of fighting with this, and using every trick I know, I realized I hadn't checked for some VirtualStore related issues caused by file virtualization in Windows 7. That means that Windows 7 lies to the programs that run on top of it. It gives you another version of the file, that isn't the one you want. This can be deadly in several ways; One; You recompile a BPL but that's not the one that loads. The BPL that was killing me was in the SysWow64 folder that was part of the VirtualStore. Note that the virtualstore basically makes phantom files appear that are only there if you're a certain "low privelege" program, which Delphi 2007 on Win7/64 bit, apparently is. To remove BPL files in your SysWow64 VIRTUALSTORE folder for your current user account:
del %HOMEPATH%\AppData\Local\VirtualStore\Windows\SysWow64\*.bpl
... Some days I just hate Windows architecture. Anyways, I'm not going to put the above as the answer, because I'd like to know if anyone has a better way or any tip or suggestion that might help next time.
Okay nobody else answered so I'll put this here to be helpful for future people:
-- Remember Windows VirtualStore when cleaning up broken systems which have old versions of DLLs on them including TeeChart, FastReport, Indy and so on which tend to be involved in messes because they can exist both as "out of box packages that ship with delphi" as well as frequently installed as upgraded versions if you purchased and installed them from the vendors directly, or third, you may have your own compiled copy in your company's mega-component-pack-directory.
-- When searching for duplicate or out of date BPLs, doing a file search in windows doesn't look in the virtualstores, you'll have to locate and zap the whole virtualstore area for your process or user, or program, manually.
The second level of this issue is this:
The dependency graph for FastReports is complex:
It depends on Indy and you might have your own version of Indy, and Delphi itself has one, and other things on your hard drive might have their own copy of Indy.
It supports various editions of TeeChart, including the binaries that come with Delphi, and perhaps the Standard version or other purchased version of TeeChart that you might have bought from Steema.
It uses a precompiled header include file to do the compilation and not just ONE but TWO different copies of an identically named include (.inc) file.
When you use their own compiler tool (recompile FastReport) it works pretty reliably but isn't the best for when you want to build everything in your project from a single build script, thus the source of my problem.
The key is to learn everything there is to know about the dependencies of all the components in your giant pile of packages, and to organize your system cleanly so that you don't have old stuff (like Indy and TeeChart bpls, dcp, or dcu files) lying around. Cleaning that up is quite a complex job if you don't know what you're doing.
A utility to really remove all traces of the version of Indy and TeeChart that ship with your system, and the "Embarcadero edition" of FastReports is key to getting this situation resolved. A general tip is that "if a version of X ships with Delphi and you are going to install a new version, prepare to suffer until your system is really cleaned up".
A really amazing technique to avoid all this crap is to just not install Indy, FastReport or TeeChart (uncheck them or skip them) during your initial Delphi IDE install, then install them yourself, one by one, from sources. Just because a version comes pre-installed in Delphi doesn't make that a good thing. (Update: You can no longer unselect Indy during install, it's part of the base Delphi product since at least Delphi XE8. A clean-up utility to remove the built-in Indy from Delphi's own lib dirs is necessary for anyone who builds their own.)
Another really amazing technique is to run the Installers for commercial components on a virtual machine, then just collect up the pascal source code and transfer that onto your clean development machine, and build it yourself. That way you can avoid the terrible things that happen when you've got BPLs and stuff scattered around your system, and even installed into C:\Windows\System32 (on 32 bit systems) and C:\Windows\SysWow64 (the equivalent path on 64 bit systems).
put that BPL (tee7100.bpl) under $(BDSCOMMONDIR)\Bpl
for XE: $(BDSCOMMONDIR)= "C:\Users\Public\Documents\RAD Studio\8.0"
for XE5: $(BDSCOMMONDIR)= "C:\Users\Public\Documents\RAD Studio\12.0"
The other issue that can cause this, is not having the folder where you've stored your .bpl files in your system path.
This happens because Delphi attempts to call the WinAPI function LoadLibrary with a file name, instead of an absolute path. So if Windows can't find the file, Delphi can't load it.
See this forum post for more information.
This seems to be an issue in Windows 7, though not in Windows 10.
I'm moving frequently between D7 and D2009 with library code that works with both.
For ease of going both ways, I'm routinely deleting all the D2009 additional files that get created, eg: *.dproj etc, such that on entry to D2009 I'm only ever taking D7 files.
This is nice because D2009 automatically makes a *.dproj, *.dgroup etc and apart from a notification on entry to D2009 that each project has been upgraded you can build immediately.
I have two identical machines, each with D2009 on them.
The 'good' one does what I've listed above, creating an upgraded project with the default build configurations 'base', 'debug' and 'release'. Looking in these, I can see my options copied from the Delphi 7 *.dof file (eg compilier options and output directory etc).
On the 'bad' machine with identical D7 projects supplied to it, although it 'upgrades' the projects it does not import the compiler options and output directory settings.
I've not fiddled with build configurations at all.
I can manually import a set of options saved on the good machine, but this is tedious and I'd like to find out why the 'bad' machine behaves in a different way.
Is there a 'master' build configuration that might now have a time/date that makes D2009 think I want that instead on a default upgrade?
I've just come across this exact problem.
In my Drag/Drop components, although I support Delphi 5 through Delphi 2010, I only distribute the dof files. I do this to avoid having to keep the dof and dproj files in sync. Now all of a sudden the search path setting from the dof files are not being exported to the dproj files.
The solution I've found is to strip the dof file of everything I don't need:
[FileVersion]
Version=7.0
[Directories]
OutputDir=.
UnitOutputDir=.
SearchPath=..\..\Source
With this change the dof file is imported correctly.
I haven't had time (nor reason or motivation) to investigate precisely which entry in the dof file that is preventing the SearchPath from being exported.
Ok, just a few questions, you have two machines the good the bad (and not the ugly). The good creates a valid 2009 project from the 7 project. But the bad one misses the compiler options and the directory settings.
At first, are you sure you have provided the .cfg file? This one is needed for this information.
Next, which order are the delphi versions installed. If the newest version is installed before the oldest, there can be some problems. Installing them in correct order gives no problems. (I have had 6, 7, 8, 2006, 2007, 2009 on the same machine without problems).
You said that the problems happened "suddenly". Can you recall what has been changed on the bad machine just before the problems started?
If you have the time, you can try to reïnstall anything.
Hope this helps.
Do you have relative paths in your projects? It seems that D2009 (or the BDS ide in general) reacts slightly different with respect to the work-directory used to resolve partial paths.
Sometimes when you file->open a file, all relative paths are suddenly relative to the path of that opened file. This state also seems to be more persistent.
To exclude such problem, open a file from the respective .dpr/.bdsproj/.dproj dir for each project of your projectgroup and do a build.
I've been searching the Internet for a solution. Also here on Stackoverflow. But I haven't had any luck so far.
We're having a problem with a Delphi 2006 application running on Windows 7. Some ComboBoxes are not shown. The exactly same application runs fine on Windows XP.
I been trying to locate any patches. Do any one of you know any links or hack to make to GUI look as it should when running a Delphi 2006 application on Vista/Windows 7?
I've found this link: http://www.theabsolute.net/sware/delphivista.html. But it doesn't solve my problems.
Any help are welcome.
/Brian
This may be one of a couple of issues; you haven't given much in the way of details. "Some comboboxes are not shown" doesn't help a lot.
The things I've run across that caused these kinds of problems:
Large fonts when the app was designed with normal fonts
Custom DPI settings (eg., 120 DPI instead of the "standard" 96 DPI)
EDIT after Brian's comment:
That's really strange. I've never seen visual differences between apps compiled in the IDE and command-line.
The only thing I can think of is that the command-line version might have some compiler defines that are affecting the comboboxes (unlikely), or the command-line version is seeing a different version of the .pas and .dfm and that version doesn't have the comboboxes on the form.
You might try making sure that there is only a single copy of the affected .dfm and .pas files on the build machine, and then verify they have the right appearance before compilation. (Use Windows search to check for multiple copies of the source files, and search the entire system just to make sure.)
I've never had this issue with visual controls, but have had it with source changes that didn't seem to take effect, or breakpoints that didn't break because the compiler was seeing a different version of the file than I was... I don't know if that's the case here, but it might be worth checking.