Has anyone used the ICU ( see http://site.icu-project.org/ ) DLLs from Delphi?
Specifically I'm interested in the Code Page Conversion and Collation functions.
Looking at the header files it would appear that they are mostly in C++ using classes, so without having done much research yet, I would assume that it's necessary to create a simple wrapper around this that exports simple functions which can easily be imported in Delphi.
Has anyone done any work for that yet?
Or can anyone recommend a different solution for Delphi that has similar extensive coverage for codepages and collation orders?
I don't use it, but there's a very complete translation called ICU4PAS that wraps the DLLs and provides a nice Delphi-based interface.
Related
We want to automate OpenOffice, When i search on internet couldnot find a end-to-end help for that and delphi examples are too less. Our intention is to insert document variables and replace the document variable with there values and copying paragraphs etc.
Can any one help me to find an end-to-end help or a pas file like word2000.pas where i can find all the word routines.
Thanks,
Basil
I do use OpenOffice-Automation with Delphi a lot and I think there is no "wrapper" with higher functionality for Delphi.
There is a Delphi OO Project on SourceForge with helpers and examples as a starting point: http://sourceforge.net/projects/ooomacros/files/Delphi%20OOo/Version%201.2/Delphi_OOo_v12en.zip/download
Then you have to study the UNO-API and use COM to call the UNO functions.
You can find a lot of updated information here:
https://www.freepascal.org/~michael/articles/openoffice1/openoffice.pdf
Can anyone recommend a FIX Engine (commercial or open source) for use with Delphi?
Is it possible to use QuickFIX with Delphi?
Take a look at B2BITS FIX Antenna. There are two possible options:
FIX Antenna C++ has ANSI C interface that can be used in Delphi (there is a sample in the package)
http://www.b2bits.com/trading_solutions/fix_engines/fix_engine_cpp.html
FIX Antenna .NET can be used in Delphi .NET (there is again a sample in the package; also programmer's guide contains Delphi.NET samples)
http://www.b2bits.com/trading_solutions/fix_engines/fix_enginenet.html
Feel free to contact me directly if you need more details.
QuickFix is a C++ project.
Both Python and Ruby use SWIG to expose the C++ classes as native Python and Ruby classes.
The .NET wrapper sounds like a mix of C++ and C# code.
It's not possible to import C++ classes within Delphi directly. You'll have to use a "flat API" conversion, exposing all C++ methods as plain C declarations, in order to import external structures and functions in a Delphi unit.
To my knowledge, there is no such "flat API" of QuickFIX available, and no SWIG version able to generate Delphi code. You'll have to write your own wrapper in C++, or perhaps write your own FIX implementation in Delphi.
The only FIX library I know for Delphi is the one from http://www.b2bits.com - it did exist some years ago, but I'm not sure it's still sold/maintained - they seems to maintain only a DotNet version. Worth asking them for pricing and availability, in all cases.
One way to integrate the protocol with Delphi would be building a .Net or Java bridge, for example:
use the .Net C# implementation to build a small application to communicate with the FIX side
then expose methods (and maybe even the objects) of this .Net app over SOAP web services
use Delphi's web service client code generator to import the SOAP WSDL
access the web service from the Delphi side
This is probably more of a hack than anything else, but you could use the Python QuickFIX bindings in Delphi, via python4delphi. That's a lot of layers though (Delphi to Python to C++).
Python is an easy language to use, and learn, and it's easy to invoke and create python objects (or native C wrappers that pretend to be python objects) and invoke them directly from the Python4Delphi API.
Barring that, it might be very little work for you to build a procedural (flat) API as ABouchez said. Instead of writing a million functions I would write only the ones I needed, and then implement these simple functions inside a VC++ DLL:
QuickFixInit;
QuickFixCleanup;
handle := QuickFixLoadFile(filename)
QuickFixSaveFile(handle)
handle2 := QuickFixGetObjectHandle(handle,index,...);
QuickFixModifyObjectProperty(handle2, propertyname, propertyvalue );
QuickFixExecuteSomeAction( handle2, actionname, param1,param2,param3 );
The above are just to give you the flavor. I know nothing about the internal API, but what I'm showing you above is that you don't need to conform 100% to the API to write a wrapper. You could probably (if you know C/C++) write a functional wrapper that does what you need, and export it, link it into a DLL, and then import QuickFix.dll into Python with very little (2-4 hours of an expert's time) work, if you know Visual C++ well enough to write a few simple C-style (non OOP) functions that instantiate C++ classes, and invoke C++ methods.
It might be possible to expose the C++ APIs to Delphi via a C++Builder package (BPL) containing QuickFIx, but (a) some source modifications would be required, and (b) the C++ code in QuickFix, or its dependencies, might not build in C++Builder without significant modifications.
I'm pretty new to Delphi and I'm trying to use the DEHL Collections library. (see http://code.google.com/p/delphi-coll/ ) I'm have a little trouble with it from the IDE perspective. It compiles and runs correctly, but Delphi XE shows errors anywhere I use the HashSet library. The biggest grievance is that is prevents me from using code completion.
The first location I get the error is in an object declaration:
uses
SysUtils, Windows, Collections.Base, Collections.Sets, Collections.Lists,
adscnnct, adstable,
uOtherClass;
type
OneClass = class(OtherClass)
private
_bad: THashSet<string>; // THashSet underlined
_good: TList<string>; // No problems
end;
The error states: "Type arguments do not match constraints"
I don't think it's configuration as I can use TList just fine, but here is how I set it up: I've copied the library to Projects/Libs/DeHLCollections/Library and compiled the library to Projects/Libs/bin. I've included the bin directory in my global library path, which got it to compile and run. I have tried adding everything (/libs, /DeHLCollections, /Library) to it as well in hopes of getting the IDE to help me out, but it doesn't seem to be helping.
Anyway to fix this, or do I just have to deal with it?
Using DeHL Collections version 1.1.1.119
Welcome to the troubles with using Generics laden code. DeHL and generics work a lot better in Delphi XE than in any previous Delphi version, but that's not the same as it "not having any problems". The problems I experience are exactly like yours.
My opinion is that DeHL shows every sign of having been written by a master delphi programmer, and that it's a thing of beauty, in some ways. It's also a source of great pain, through no fault of its own.
Delphi contains not one or two, but at least three (maybe four?) separate parsers, including the full compiler parser, and a few IDE-parsers used for things like Error Insight (the errors you see even before you build) and the code completion data parser. Each has different language support limitations with regards to generics. It is possible perhaps that DeHL could be written to avoid parser problems with all the various Delphi parsers. I have not seen a guide ever written that shows the limitations, but I wouldn't be surprised if complex type declarations in the form TSomething<TSomething<ISomethingElse>,TBar<IFoo>> breaks more than a few of those parsers.
If you intend to use Generics very heavily, you may as well turn off Code Completion and Error Insight. You might also want to save often, and be prepared to experience a lot of compiler problems. And don't try to compile generics-heavy code and put it in packages either. I have experienced a lot of URW and AV (internal compiler faults) when I write generics based code. I find that the Delphi compiler team is great at fixing whatever gets reported, but that the Generics are really most stable for me when I restrict myself to using the Generics.Collections that come with Delphi, and not using other generics based code. It seems it is possible to write stuff using the generics features, that the IDE and two-way tools, and code-completion is not yet fully ready to handle. That means, phenomenal cosmic Generic powers come at a cost to the classic RAD IDE productivity features.
That being said, the latest DeHL sources from Subversion work fine for me and build and run with no errors, but the most recent source ZIP of the entire DeHL collection had problems for me.
I expect that over the next few releases of Delphi, whatever issues have been found (and DeHL seems to be a great place to push the boundaries, and that's one of the reasons i'm a big fan of it) will be fixed, and you won't be wondering why heavy-generics break your IDE features, because they'll all be working again.
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.
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.