I have created a few AUTOObjects using Delphi and its type library. It compiles without error, but when I tried to register it, Delphi froze, and doesn't return to normal. I have tried to register it in both Delphi 7 and 2006, but both get into the same problem. I tried to register a simple library in Delphi's demo, I am ruling out bad registry file,
There might be something wrong with my code, but I have no idea where, since it compiles well and I have not put any code in RegisterDLL.
Anyone had the same problem before?
You have not provided enough information for anyone to help you.
Have a read of this http://support.microsoft.com/kb/555375 on how to ask a technical question, it's written for the Microsoft newsgroups, but has the same application here.
Initialization sections of the units also get executed when registering a COM dll. Try registering outside of Delphi with tregsvr or regsvr32 and see if that works ok. You can also have those tools as a startup project and debug your dll while it gets registered.
Cheers everyone. I solved the problem. The problem was in one of unit there was a initialization code creates threads, now I have removed it, the library registers fine. :)
Related
I have problem to build my project. I am using delphi 2010.
when i try to build my project this error shows up. "F1026 File not found: 'System.Action.dcu'
I've tried to find solution for this error, but i can't find anything that really fix this.
any idea?
First of all, I am going to assume that the error message actually refers to System.Actions.dcu (as per the question title) rather than System.Action.dcu (as per the question body). It's always best to use copy/paste error messages so that they are transferred verbatim.
You are using code written to target a later version of Delphi. Not only does Delphi 2010 not have unit scope names, i.e. System.<unitname>, but it does not have the Actions unit. If memory serves correctly, unit scope names arrived in XE2 and the Actions unit in XE3.
The code you are compiling has a unit the uses System.Actions. Find that unit and work out where it came from. Then you'll need to work out how to proceed. Can you get a version of code that supports your older Delphi version? Can you port the code to your Delphi version? Can you find an alternative library? Only you can answer those questions, I'm afraid. We cannot give advice at the moment since we do not know anything about the code that is causing you problems.
I have a Delphi application with an automation object.
On the start of the program, I want to register the COM object automatically in the registry (instead of using the /regserver switch).
The old version of the program was written in Delphi 7 and I think I remember that this version registered itself after program start. But now it's compiled with D2009 and it doesn't register itself now. Maybe somebody know something about this?
Thank you very much!
This is probably failing because you are running on a machine with UAC and you don't have rights to write to HKLM. You aren't going to find a satisfactory solution using the /regserver switch because it will always try to write there.
You could switch to registry free COM, although it might just be better to do the registration as part of installation. That's when you are expected to do it because that's when you know that you will have sufficient rights.
You can use ComServer.UpdateRegistry(True); to register your com objects and ComServer.UpdateRegistry(False); to un-register.
ComServer is found in ComServ.pas
http://docwiki.embarcadero.com/VCL/en/ComServ.TComServer.UpdateRegistry
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.
There is a whole host of components that I am trying out to better understand how to detect when a file or folder has changed. I want to write a delphi application to also do this but delphi Unicode(Tiburon) doesn't seem to ship with any component that can accomplish this. At least not anymore. I found a curious component on the palette called shellersources and after just placing it on a form and running it I get an error:
Cmctrls was compiled with a different version of SHLObj.IAutocomplete
I tried virtually all the component listed here: shell resourcehttp://www.torry.net/pages.php?id=252 and interestingly I get the same exact error on compiling them. I am running delphi on Vista, could this be a vista issue? I also tried the SHChangeNotify component from about.com and even it too produced an identical error concerning SHlObj.IAutocomplete. Anyone noticed this? Strange.
There are two Windows API calls that will help you accomplish this in Delphi:
FindFirstChangeNotification
FindNextChangeNotification
The drawback is that these function calls are low-level-non-delphi components. But you can still make those function calls in Delphi. If you ABSOLUTELY need a delphi component, you could always write your own, using the mentioned functions as base.
I can't seem to add a reference to a DLL file in F#. It might be a bug with Visual Studio.
I attempted to add a reference to my F# project by clicking on "Add Reference" -> "browse". I found my DLL, and when I attempted to add it, nothing happened. The window didn't even close to confirm my selection. Help please.
Are you adding a reference to a managed DLL?
Anyways, if you can, make a small repro and send it to fsbugs AT microsoft dot com.
Edit: Here's the list of known issues with the F# Sept CTP.
I think there are some known issues when the DLL is produced by Managed C++, however I don't know the details. In any case, sending a bug report to the F# team as Michael suggests is the best thing to do.
Adding a reference to the F# project never works for me, i need to debug the project, then i reference the resultant dll found in the debug folders. This usually does the trick for me.
When I reference the project it always tells me that there is no dll.