I'm running windows 7 ultimate (32bit) and have a very anoying problem with my installation of delphi.
The problem is with the feature "Code Insight" and with "Code template completion", it is very anoying when it every time i write something and it wants to complete some piece of code for me (for example i hate it when he completes the for condition). The problem is that i can't shut it down since i think it has a bug when installed on windows 7 that when i turn those features off it works once and then it turns on again, like it couldn't write in the settings file.
Does anybody know where Codegear Delphi 2009 stores it's setting/configuration file? Or how can i turn off.
I tried running it as administrator in compatibility mode (vista and xp) tried searching for the file but with no luck.
In the registry under: HKEY_CURRENT_USER\Software\CodeGear\BDS\6.0
Also in HKEY_LOCAL_MACHINE\SOFTWARE\CodeGear\BDS\6.0 but there seems to be no data there of interest.
Also under C:\Users*USERNAME*\AppData\Roaming\CodeGear\BDS\6.0 are some settings stored.
Related
I have an ancient program that I use for reading and writing data from AutoCAD. This program is written in Delphi 5. I have tried to update it to a newer release but several of the libraries I use no longer exist and it is a huge program with lots of libraries used.
The program uses the ACAX##ENU.TLB type library that is provided with AutoCAD. Where ## changes for each AutoCAD release. Every time Autodesk sends out a new AutoCAD version I import the new type library and life goes on.
Now I am faced with Windows 10. For some reason the automation links between my program and AutoCAD are not working in Windows 10. Did something change about the way the type libraries work between Windows 7 and Windows 10? Something that Delphi 5 is no longer compatible with? Maybe it's a 16bit vs 32bit vs 64bit issue. That is all over my head but I understand that Windows 10 dropped support for some 16bit operations. But my program itself runs perfectly. Even the BDE can be made to work which is amazing to me.
Is there anything I can do for an experiment? I am really lost about what to even experiment on.
Thanks.
Well, it's been a long time since I asked this question but here is an answer:
I was able to get my Delphi 5 compiled program working with AutoCAD 2017 in a Windows 10 environment. I am pretty sure that the solution was to run the program WITHOUT administrative permissions and WITHOUT any compatibility modes switched on. Apparently Windows places restrictions on COM communications as soon as you turn on either of those features. There may have also been issues with Windows 10 still having UAC active even when you set UAC all the way off. There is a registry setting to actually set UAC to off but my corporate IT prevents turning that off even with admin rights.
So in the end it was not a problem with Delphi, my program or with AutoCAD. It was a Windows 10 problem.
There was a bit of a clue that might be helpful to others: with the admin permission and/or windows XP compatibility turned on the program took several extra seconds to boot. With the settings turned off it booted quickly.
Or maybe its something entirely different from any of this. But the program is working now.
Thanks.
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.
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.
Debug buttons are disabled in Delphi 2007 IDE. I can build project with command line or Project -> Build, but cannot run application or either attach to process.
I'm wondering if anyone has encountered this issue in the past and can help me.
Few facts:
Delphi 2007 IDE was installed on my machine and worked just fine.
Debug buttons got disabled at one point of time and I have no idea what was the reason.
I tried reinstalling Delphi, but this did not help.
License for Delphi is ok.
I suppose that there should be
something with either registry or 3rd
party components.
I'm .NET developer and need investigate some piece of Delphi code, so please do not blame me :)
Will appreciate any help.
Possibility...
Go to pull down menu: 'Project/Options/Compiler' and set in field 'Build Configuration' to 'Debug'. In filed 'Debugging' switch-on first 5 switches like 'Debugging Informations' and so on!
So, as I figure it out later (from Delphi developers from different team) issue was with 3rd party components to Delphi. They stored something into registry. It was enough to change some registry keys, they did this so I cannot post it here.
Very interesting how it could be that such components got shipped.
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.