I just did the update of RAD XE2 to the latest service pack. I can not compile my application using Fast reports stuff inside. The error at compile says "frxclass.dcu not found".
This seems to be a problem like
FAST REPORT ISSUE
Is this a bug of updateing XE2 or did I do something wrong while executing the update process ?
This problem happens with XE2 and XE3. I have FR professional with source and have done several installations each of which have suffered problems. I believe that it is an incompatibility between the included version of FR and the licenced version. My solution was thorough:
1. Go into control panel and delete any and all installations of FR.
2. Go to the program files folder and manually delete any FR folders.
3. Inside the Delphi IDE go into options, library and locate and delete any reference to fast report paths.
4. Go into the IDE Install Packages option and make sure that there are no references to FR packages.
5. Quit the IDE and now install FR using the supplied installer. When this completes you should be able to fire up the IDE fine without frClass errors.
Related
With XE8 update 1, Win 7 64 bit and a single component added to an otherwise empty folder I get:
error: [dcc32 Fatal Error] F2039 could not create output file .\Win32\Debug\MountTest.
The test will compile and run fine the first time but XE8 has to be shut down and restarted to compile again. The component is a gauge from Mitov Software.
The component vendor say's that this is a known bug with no fix. If so its a showstopper and project end'r for me. Is it really the end of the line for Delphi?
I hope some one can pull this rabbit out of a hat somehow.
This is what I have done to isolate the problem.
Started with a failing application (will not compile a 2ed time)
Remove all external units used
Remove al references to those units
Remove all references in the 'Uses' clause
Comment code until it compiles
It should compile every time you hit run (no problem).Now add a blank form to the project. Don't do anything to the form just add it. Add it to your uses clause.
Its should compile every time you hit Run.
Now open the blank form and simply touch it so that it needs to be recompiled.
When you run the application its back to failing when you run it a second time.
Notice that happens when you simply add a form and 'touch' it. No code needed.
This problem is not something wrong with my code - it can't be. Its a bug in the UI - must be.
Coincidentally, I just fought with this issue yesterday testing some components I ported to XE8. The output file in my case is the project executable.
After spending several hours trying to figure out what was going on (including efforts to reconfigure my AV software, disabling it entirely, moving the project to a different location, etc.), I was able to solve the problem by disabling Castalia. If I run the IDE without Castalia, the problem does not occur. If I enable Castalia again, it starts happening again.
You can find instructions for disabling/enabling Castalia in How can I disable Castalia in XE8?
I'm removing the above content because the issue has reappeared (with Castalia disabled). Further investigation shows a couple of things:
The problem seems to be related to any sort of exception being raised in the debugger (even those that are handled in the code). Clicking either Break or Continue in the debugger exception dialog works as always. However, the next attempt to compile or build the application fails with the F2039 error. Deleting the executable in Windows Explorer allows compilation and running once, and then the error recurs.
Restarting the IDE fixes the issue, until the next debugger exception occurs.
Neither taskkill or a batch file with del worked in either a pre- or post-build event.
There is an open QC entry for it at Embarcadero which indicates that it was reported in XE7, XE7.1, and XE8, and is currently an open internal ticket. I can't find a way to add the information in the two points above to that open ticket in the new JIRA-based Quality Portal. Perhaps someone who has access and can do so will on my behalf (or at least add a link to this post).
It's not linked to a specific project. The original answer (as mentioned above) was related to a test app while porting some components to XE8 from an earlier version. When the problem reappeared for me, it was in a brand new project, totally unrelated, that does not use any non-standard components.
(I previously had access to EMBT QC, and had a few open tickets. The accounts appear to have not migrated to the new QP, and I can't locate any tickets there under my account.)
Found It.
I decided to start from scratch on my development system and uncovered the problem.
I installed Windows 10 on a virgin disk
Installed XE8 update 1
Installed MITIOV Instruments for XE 8 and tested them. All working find
Installed AsyncPro - Still working
Installed the JEDI Jcl - Fails
Remove JEDI Jcl - now works
Trash JEDI completly - Everything works fine
Something in the JEDI Jcl version 3.48 is causing the problem. I can code around the JEDI components I was using without to much trouble but its a shame.
How about automatically kill your "hang-up" application before build?
I also had this problem on Win 7 Pro 64 bit with XE8.
Removing JCL fixed the problem. If I was a betting man, I would look closer at the JCL Debug IDE extension.
Guy's..
There is no reason to upgrade to Delphi 10.1, because all previous versions are equipped with an older version of the Android SDK.
Now, how to solve this annoying issue:
Just find the map where the Android SDK is located.
See: Tools/Options/Delphi Options/SDK Manager/Android Location
Now run the ..\sdk\tools\android.bat as Admin
This will show the Andoid SDK Manager.
Next is to update to the newest Android SDK and SDK Tools.
If all completed, you don't have to upgrade to Delphi 10.1 or whatever "advised".
Restart Delphi and problem:= solved!
btw:
It took some effort to find out what's happening here, because the Eclipse compiler suffered the same issue as Delphi. Finally all was related to bugs in earlier versions of the Android SDK causing adb.exe to keep a filehandle held hostage.
Okay. So I have Delphi 2010 installed.
It compiles/builds
JCL/packages/d14/jcl.dpk just fine
I then have another pakcage (not Jedi) that requires JCL. (I get error that it requires that package.)
I have tried adding the path to jcl140.bpl to its project options, but that does not help.
(I would preferably like to avoid running the JCL/JVCL installer again since I have the same versions of source code running on multiple computers.)
I decided to solve this another way. I decided to run the Jedi JCL installer. (And then switch the source back to the old afterwards.) That created the otherwise missing jcl140.dcp file (I only had jcl140.dpk, jcl140.bpl etc. but could not create/find the .dcp one) This seems to work.
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.
Virtual treeview by Mike Lischke seems so popular on the web and as third party component. I just downloaded version 4.8.7 on my machine.
I have Delphi 2010 and Delphi 7.0 in 2 partitions.
Aftter clicking installer of virtual treeview, a log file prompts, saying it has been installed successfully.
I check Delphi 2010, yes, it is on component palette showing 3 controls.
But when I start Delphi 7.0, IDE prompts 'Can not load VirtualtreesD7.bpl...'. I ignore it, and find that Virtual treeview design time package is in list but UNCHECKED. If I try to check it, again it promts "Can not load virtualtreesD7...".
I search whole Disk and find a VirtualTreesD7D.bpl, and manually add it in design time package list. It is on palette with 3 controls.
I tested it quickly and exit Delphi 7.0. But when I restart Delphi 7.0, again it prompts "Can not load VirtualtreesD7.bpl...", it is again not on palatte and not Checked in design time package list.
This is very simple question. Can you let me know how to solve it?
Thank you very much in advance.
Edit:
Thanks for comments.
I tested your comments, but not work.
New problem:
If I uninstall virtual treeview by clicking unins000.exe and reinstall it only in Delphi 7.0, the installer prompts in the last screen ''...completed.." and no error prompts. When I start Delphi 7, the virtual treeview design time package is not in package list. This is even worse than the last time (last time it is in package list but not checked).
I check very carefully one line by one line of that log file, it says:
...
...
VirtualTreesD7.dpk(39)
VirtualTreesD7.dpk(39)
VirtualTreesD7.dpk(41)
VirtualTreesD7.dpk(43)
**VirtualTreesD7D.dpk(32) Fatal: Required package 'VirtualTreesD7' not found**
Why?
Why it does not successfully install and does not prompts the error in installation in the last install screen.
How to solve this "Fatal...not found" problem.
Thank you all for help.
New Edit: (Is this Answer?)
Thanks for your help and suggestion first.
I take 2 hours to test and find a possible solution. It works on my machine and it can be installed in Delphi 7.0.
Steps:
1. uninstall virtual treeview by clicking unins000.exe from Delphi 7.0 ( you can separately install virtual treeview in Delphi 2010)
2. clicking newly downloaded VirtualTreeview setup 4.8.7.exe, install it in Delphi 7 folder, do not install it in default...Rad..path. Important: INGNORE ALL ERROR PROMPTS DURING INSTALLATION (INCLUDING ERROR PROMPT IN THAT LARGE INSTALLATION LOG FILE).
3. Go to $\Virtual Treeview, right click VirtualTreesD7D.dpk, select Open with Delphi 32 development environment. A window prompts for you to compile. JUST CLICK COMPILE, DO NOT CLICK INSTALL.
4. Go to Component -> Install Packages. Go to $\Bpl folder and manually add VirtualTreesD7D.bpl into Design Package. The three controls will appear in Palette.
5. Go to folder $\Bpl and YOU MUST COPY VirtualTreesD7.bpl (NOT VirtualTreesD7D.bpl) INTO $\Bin folder.
6. Close Delphi 7 and restart it, you will find that this component is on Palette and in Package list, it is in Design package list and CHECKED.
I personally feel that the installer of Virtual treeview needs improvements to free users from such trouble and test in installation. The installer needs rewrite.
This is my case of installation. I do not know if it can be generalized to all users.
Thank you all.
The IDE uses LoadLibrary (actually, LoadPackage) to load packages for components that are installed. This means that it follows the same logic for where it looks for files that LoadLibrary does.
The problem is that the IDE can't find the package using LoadLibrary's search logic - see the Remarks section here. So the solution is to add the folder to Delphi's Library Path (Tools->Options->Environment Options->Delphi Options->Library - Win32), or move it somewhere on the system PATH.
Ensure you have the folder where the virtualtrees.pas (\source) is located in the environment search path.
You may manually need to install the *.dpk file for Delphi 7. Open the D7.dpk, compile then open and install the D7D.dpk (Runtime first then Designtime package)
Haven't done it on Delphi2010 w/ Delphi7, but installing with just Delphi7 is fine.
*edited
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! :-)