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.
Related
RAD Studio 10.4.2 C++Builder running on Windows 10 Pro 64-bit PC. Target VCL Win64 (ie Clang64 compiler).
I have a large C++ project that is under development using VCL Clang64. I am compiling using static linking of all RTL libraries and all installed component packages.
It was compiling and running OK before. I've added some new stuff, and now it compiles and links without reporting any errors, but when I run it I get an error box and the application doesn't run (doesn't even start up). The error box says.
Error reading OKBitBtn.Kind: Resource BBOK not found
I have used Notepad++ "find in files" to search all directories for a file containing BBOK, but it says "none found".
If I compile with the "Use runtime packages" project option enabled, I get an AV when I try to run the EXE file.
If I compile and link using Clang32 (target = Win32) with static linking, it runs ok - no sign of any errors (but I need a 64-bit application to interface to my PostgreSQL database using FireDAC, so this experiment won't talk to the database, as expected).
I am at a loss as to what can cause this error, and what debugging steps I should take to track it down and solve it.
(thanks to Remy for making edit improvements to my mquestion)
Thanks to help from David Millington and Miguel Moreno (provided by skype conversation I now have the solution:
I have some of my own VCL components that are written in C++ (and work with the classic compiler). I had these de-selected in the "installed packages" list - but they were still listed (with empty check boxes). I know that RAD studio 10.4.2 (and earlier) does not work well with VCL components written in C++ and compiled with clang32 or clang64 compilers.
If I "remove" these components from the list then the problem is solved. At this point I have no idea why this happens.
This is a bit of a pain as it means swapping from projects that use the components with classic compiler (many) to the big project I am spending a lot of time on is not convenient. However it is an acceptable workaround. I am hoping that this issue will be fixed in the coming RAD Studio 11 version.
Rad Studio 10.3.2, create a new Windows VCL app C++. Put a breakpoint at the Form1 constructor. If I inspect "this" and the debugger shows ???? for any variable.
I am having really a lot of problems with 10.3.2, not only this one (std::variant not work, CLANG stops, ...). I would say that it has a lot of bugs but now I would ask if somebody has a similar problem.
It is a known bug in 10.3.2 and is currently being fixed by Embarcadero.
The bug is tracked as RSP-25527 | RSP-21126 (currently these are marked as duplicates but a request has been made to separate them).
They report that you can work with 64 bit windows ... provided of course you are not trying to link to external libraries or COM objects that are only available as 32 bit.
I can confirm that I have tested a Win64 VCL project and I can confirm that I do have the variables visible in the Inspect Window. You may have to manually add the 64 bit Windows target.
(I am having some problems with my 64 bit debug setup at the moment - I am loading packages which include debug info (as per the Events window it states the library has debug info) but I am unable to step into some of them which I normally can do with Win32. I do have the variables visible to me though.)
I have an Delphi 7 Application that uses Halcyon dbf component. It works well in Windows ME.
Unfortunately in Windows XP data aware controls which are bound to Halcyon xBase Engine do not behave correctly. In addition pack command almost hangs the application. I tried compiling in XP. But no joy. Does that mean that API calls work differently? May be Data types mean different things....
Thanks for all help
A well written Delphi 7 application will work on any version of WIndows from 98 onwards. If you have managed to make an application that doesn't work on XP, then you should debug the problem on XP, not recompile and then give up. (no joy!? what? you're done already? Is that how you troubleshoot and debug?).
For posterity I should point out that if you change Delphi versions then of course, some things change. For example, If you build your Delphi application in Delphi 2009 or later, it will work properly on Windows XP, but not on Windows 98 or ME any more. But if you build your application using the same version of Delphi, why would you expect any changes in the application's bugs?
As David says; Rebuilding your application on a different computer, from the same code, and with the same compiler, produces the same binary. If you have a fundamental problem on Windows XP it is because you made a mistake in your code somewhere.
In general, windows 98/ME to 2000/XP was an easy transition, but that was a decade ago.
The only API I remember that was in Windows 98/ME that was not in XP, was the Windows 98 text-to-speech API which was removed and replaced with a different API in XP.
I believe your confusion is that windows contains something that affects Data Aware controls. It does not. Data Aware Controls are a purely Delphi thing, and they are not a part of Windows XP, they are 100% implemented inside Delphi. If you have some funny custom control that is badly written, perhaps it might not work. We have no idea what your code contains, and you haven't even described the nature of the failure.
You need to provide more information, or this question should be closed as unanswerable, or too localized. (My app doesn't work! Help! No other info given.)
After many years of trouble-free use, Delphi 7 is now throwing an Access violation at address
40233A3E in module 'vclx70.bpl'. Read of address 0000021C.
When starting the IDE, the default empty project and unit/form appear and compile and run fine.
I'm developing Windows apps, running on Windows 7 (x64).
I haven't installed any new packages or tools in many, many months.
I stopped, dead in the water, unable to work.
Any suggestions other than a complete rip and re-install (which takes many hours...)
EDIT: I un-installed and re-installed Delphi 7. Now I'm getting Access violation in vcl70.bpl. I would have thought that uninstalling D7 would completely remove all of its libraries, etc... Are there folders that I should manually delete after uninstalling D7?
Problem fixed (and major machine rebuild averted)!
Gerrit Beuze of ModelMaker Tools suggested elsewhere:
Remove all .dsk (project desktop) files for the project you try to load, Temp remove all *.dst (desktop files) from C:\Program Files\Borland\Delphi7\Bin
After performing these steps, the problem appears to have been fixed.
A read at that low a memory address is typically a problem in a third-party component. However, you say you haven't installed anything new in months.
The other thing that's strange is that you're getting the error in vclx70, which is one of the CLX libraries. Are you doing anything using the CLX (leftover cross platform - Kylix) forms or dialogs?
If not, you might do a search in your source for QDialogs, QForms, or any of the other units in %PROGRAMFILES%\Borland\Delphi7\Source\Clx, and see if something mistakenly was added that you didn't intend that's pulling CLX into your project. If so, change it to the VCL version instead (by just removing the 'Q' from the front of the unit name in your source).
EDIT: You might try going into the registry (D7 would be HKCU\Software\Borland\Delphi\7.0) and temporarily changing the name of the delphiCLXide entry in Known IDE Packages to something else (put an underscore in front of the name or something). Then start the IDE. You should get an error message about Delphi being unable to load the package, and asking if you want to try and load it again in the future. Answer 'Yes', and let the IDE continue to load. Then try again with your project and see what happens.
The step above removes CLX temporarily from loading in the IDE designer. (Don't worry, you can just rename the key again to put it back if it's not the problem. If it doesn't come back, make sure the IDE didn't add an entry in the Disabled Packages entry; if it did, just remove it.)
If this works, you can open the project options (.DOF) file for your project, and remove the CLX libraries from the Packages list. This prevents it from being included when your project is loaded.
Once you've established whether the problem actually
My first suggestion would be to use XP Mode or another VM infrastructure to run such an old Delphi version on Windows 7 (I do it that way).
Another potential method is to use the compatibility settings in Windows 7 to set it to XP and to exempt the Delphi 7 process from DEP (data execution prevention) policies the system may otherwise impose. I've had some trouble with enabled DEP with older Borland IDEs and also VS 2003.
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.