I have a pas unit defining a component.
How can I add it to the palette? the only way I know is to include it in a package, is tehre a direct way to do it?
In a package, have a unit that has a procedure named Register — the capitalization is important. In that procedure, call RegisterComponents on the component you'd like to appear on the Tool Palette.
You must use packages. That's the only way the IDE will load the executable code; it cannot execute DCU files directly. If you don't already have some other package to use, you can add your component to the DclUsr package.
With component libraries of any appreciable complexity, there will usually be at least two packages. There will be a run-time package that contains all the components, and then there will be a design-time package that contains the Register procedures.
Related
I created a design-time package, placed it on disk C:, compiled, installed and added to Library path and Search path.
Now I create new project using a component from this package. Component is added to form, name of unit where the component resides is automatically added to uses, but then Delphi's editor complains that it cannot find the unit where my component is defined and also I am unable to compile.
I never had such a problem in Delphi 6.
What's wrong?
Design time packages cannot be used in your programs.
Usually, you have (or should have) a designtime package, which is only used for installation in the IDE, and a runtime package with the actual component code. The designtime package should have the runtime package in its requires section and register the components in the runtime package.
Your app should only use the runtime package. And that runtime package (or its units or .dcl file) should be in the Library or Search Path.
This separation of designtime and runtime was not enforced in Delphi 6 yet (IIRC), but in more current versions it is, by making some of the units in e.g. the designide package unavailable outside the IDE.
Update
If I remember correctly, the packages to be included in a designtime package for Delphi 6 are not the exact same packages a designtime package for the latest Delphis requires. Ensure that your requires section contains the correct packages for your version.
Ok, now I have untangled this puzzle.
There were multiple superposed Delphi issues:
If Delphi's IDE encounters an unhandled exception when loading DFM it doesn't go further and pretends that it didn't find the faulty unit and units that are listed after it. My problem was that the faulty unit was the last in uses clause, therefore only its name was underlined.
If Delphi's IDE encounters an exception in component's constructor, it makes an automatic "shutdown" for the faulty component by calling Free. Then it tries to use an already freed component and of course encounters Access Violation which affects the number 1.
Sometimes exception messages in component's constructor are suppressed, but IDE still makes a component's emergency "shutdown" which affects the number 2. To find out the exception messages an explicit try-except block is needed.
TChart cannot be created in component's constructor and raises an exception which affects the number 3. When TChart is created it requires a presence of an already created component's window, therefore it should be created in CreateWnd method.
I'm trying to recompile an old Deplhi 5 project but I'm receiving a fatal error saying some of the files are missing.
I've found around 20-25 of the missing components on the Internet, but can't seem to find "LibIntf.pas". Where abouts can I find or download this missing file?
If the compiler tells you you're missing LibIntf.pas, then you're not really missing anything. You're not supposed to have that file. That unit is provided by a design-time package distributed with the IDE. Code that uses that unit can only be used as part of another design-time package. To make it compile, your design-time package should have DesignIDE.dcp in its "requires" list.
Your license forbids you from distributing Delphi's design-time code. The "missing" package serves to enforce that rule. DesignIDE is only usable by other packages, not applications, so if your application tries to use any of its units (like LibIntf or DsgnIntf), then compilation will fail. You need to split the code that needs those units into a separate design-time package.
1) do not mistake units and components. One unit may declare a hundred of components. So be clear about what your are searching.
2) Google. just Google. http://google.com/search?q=LibIntf.pas
The 1st link is in russian, the 2nd one is in English: http://delphigroups.info/2/54/173805.html
In short - you does not have the pas, you should enable runtime packages (if your project is EXE or DLL) and include designide.bpl (or was it designide50.bpl?) or add designide.dcp to Required section of project options (if the project is DPK)
Sorry if this is a silly question but it's not something I've had to do before.
Is it possible to create a component class, say, a descendent of TPanel or TDBGrid, in a DLL, and then load that DLL at runtime in another application, which then creates those controls and uses them like normal Delphi components?
If so can you give me any pointers as to where to look to start doing this?
That's what packages are for. They are a kind of DLL that is improved to play well with Delphi classes (including components).
Just remember that you'll need to distribute RTL[ver].bpl, VCL[ver].bpl and any other necessary Runtime Packages alongside your executable and DLL.
Ideally you should test your application on a VM or system which has never had Delphi/RAD Studio installed on it. This way, if your distribution is missing any required Package files, the Execption dialog will tell you what files you need to include.
I have a pas unit defining a component.
How can I add it to the palette? the only way I know is to include it in a package, is tehre a direct way to do it?
In a package, have a unit that has a procedure named Register — the capitalization is important. In that procedure, call RegisterComponents on the component you'd like to appear on the Tool Palette.
You must use packages. That's the only way the IDE will load the executable code; it cannot execute DCU files directly. If you don't already have some other package to use, you can add your component to the DclUsr package.
With component libraries of any appreciable complexity, there will usually be at least two packages. There will be a run-time package that contains all the components, and then there will be a design-time package that contains the Register procedures.
I'd like to use a .dll with a delphi application, but I'm curious if a delphi package is more flexible than dll?
You can read this article on my Blog: "DLL's, BPL's Static and dynamic loading, and Packages in Runtime"; Is 's writed in Spanish but you can try the Automatic translation (on right part of the page).
Basically BPL is an extension of a DLL. It's a DLL with some things added.
(POSITIVE) If you use BPL's you can do more things with the DLL. More power. You can use RTTI (you must build your applicaction with runtime package for accesss RTTI).
(NEGATIVE) If you use BPL's with more powerfull, you can only use it with Delphi, no with other languages.
If you're sure that you only use it with Deplhi, I think that you must use BPL. Search samples about RTTI, RegisterClasses, GetClass method, LoadPackage (for dynamic load),...
Regards.
Escuse-me for my poor english. It's not my natural language.
Not knowing excactly what you mean, and believing you are a newbie (so I may omit some specialized aspects), and implying you know what a DLL is:
The first and foremost reason to build a package is authoring a design-time component.
You can do quite everything (well..almost...) that a package does just as well with DLLs -- except for the design-time stuff.
Additionally, you can package multiple compiled packages into one Borland Package Library (BPL file) without having the design-time features in mind. If you think deploying and runtime-binding one BPL is better than various DLLs, go for it. The primary purpose is design-time support, though.
Packages are special DLLs that can export classes, while DLLs can only export functions. Yes, you can write a DLL function that creates and instance of a given class, but you can't use a class declared in a DLL (unless using some hacks maybe), while you can use a class declared in a package directly. Packages "know" about Delphi object architecture, while DLLs don't. On the other end, DLLs can be used from any language able to use them, while packages are Delphi-specific.