I have installed CnPack (https://www.cnpack.org) to get. At least, a little bit of the experience you get with VS Code. CnPack is a really great tool and I don't want to miss it, but it overwrites the default Shortcuts of Delphi RAD Studio. After Installation, I miss the Shortcut for automatic code formatting. Usually it is CTRL + D. I found that CnPack has also Code Formatting ability, but I could not find the manuals for it, and therefore I could not find the keyboard shortcuts for that. Any experience with that?
To be precise it pops up the autocomplete box when I press <ctrl-space>. However after approximately 500ms the popup disappears. This happens all the time without fail. When I switch to a C# for VB.Net project the intellisense popup has no problems.
Any ideas?
I've found a fix in case anybody else has this problem.
In your F# solution add a single C# class library. It doesn't matter what it is called. I call mine IntellisenseFix. Ignore the project and continue editing your F# project but now intellisense works correctly.
If you delete your C# class library from the project then intellisense stops working.
It doesn't have to make sense it just has to work :)
After upgrading to Windows 7 all seems to work in my Delphi 2007 version except this one.
I know that 2007 is not build for win 7 but I'm not sure that the OS is the reason. My friend is using it without a problem.
When I use "Find Local References" all is fine.
Do you know a fix for this? Some dll registration may be?
I found the solution!
When I used Refactor -> Rename menu delphi didn't blew up but kindly show me the error. Unavailable interface call with the name of it.
So after short research I've registered 2 tlb files and all is working now.
..CodeGear\RAD Studio\5.0\bin\Borland.Studio.ToolsAPI.tlb
..CodeGear\RAD Studio\5.0\bin\Borland.Studio.Interop.tlb
I used tregsvr.exe for the registration without a problem under my x64 system.
P.S. I still wonder what else is not registered during the installation .. hopefully all is good.
We are trying to split up our monolithic EXE into a combination of an EXE and several packages. So far, we have one package that we're trying to use, and when running the EXE Codeguard shows the following error on startup:
CG Error
Two different CRTLDLLs are loaded. CG might report false errors
(C:\Windows\system32\CC32100MT.DLL)
(D:\Projects\Foo\Bar.bpl)
OK
I read this as two different runtime libraries being loaded - one, the correct one (CC32100MT.dll), one incorrect, which is the package we're trying to use.
Continuing to run the program shows odd errors, especially casting between classes or passing a pointer to a class as a parameter in a method that crosses the EXE/DLL boundary. Codeguard itself doesn't show any other errors at all though. Edit: This is now resolved, and wasn't related. The program appears to run correctly, but the warning Codeguard shows is still worrying.
How do we solve this?
Some more details
We've looked at as many things as we (the developer working on this and I) can collectively think of:
Each project is built using runtime packages. The EXE host lists Bar in its package list.
Each project is set to compile with dynamic RTL. However, changing this does not solve the problem.
The package is linked to the EXE via its BPI file, but linking via a LIB makes no difference either.
The EXE and BPL are compiled with the same project settings, where the same options exist for both types of project. We think, anyway :)
There is only one copy of the BPL and BPI on the system: it's definitely linking to the right one.
Examining the EXE and BPL with Depends and TDump show they are both using C:\Windows\system32\CC32100MT.DLL. They should both be using the one RTL.
Creating a new project (a plain VCL forms application) and linking to the BPL (via its BPI) works fine. Something in the process of adding all the files and LIBs that make our EXE contain the code it needs to changes this, but we haven't been able to figure out what.
The LIBs all either correspond to DLLs we use (flat C interface, usually look as though they were built with MSVC) or are simple projects with lots of related files, compiled to a lib for the purpose of linking into the EXE - these correspond roughly to the areas of the program we want to split to BPLs, by the way. There don't seem to be project options for the LIB projects that would affect RTL linking, unless we've missed them.
I have exhaustively hunted through Depends and looked at all RTL and CC32*.dll files the EXE and every single DLL references. All are identical: rtl140.bpl and CC32100MT.DLL. Fully qualified paths show they are the same files, too. Everything should be using the one same run-time library.
Edit: The final EXE is complex, built with several libs, several DLLs, etc. All these, when built with C++Builder, are built with the current version. Is it possible there's something in one of these DLLs or LIBs that could cause a problem? I don't know enough about how the RTL is linked in to be sure about where to look... my (naive?) assumption is that the linker would normally link in one set of RTL functions, but that of course doesn't seem to be happening... and I don't know how things change when using packages. Is it possible this error has always existed and Codeguard has not flagged it before, because we haven't used something dynamic like a package?
Perhaps another question is, Why would a package have its own RTL anyway, or what would make it count as 'a RTL DLL' to Codeguard?
We're stumped. Absolutely stumped. We've had other problems using BPLs (they seem to be surprisingly tricky things, especially using C++) but have managed to solve them all. This one we've had no luck at all and we'd really appreciate any insights :)
We're using C++Builder 2010 (as part of RAD Studio actually, but with little Delphi code apart from components.)
Edit: Started a bounty. I'd really like to solve this!
Edit 2: Thanks to David Dean for his help (marked as answered below.) Via email, he pointed out this issue was reproduced in a simple test case by someone else, and is logged in Embarcadero QC as report 86335. Currently there is no fix, but the warning does not appear to indicate a genuine problem (ie, it's probably a spurious error, and while it's a pity to have to click past the dialog when you run, hopefully there's nothing in the error to worry about.)
Since one of these is coming from a .bpl, did you try turning off "Build with runtime packages" in the project options?
We had a similar problem. We tracked it down to a (non VCL) .cbproj that was created without the "Multithreaded" option.
As far as I can tell, the only time you get chance to set this option is when you create a new .cbproj, it cannot be changed afterwards using the GUI. We ended up "hacking" the .cbproj to include the following:
<Multithreaded>true</Multithreaded>
To determine which dll is causing the issue, it should be the last dll loaded in the output window just before you see the CG message.
Did you check if you use _TCHAR as char. We had some similar problems with RAD Studio and we found a workaround using _TCHAR as char. As soon as one DLL or BPL Project is compiled with wchar_t, this code guard error appears.
We also figured out, that EXE projects can be compiled with TCHAR = wchar_t without any problem (the main function will be WIDE).
The settings does not affect the GUI being able to handle UNICODE.
A customer logged a similar case in our public bug tracking system and the bug has been identified and fixed in the latest release.
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.