I've been working for a long time under Windows XP with Delphi 6 (and under Win2k before).
As I've recently bought a new laptop, I had to start using Windows Vista.
I've installed Delphi 6. Whenever I used the TBitBtn component, I get error when running the compiled program: like resource BBOK not found, resource BBcancel not found, etc.
"Project Project1.exe raised exception class EReadError with message 'Error reading BitBtn1.Kind: Resource BBCANCEL not found'. Process stopped. Use Step or Run to continue."
Right now, I do not have possibility to try to run the exe-file on WinXP; however I was able to compile the same code under WinXP and the produced executable ran fine under Windows Vista as well.
Is there some simple workaround other than upgrade to a newer version of Delphi?
Thanks in advance!
This is definitely not a very neat solution, but this issue seems working after:
Copying Buttons.pas and buttons.res from Sources\Vcl to the directory with my project.
Editing Buttons.pas to use QBOK, QBCANCEL etc. instead of BBOK, BBCANCEL.
Thanks for your comments.
Related
Update: as noted by some, this is a problem brought about by NOD32. An issue item for this in their system is:
https://forum.eset.com/topic/16237-probleme-debug-delphi-with-eset-11249/
Delphi 10.2.1 and 10.2.3 hang when starting (with debugging) any 32 bit application on Windows 10/64. This started after the computer was rebooted for the weekend like it is every weekend.
Debugging a 64 bit project compiles & runs ok.
Debugging a 32 bit project compiles but hangs before/slightly after the project even starts running ("end task" on Delphi is the only option now). If I run without the debugger, the project runs ok. Delphi "stops responding".
I've seen this single form "do nothing" test application I have used to investigate this freeze after loading Kernel32 or Comdlg32.
Hearing how similar this is to the problems with Delphi 10.2 and Windows 10's Creator update, I migrated to Delphi 10.2.3. Same problem as before.
I restored to a backup of the Windows partition. After I did that, it worked until I rebooted and then it broke again.
I went to an earlier backup of the Windows partition & got the same result.
This is so strange...any ideas?
I Thought it might relate to Nod32 as I had the same issue happen after a nod 32 update.
I have added the BDS.exe directory to be excluded from real time file system protection.
Seems to be fine now.
I have seen this kind of behavior with F-Secure antivirus and Windows 10 1803 (April 2018 Update).
This is similar to the last comments on this post : http://blog.marcocantu.com/blog/2017-june-delphi-packages-creators-update.html.
The only workaround I've found was to define the affinity of the BDS.exe process.
You can do this by right clicking the bds.exe process in the Details tab of the Task Manager and Define affinity but it will only define it for the current run.
You can define affinity definitively by running BDS through the command line.
Here is my shortcut :
C:\Windows\System32\cmd.exe /C START /affinity 1 bds.exe
ESET is deploying 11.2.63.0 release of it's antivirus and the problem of freezing Delphi for Win32 debugging is now solved.
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.
I have developed an app for computers a while back, that generates a word document and saves it automatically under a name provided by the software.
The application has worked perfectly in windows xp and windows 7. But now it needed to be moved to a windows 8.1 computer and since the generating works perfectly. But the save command wrdDoc.SaveAs(SaveToFile); does not work.
Basically what happens, is on that command's execution a save dialog appears and you can save the document yourself. After you click save. You get an error command failed with no further details.
Is there anything that has changed since windows 7 that prevents this code from executing properly?
The old computer used the following:
windows 7
office 2007/2010/2013(all were used at some point in time)
New computer:
windows 8.1
office 2010
UPDATE:
it is also worth noting, the dialog does not show any of the word documents in the folder if i browse there... Can this be a hint to the problem?
Resolved
I managed to find the problem. It's a brand new laptop, and Acer had a bunch of crap installed that sync's with office and explore. Once i uninstalled that the software returned to working normally...
Thank you guys anyway so much :)
It depends on your word version. Only 2007 has a "Saveas" method for the document object (https://msdn.microsoft.com/en-us/library/bb221597%28v=office.12%29.aspx). The later versions (2010 and 2013) only have a "Saveas2" Method (https://msdn.microsoft.com/en-us/library/ff836084.aspx)
Here is the problem I've met:
Working in BDS 2006 IDE, my older computer gone, new ( i7 mount ) has been built and it has Windows 7 Ult OS 64bit, where 2006 was installed and QuickReports Pro as well as eDocEngine, FIB+, TMS, LMD, ZEOS & DB Comparer Component Packs - I use them in my products.
On computer I have Office 2010 installed as well, by default in 32bit version and Adobe CS6. That's it.
After installation I tried few times reinstall RAD 2009 and anyway, always the same problem, to simplify it is 100% reproducable like that:
Create new Delphi VCL Forms application ;
Click File / New / Other and goto, say, "Delphi files" and select Frame or DataModule. When new file is created, all the time we have message:
"Stack overflow - save your work and restart Delphi for Microsoft Windows"
After that IDE set in bad state and next F12 ( show VCL designer) closes Delphi with General Error.
Any idea what happens?
As I said, I tried few time uninstall - install 2006, start in any personality, use / do not use any of the updates or IDE fixes from Andy's site, nothing helps.
Any help would be greatly appreciated.
You can try running a second instance of the IDE in the debugger.
Create an empty dll or package project.
Open Run > Parameters
Set the host application to $(BDS)\bin\BDS.exe
Then just hit F9 to run the second instance of the IDE in the debugger. After that just follow the steps to reproduce the problem and wait for the exception. If all goes well you'll get a complete call stack to step through.
Note: You may see various other exceptions occurring as the IDE loads. These are normal and can usually be ignored.
Also you didn't mention what version of Windows was on your old machine. If it was Windows XP Uwe could be right. XP was a little more lax on security by default than Vista or 7. The new default is to restrict write access to any folder under Program Files. If that turns out to be the problem you can adjust the write permissions for $(BDS) for whatever user account you use for development.
Delete de PackageCache in Embarcadero registry entries. Its not a complete solution but worked for me.
Got that from here: http://qc.embarcadero.com/wc/qcmain.aspx?d=118669 (last answer).
I have no BDS 2006 at hand, but is it possible that the default folder for new projects is located below the Program Files folder? In that case there might be no write access to that folder.
I'm writing a FireMonkey HD application on my Windows 32 bits machine, and deploying (remote debugging) it on my MacBook running Snow Leopard. I'm running the Delphi XE2 Trial.
Everything is working fine, except for one thing: every other run I hit the following error when I press F9:
Fatal error starting debugging kernel: "Invalid debugger request".
Please save your work and restart Delphi XE2.
Restarting XE2 and running again cures this problem... for exactly one run, then I hit the same error again. Whether I stop the debugging run through CTRL-F2, or gracefully close the application on the Mac, makes no difference. It happens on every project (including new, empty ones with only a single FireMonkey form).The PAServer terminal has no information, it's still on "listen".
Anyone has any tips on how to avoid this issue?
Installing the full version of Delphi XE2 (including update 1) seems to have fully solved my problem.
I've checked the Bug Fix list for any references, but no such luck. Oh well, problem is gone anyway.
[EDIT] And now, the very next day, the problem re-appears.
Delphi 10 gives a similar adventure (Win32 --> Win32 target). It's "business as usual" for the remote debugger.