I've been widely making use of the Complete Class at Cursor function in Delphi, in 2010 and in XE2. Recently, after installing Update 4 for XE2, the Complete Class at Cursor stopped working. After doing some research, I found that uninstalling "AQTime" would fix the issue. So I did that (had to re-install Delphi just to remove it) and sure enough it started working again.
Except, today, it suddenly stopped again. AQTime is not installed, and I haven't done anything in the IDE at all which (as far as I know) could possibly cause this. I haven't installed/uninstalled any packages, changed any library paths, not even changing any settings. It just suddenly stopped working in the middle of my development. Was working one minute, and not the next. I've restarted Delphi, restarted my PC, and even tried in a brand new project. It just will not work anymore.
Anyone know why this stopped working? How can I make it work again? It's an extremely helpful tool which I use all the time.
I had the same problem, but it was solved after uninstalling Smartbear AQTime from the windows uninstaller. (close Delphi first)
No need to reinstall Delphi.
Had the exact same issue in XE2/Update 4. Did the following (without uninstalling AQTime) and it came back.
Tools > Options >Editor Options > Code Insight
Verified the Code Completion was checked (it was), then changed the Delay to Low (was set to None) > OK
Code Completion in my IDE started working again.
I was having the same problem in Delphi Berlin. None of the above worked for me. I also tried regenerating the .dproj file but that also did not help.
The one thing that has worked (so far) is installing the excellent IDEFixPack for Delphi Berlin. Delphi IDE Fix Pack
Please let me take this opportunity also for a quick moan. Code completion is an absolutely essential feature of Delphi and it is very slow and flaky at best. Embarcadero (if you are listening) - please focus on making these core features much more robust.
Unstalling the AQTime8.20 integration in the IDE solve the problem for me too - used AQtime outside the IDE anyway.
Related
I'm trying to move a project that was done in a previous version of C++Builder to 10.1 Berlin (I am using the trial version of C++Builder).
The project was converted and compiled succefully with minimal efforts. Then I got the well-known linker LME288 problem, but it was resolved by starting C++Builder as an administrator.
But now, when I start the application, I get a message box saying "Abnormal program termination" at the very beginning - even before the main window appears on screen.
The situation is the same for debug and release versions, under IDE and as standalone. When I start the program inside the IDE, and set a breakpoint at the very first statement, the error message appears before this statement.
I have Windows 10 Pro, 64-bit. C++Builer 10.1 Berlin trial. It shows the only accessible platform is Win32, but I don't know if this is a reason for an error. The program worked fine for previous versions.
Could anybody advise me what to do? Is there a systematic way of investigating the problem?
I have tried all recommendations I could found - use debugger, show us the code, try reinstalling software or Windows, upgrade to latest updates, etc. But I have never seen a systematic approach.
Here are a couple of things I had to do to get my project working.
1) Start a new project. For some reason old projects can get corrupted and produce strange errors. I recommend starting a new project and adding your files to it.
2) Use an old version of borlndmm.dll The version provided with C++ Builder 10 produced crashes for me that made no sense. I overwrote the provided copy of borlndmm.dll with a copy from XE6 or XE8. That solved my problem.
Hopefully one of these will help you.
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.
Delphi 7 has been running fine for a long time (months on this machine, many years on others.)
However, although I know of nothing that I changed (and certainly didn't install any components) if I try to run a newly created, simple program, with one form, while I'm in the IDE, I get an Access Violation at address 006DDDC2 in coreide70.bpl.
The program runs fine outside the IDE.
I'm running no add-ins (like Delphi Speedup...)
Other than completely ripping and re-installing, any suggestions?
A rip and re-install solved the problem ... for a while, and then it re-surfaced.
For anyone having the same problem, I have traced this down to something being corrupted in my saved desktops. Since the problem was occurring when I tried to run a program, it would naturally switch to the debug desktop. Apparently it was corrupted. Saving a new desktop to replace the old desktop resolved the problem.
The first thing to try is to remove packages from the IDE. Try this out with your vanilla empty app rather than your real app. If that doesn't help I'd move straight to a Delphi reinstall. That really ought to fix it and there's probably nothing to be gained trying to solve the problem with a reinstall.
I face a very annoying bug in D2007 IDE :
It's the second time I have this problem within one month (on two differents computers, but with the same project), and it is a very annoying bug that causes the IDE to close itself without allowing me to save any changes in the code.
I tried but cannot reproduce the bug, it only appears randomly.
Here's what happen exactly :
i'm changing a line of code then (when I press "enter" to go next line)
the message
"Assertion failed: amount >= dest - startDest, file ek_flbuf.cpp, line 315" appears.
and when I press OK an second message "Abnormal program termination" appears.
Closing this message cause the IDE to quit.
When googling at my problem i found QC 33917 but the status is Closed : Cannot Reproduce
My questions are :
Is there any known workaround to this problem ?
can this problem be caused by third party stuff ? (I'm using GExperts and Delphi SpeedUp)
Does anyone here encountered the problem on a more recent IDE ?
UPDATE :
I remembered the problem occurs the first time (a month ago) within the same Unit.
so maybe the problem is not only project related but unit related.
I've restarted Delphi and returned in the same function where the problem appears today, trying to reproduce the bug only typing some code then deleting it, again and again, like a mad...
just restarting delphi and editing code in the unit (no other actions before), I managed to reproduce the problem a second time today ! but no more, despite many new similar tentatives... :(
...still investigating. (and thank you for the answers, I will now stop trying to reproduce the bug and check the answerers hints.)
The last time I have seen this, is when one of my source files had inconsistent line endings.
Make sure all your lines in all your source files end with CRLF.
--jeroen
When I used 2007 and saw this, it only happened on very long units (10,000+ lines - having that many is an issue for another discussion :p) Usually the IDE would be fine, then typing would become fairly slow - I could see the letters I typed lagging behind in the code editor. Unless I paused and let the editor catch up, I'd get that error.
So, my fix was:
If you're in a large unit and the editor starts lagging, pause, immediately. Let it catch up, and keep going.
This is really annoying, but worked for me.
I also turned off many of the Code Insight features, but I don't know if they affected this particular issue or not. They did help general editing speed. Turning them off was recommended to me in the then-Codegear forums. I can't remember who by, but I have a vague feeling it may even have been one of the Codegear QA staff who was aware of the bug but was trying to see if I could narrow down what affected or caused it. This was a couple of years ago now though, so don't take that as gospel.
Splitting your files into smaller, say <5000 line units may also help. For me it only happened on large and complex files.
The issue seems to have been fixed in RAD Studio 2010. Another way to avoid the error would be to upgrade :) If you do, wait a few days or talk to their salespeople first. The next version, RAD Studio XE, is due out at any moment. I'd recommend upgrading anyway: you'll need to handle Unicode issues, but other than that the 2010 edition is the best version I've used, including its stability, and I've used Delphi since version 1.
The first thing to try is to remove both add-on packages (GExperts and Delphi Speedup). It could be something they are doing.
The second is to do your best to reproduce and submit the issue.
The third is to upgrade to a new version of Delphi and hope that it solves your problems without creating new ones.
If this happens on two separate computers, but the same project on both, then the problem is most likely in the project itself and not the IDE. Of course, you didn't post any of the code that causes the error message to appear, so it's hard to help you find out what the problem is with the code. I find it very unlikely that the problem is the IDE, though, or others would have reported the same problem (D2007 has been out and in use by millions of developers for years now).
If the problem is in the IDE itself, you should be able to reproduce it with a new, empty project. Copy and paste only enough of the code from the old project into the new one to allow the problem line to compile, and then replicate the same change->press Enter to add a new line - does the same assertion failure and then abnormal termination happen?
If you can't reproduce the problem in a new project, the problem is most likely with your code, and without seeing it it's hard to tell what might be causing it.
Ok, I'm going nuts here. For the last (almost) four years, I've been putting up with some extremely bad behavior from my Delphi 5 IDE. Problems include:
Seemingly random errors in coride50.bpl
floating point errors on compiling
occasional deletions of my source code files
form and object sizes shifting between instances of working on them
Loss of links between files on compile: messages that it can't find a function even though it is explicitly referenced
The linker frequently fails to include valid .DFM files unless a full build is performed instead of a smaller compile
The biggest problem is that my boss isn't believing that this is happening without any user changes making these issues appear. I've already wiped and reloaded Delphi fresh a couple of times, but that is not something I can do again right now. Most of the issues listed can be easily recovered from (either reload the IDE or re-copy the files out of source control), but this is completely nuts. I've eliminated all the warnings and hints from compile time, haven't covered them up. I've done my best to follow Marco and Microsoft's best practices. Is this just me? Am I the crazy one? How can I stop Delphi from causing these headaches anymore?
Pretty sure it is a bad package. If you can come up with steps that fail repeatedly (which I know is tough) then try removing 3rd party (or home grown) packages 1 at a time until it is fixed. Then you at least know which package us causing the trouble.
Once you know what the troublesome package is, you can actually debug the design time code & behavior of the component in Delphi. Just set the Delphi exe as the debug application, and then Delphi will launch another instance of Delphi in debug mode. Reproduce the steps that cause the failure, and hopefully you will get a good idea of what code in the package is causing the problem.
Good luck!
I have never seen any version of Delphi delete files under any circumstances.
Do you have any IDE plug-ins installed? This would be my first guess.
I've never heard of behavior like this from Delphi before. A couple of things to look at:
Are you sure the memory on your machine is good? Have you run Memtest on it?? The last couple of times I've encountered crazy behavior from a machine the culprit turned out to be the memory.
Beyond that, remember that anything you install into Delphi runs in the context of the IDE and if it's buggy it can mess up the IDE. Even a component that writes to a wild pointer could do this to you.
i used d5 for a long time & never saw that. i had some other strange things like you mention about needing to build rather than just compile. i have that in d2009 as well.
Just a thought; pikcing up one of your comments about you having D5 and D7 installed, I'd suggest;
uninstall D7
uninstall D5
reinstall D5
install D5 3rd party components
service pack D5
reinstall D7
install D7 3rd party components
service pack D7
then try again, having done the trick of deleting all the .DCUs in your own project directories.
In my experience I've always been careful to stick to installing them 'in numerical order' and if one needs to be removed, I usually end up removing them all before I start reinstalling.
GExperts ToDo list window... close it or any other GExperts Windows.. Watch the Task Manager for memory increasing and then stopping after you close any windows.
Pretty much out of Delphi 5.0 these days. But I do recall it was important to have the latest Build for various reasons. Do you have it?? Go Help->About. I believe this is the latest version:
Version 5.0 (Build 6.18) Update Pack 1
Which OS are you using? If it's Windows 7, perhaps there are incompatibilities with Delphi 5, since it's a bit long in the tooth now. Perhaps you could try running Delphi 5 in a XP VM.
Since you had no problems with Delphi 7, is there any reason for not migrating this application to Delphi 7? It shouldn't be difficult to do, unless you have some third party components with no source.