I have an application that I make a call to a DLL function that creates and returns a form. I get a whole bunch of errors when I try to parent this new form to the main form in the application.
Is that a common error / problem or is there not an issue with parenting in this case.
And as far as I have learned a form created in a DLL call doesn't belong to the application. Is there a way to make the newly created form belong to the application.
Thank you,
Tim
compile your dll and exe with the same version of delphi compiler with the same runtime packages.
also in dll do not use any calling convension like stdcall or cdecl on your form-creating-function.
it will work like a charm.
Do not use VCL inside DLLs. You will encounter all kind of problems this way. If you absolutely need to have dynamic packages that create VCL components or other GUI parts, use BPLs for instance. Here is a short sumary of both:
BPL vs. DLL
Stack oveflow question
There are other aproaches. Now the main question is why do you create a form inside DLL and is that really needed?
Your dll and exe must be compiled in same version of RAD Studio and both must use runtime packages.
Related
I've made a dll in c# an made it com visible then used it in delphi. In order to do that i had to register the dll so that i could install that as a component in my delphi ide. (I registered the dll with the interop thing then in delphi went to install component > type library > selected my com dll and it created everything for use of it.)
The problem i'm facing now is that i want to use the exe on another machine without having to register the dll. Is it possible to compile the exe file with the registered com dlls?
I have a solution to this is to not use the com obj but just go with unmanaged dll and export all the methods i want but i would prefer embedding the dll/com into my exe and i can't seem to find a solution to this, i don't know if it's possible.
Use dynamic loading of CLR technique to load and use DLL. refer to this Hosting the .NET runtime in a Delphi Program you might get your answer.
In dynamic loading technique you need not register the DLL you just have to generate a TLB and interface for your DLL and through that use the DLL.
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.
Is it good idea to put Forms that have complete functionality in dll.
And main app will invoke dll function that returns form object.
The accepted way to do this in Delphi is to use packages rather than DLLs.
Packages are essentially DLLs but with Delphi specific capabilities that allow VCL objects to be used across package boundaries.
Trying to do this with DLLs will lead to a variety of problems that packages deal with. One downside of packages is that all modules must be compiled with the same version of Delphi. But if you are wanting to share objects across module boundaries then you would face the same restriction if you used DLLs.
The Delphi documentation has extensive coverage of packages.
Having said all that, I would add that if you can put all your code into a single module (.exe or .dll) then it does make life a lot simpler.
Adding to the answers about using packages:
Packages can only be used if both, the main app and all dlls (plugins) are written in Delphi and are written using the same version of Delphi
DLLs can be written in any programming language that can create them and can be used by any program regardless of the programming language
So, using dlls rather than packages does make sense.
Regarding the actual question: Yes, it is possible to put forms into dlls and they usually work fine. Just make sure that you do not pass them around because they are only valid objects within the context of the dll. You will experience the odd problem with forms losing focus or coming up behind other forms. This can usually be fixed by passing a window handle from the main executable to the dll which is then used as the parent for the form.
Also note: TObject of your dll is different from TObject of your application. The same applies to other commonly used classes and variables like (Forms.)Application.
I have done it and it was a pain in the lower back but it was not impossible. The main program was written in Visual Basic 6, some modules were written in Delphi 6, others were written in Delphi 7 and Delphi 2007.
Conclusion: If you are sure you will never use something different than Delphi for your app and for your dlls (plugins) and are willing to always recompile everything when you switch Delphi versions, you should use packages. Otherwise it might be better to use regular dlls. (And are you sure you will always be the only person writing these dlls? Maybe at some time there will be a 3rd party developer for one of the dlls who does not own the Delphi version he needs.)
IMO this is sometimes a very good idea and the only way to go - for the reasons others have mentioned, I'm not a fan of packages, and am very comfortable with DLL's. I am currently adding functionality to an app written in Delphi 5 using Delphi XE - it was either use DLL's or write in D5 - of course I opted for the former: D5 app calls DLL's written in XE that contain all the latest and greatest features. (The first projects I did in Delphi were done via the old Borland Paradox - Paradox app invoked DLL's written in Delphi 1!)
But, I don't send the form or module from the DLL back to the main app - I just send the DLL module a structure containing what it needs to know to do its work, and when it's done and the DLL's form closes, it cleans up and then and returns a numerical code or structure back to caller indicating success, failure etc ( old fashioned but very effective).
Passing the form instance from the DLL back to your main app across the DLL threshhold can be problematic - note #dummzeuch's excellent answer above with some good tips on how to negotiate some of those problems should you decide that is your only solution.
+1 for everything that David Heffernan says.
Strategically, you really only need to implement forms (or other functionality) in external files if you're implementing a plug in system.
If you're going to allow plugins to be authored in any language, then DLL's are the only way to go.
If your plugin system will be restricted to developers with the same version of Delphi (same team perhaps?) then go with BPL's. The additional drawback of Delphi packages, from my perspective, is the need to deploy the VCL BPL's with your app, which are always more Mb than a single compiled module.
If on the other hand you want to write a modular system, you can still do that by implementing loose coupling & "plugin" techniques within your code and still compile to a single module.
If you put a form in a normal dll the form won't be able to intercept the TAB or arrow keys. I have been told that this is due to the OnKeyDown not be passed through.
I want to design Delphi plugin framework. There are three options:
1. DLL
2. BPL
3. COM interface
Every option has some disadvantage.
DLL - Promblem with MDI apllication, forms from plugin cannot be embeded to the host exe - mdi application.
BPL - Every *.bpl plugin and *.exe host application must be compiled with the same version of Delphi.
COM - Interfaces {xxx-xx-xxx-xx} must be registered in system, (regsvr) So plugin framework cannot be portable!
Is everything true what I wrote above? If not, please correct me, or is there some other possibility?
thanks
Yes, what you wrote is correct. All of these have advantages and disadvantages, the question is what is important for you, you didn't say what you want to do, so we can't tell you how to do it.
In general, I would pick BPL by default, use DLL if you need to use it from non Delphi apps, and pick COM only if you really have to.
The alternative is to not build your own, since there are several Delphi plugin frameworks available.
Also, this topic has been discussed here before, check out:
how-best-to-add-plugin-capability-to-a-delphi-program
plugins-system-for-delphi-application-bpl-vs-dll
Another possibility is having a scripting interface, such as with Python or Pascalscript. There are many advantages to this approach, not least of which is that the plugin source is also the executable, making it easy to debug and share.
I would look at Hydra from Remobjects.
Another candidate would be a combination of PaxCompiler (scripting) and EControl Form Designer (form designer).
We use DLLs, even when using only with a Delphi application.
Dll forms are embedded in the main form and use Tabs instead of MDI.
For DLL to work properly we also use a shared memory manager and built with runtime packages: vcl, rtl and our own package.
Have you taken a look at http://www.tmssoftware.com/site/tpf.asp
Is there a way to store a Delphi form in a .dll file?
You can make code that creates and displays a form, just like you would anywhere else. What you can't do without a lot of inconvenience is pass a TForm object (or any other object) out of the DLL, so it has to be self-contained. If you want a form that can communicate and interact with your program, you either need a package (BPL) or you need to make the form into a COM object.
The easiest way to do this is to compile your application and the DLL in question with packages. This requires that you include several BPL files with your application when it's deployed, but means that both the EXE and the DLL will be much, much smaller (great for on-the-fly updates!)
There are a number of open-source and commercial products that will help you "plug-in" forms into your application. http://delphi-jedi.org has the JVCL which includes a plugin system that will let you do this pretty easily, and take a lot of the heavy lifting out of developing it. Also, TMS Software at http://tmssoftware.com has a plugin framework that will allow you to do this as well.