i want my own pascal code to be executed it also have some uses files and other complex functions just like a Delphi code can i do this
Yes:
http://www.remobjects.com/ps.aspx
This component is used in the highly popular Inno Setup installer software.
Delphi Web Script is now under active development again.
Previously it was good; now it is becoming great.
You can download it on Google Code.
--jeroen
Another option, which is useful if you want to support more than just Pascal syntax, would be Fast-Script by the makers of Fast-Report.
There's also paxCompiler
Depends how much pascal you want to interpret. Pascal Script will interpret most stuff but you can't declare classes in a script (You can however import them using script functions). You can't use "uses" clauses either.
If you want to do full on pascal support you're going to have to compile it. You could probably use the FreePascal one providing your app's licensing is compatible (GPL).
TMS has both a scripting engine and a scripting IDE product.
Related
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
I have a environment and I want to know that if I write code in this environment is it possible to save>compile and use that code?
whats is more is that I want the environment to be able to call function in this code and for the code to be able to call function in the environment..
I think there was something called class loaders in java that allows you to do this.. can I do this is Delphi and what is the best way to go about doing this?
(just in case anyone says about putting it in there to start with its for a game for kids, they will just write a section of the code dealing with simple logic and variables and have calls to methods that are in the environment that move a virtual robot)
Delphi doesn't have any facilities for compiling code at runtime, but there are a fair number of scripting languages that do. Take a look at PascalScript from RemObjects, for example. It can do most of what you're looking for, though it doesn't have any facility for creating new classes. I don't think any script engine does. But it can import existing ones from Delphi and create new Pascal functions and procedures for your program to interact with.
You should be able to do what you need to do using paxCompiler.
If you absolutely need compiled code, you can use freepascal to generate a dll and then load this from delphi. Yes, should be nice to' have a free version of commandline Delphi compiler.
I have source code for a Windows DLL that is written in C++ and uses Visual Component Library. Now my task is to port that to Linux, but I don't have source code for the VCL itself, or any kind of documentation (and I have never worked with Borland C++; in my Windows days I used MFC).
This should not be all that hard, since my DLL does not have any GUI: as far as I can see, it mostly uses VCL for multithreading. I ran into a class that inherits from TThread and that is where I got stuck. I did some search on the Internet, but found no documentation for VCL so far. I would like to avoid buying a book on Borland C++ Builder, because I don't have time to wait for it to arrive from the Amazon. I cannot consider buying the package for Windows, because at work I only have a Linux box.
Any suggestions?
The Boost libraries, and wxWidgets, will provide analogs to the VCL classes.
You should be aware that the VCL used by C++ Builder is written entirely in Delphi/ObjectPascal. c++ builder apps all involve c++ making use of delphi-based libraries.
The FreePascal/Lazarus open source project has reverse-engineered most of the VCL (almost all of the non-visual stuff and much of the visual stuff) and it runs natively on Linux. The non-visual VCL-compatible stuff is known as the "Free Component Library" ("FCL")
http://www.freepascal.org/
http://www.freepascal.org/fcl/fcl.var
The source of the TThread implementation in the FCL should be easy enough to find.
One option would be to rewrite in FreePascal, where language would change to ObjectPascal but calls to the VCL and usage of VCL components would be virtually identical.
Another option might be to port to c++ on Linux and somehow make use of FreePascal's VCL from c++. I'm not sure of the practicality/feasibility of that. Someone at FreePascal's forums should be able to help answer that.
So another option as someone has mentioned would just be to rewrite using some other threading library.
The VCL is documented on CodeGear's web site. TThread in particular is described here.
I've found the documentation on the threading-related components of the VCL to be rather sparse. This site has a much better description of the Delphi/VCL approach to threading.
You can download their free compiler and try experimenting with it. It should be possible to run it under WINE at least. Maybe even under FreeDOS.
It should be related to the TThread class in Delphi/Kylix. That is another alternative for exploring it. I do believe that the most important methods were run() and sync() but it's been ages since I used it.
However, if you plan to cleanly port the code to Linux, it may help to re-implement the TThread class yourself, using some boost libraries or something.
Many years ago, Borland released a version of their IDE for linux, marketed as Kylix. I'm not sure if it is still supported, but that might be the path of least resistance, for you.
There are several libraries that provide frameworks like threading e.g. Boost (www.boost.org) or ACE (http://www.cs.wustl.edu/~schmidt/ACE.html)
It should be fairly easy to port the code to use one of these threading infrastructures.
I'm using delphi6, and it lacks the following abilities:
a library object,
a list object(looks like TList,TStringList is good enough?)
a algorithm library(like sort,)
template library like STL
dynamic language feature or GC.
and so on.
how can I find this things?
Try Jedi Code Library. There are good replacements for container classes and sorting algorithms. I don't think there is GC or STL-like library for Delphi 6.
Delphi 6 is behind the times, check Delphi 2009 or at least Turbo Delphi
There is DeCAL, which claims to be similar to the STL. I've never really tested it, however.
There are many third party delphi libraries, components and source code examples on the net.
Just a couple off the top of my head
JEDI http://www.delphi-jedi.org/
and
a Delphi super page http://delphi.icm.edu.pl/
As an alternative to DeCAL (Which is a very good alternative to TList without generics), I will propose EZSDL by Julian M Bucknall.
List of main third party components compatible with Delphi 2007 for Win32 and RAD Studio 2007 by Andreano Lanusse at http://edn.embarcadero.com/article/37455
The first three are in the VCL, take a look in the help and the sources. Delphi 6 has no generics, so cannot be used with a template library. And no garbage collection.
If you want to program in Delphi, forget about them. If not, find another language.
I am looking to add the capability for users to write plugins to the program I have developed in Delphi. The program is a single executable with no DLLs used.
This would allow the user community to write extensions to my program to access the internal data and add capabilities that they may find useful.
I've seen the post at: Suggestions for Adding Plugin Capability? but its answers don't seem transferrable to a Delphi program.
I would like, if possible, to add this capability and keep my application as a single executable without any DLLs or additional modules required.
Do you know of any resources, components or articles that would suggest how to best do this in Delphi, or do you have your own recommendation?
The first question I would ask is, do you need the plugins to access the UI of your host application, or add any UI elements of their own? Or will the plugins be limited to querying and/or supplying data to your host app?
The latter is much easier and opens up two possibilities. Others have already mentioned DLLs, which is the first way to go. Certain caveats apply - in general you should be interfacing with a dll using only the data types that are used in Windows API. THat way you can be sure that the plugin DLLs will understand your data types, no matter what language/compiler they were created in. (So for example, use PChars, not strings. Do not as a rule pass Delphi classes such as TStream to a DLL. This will appear to work in some cases, but is unsafe in general, because even if the DLL was compiled in Delphi, it may have been a different version of the compiler, with a slightly different idea of what TStream is). Google for using DLLs in Delphi, and you'll find plenty more tips.
Another way that hasn't been mentioned yet is to enable scripting in your application itself. There are several very capable 3rd-party scripting engines, both commercial and free, and most of them allow you to exchange Delphi objects with the script. Some of these libraries support only Pascal as the scripting language, others will let you use Basic (perhaps better for beginner users) or other languages. See for example RemObjects Pascal Script (free) at http://www.remobjects.com/free.aspx .
My favorite scripting solution at the moment is Python for Delphi (P4D, also free) from http://mmm-experts.com/Products.aspx?ProductID=3 It can interface beautifully with your classes via RTTI, and allows you to execute Python code in your Delphi app, as well as use Delphi classes in Python scripts. Given the popularity of Python, this may be a viable solution if you want to attract developers to your project. However, every user will need to have a Python distribution installed.
It seems to me that the barrier to entry, from the point of view of potential plugin writers, is lower if you use scripting than if you choose DLLs.
Now, back to my initial question: things get much more complicated if you need the plugins to interact with your user interface, e.g. by placing controls on it. In general, DLLs cannot be used to do this. The Borland/CodeGear-sanctioned way is to use packages (BPLs). With BPLs, you can access and instantiate classes offered by a plugin as if they were declared in your host application. The catch is, all BPLs must be compiled with the same exact version and build of Delphi that your main application is. In my opinion this makes packages completely impractical, since it's hard to expect that all the potential plugin writers around the world will be using the same version of Delphi you are. A major pitfall.
To get around this, I have experimented with a different approach: keep using DLLs, and develop a syntax for the plugin to describe the UI it needs, then create the UI yourself in the host app. (XML is a convenient way to express the UI, since you get the concept of parenting / nesting for free.) The UI description syntax can include callbacks to the DLL triggered when the contents or state of the control changes. This method will restrict plugins to the set of VCL controls your application already uses or has registered, though. And it's not a one-nighter job, while BPLs certainly are.
Google for "Delphi plugin framework", too. There are some ready-made solutions, but as far as I know they usually use BPLs, with their limited usefulness.
Actually, the accepted answer to the question you cite is quite appropriate for Delphi as well. Your plug-ins will be DLLs, and you can dictate that they should export a function with a certain name and signature. Then, your program will load the DLL (with LoadLibrary) and get the address of the function (with GetProcAddress). If the DLL doesn't load, or the function isn't there, then the DLL is not a plug-in for your application.
After you have the address for the DLL, you can call it. You can pass the function an interface to something that represents the parts of your application that you wish to expose. You can also require that the function return an interface with methods that your application will call at various times.
When testing your plug-in system, it will be wise to write a plug-in yourself with a language other than Delphi. That way, you can be more confident that you haven't inadvertently required everyone to use Delphi.
At first I went for BPL and DLL base plugins. And found them hard to mantain.
If you use BPL system, then you need to match BPL version with EXE version. This includes Delphi updates which can break something. I found out (the hard way) that if I need to include all my plugins with every release, there is no point in having plugins at all.
Then I switched to plain DLL plugins. But that system just complicated code base. And that's not a good thing.
While crusing the net I found out Lua embedded script language, and delivered with it. Lua is 150K DLL, embedding bytecode compiler, interpreter and very simple and smart dynamic programing language.
My plugins are simple lua scripts. Easily mantaind and made. There are premade Delphi examples, so you can export any class or procedure as Lua table or function. GUI or not. For example I had TurboPower Abbrevia in my app for zipping. I exported my zipping class to lua, and all plugins now can call zip('.', 'dir.zip') and unzip(). Then I switched to 7zip and only implemented old class to use 7zip. All plugins work as they did, with support for new zip('.', 'dir.7z').
I made TLuaAction which calls Execute(), Update(), Hint() procedure from its script.
Lua allso have it's own plugin system that makes it easy to add funcionality to it. Eg luacom make is easy to use COM automation, luainterface allows calling .net from lua.
See luaforge for more. There is Lua IDE made in Delphi, with source.
I tried to make an overview of all such options some time ago. Together with my readers/commenters we built this list:
DLL/BPL loaded from the program.
DLL/BPL loaded from a sandbox (which could be another copy of the program or a specialized "server" application and which communicates with the main program via messages/sockets/msmq/named pipes/mailslots/memory mapped files).
COM (in any of its variants).
DDE (please not).
External program that communicates via stanard input/output.
External program that communicates via files (file name is a parameter to the program).
External program that works via drop folder (useful for batch processing).
External program that communicates with windows messages/windows sockets/msmq/named pipes/mailslots/memory mapped files/database publish-subscribe.
The most universal method of adding plug-in capability is to use COM. A good book to get you started on the road is Delphi Com Programming by Eric Harmon. While it was originally written for Delphi versions 3 through 5, the books contents are still valid with the latest versions of Delphi.
Personally, I have used this technique along with active scripting to allow end user customization.
I'm using plug-ins to implement most of the functionality in the game engine I'm building. The main EXE is made up of a script engine, a plug-in manager, some basic graphics routines and not much else. I'm using TJvPluginManager from the JEDI VCL library. It's a very good manager, and it can add just about anything you want to your program. Check out the demos included with the package to see how it works. The only downside is that it adds a lot of JCL/JVCL code to your program, but that's not really an issue if you're already using other JVCL components.
If plugins will be developed in Delphi or C++ builder, use packages + interfaces. Delphi OTA is a good example for that.
If plugins will be language independent, COM is a good way to go.
Addition: If you won't use COM, u may need to provide SDKs for each language. And datatype handling between different languages can be pain(for example delphi string type). Delphi COM support is excellent, u don't need to worry about kind of details. Those are mostly impilicit with Delphi COM support. Don't try to invent the wheel again. I'm surprised why people doesn't tend to mention about it.
I found an article by Tim Sullivan:
Implementing Plug-Ins for Your Delphi Applications
You could have a look at Hydra from Remobjects. Not only will this allow you to add plugins, but also to mix win32 and .net.