|
PureBytes Links
Trading Reference Links
|
Hi, Tomasz,
For a number of reasons, I do not program in C, nor any flavor of it, and
avoid it like the plague. [Many years ago, I DID write a program in C,
and was 'cured' forever from it. My hat's off to you for your patience
to do YOUR work in C!!! (:->) ]
I've chosen to do my projects in various flavors of Basic. In
particular, I use Visual Basic and PowerBASIC. PowerBASIC is my language
of choice, and soon I'll be obtaining the PB/DLL v6.0 compiler. This
compiler generates code to interface with Visual Basic's 'dll' calling
conventions, which to my understanding use standard Windows API interface
conventions. As long as the AmiBroker calling convention adhere's to
this standard, I see no reason why ANY language, including the PB/DLL
compiler, that generates such calling-interface code could not be used.
Please verify that this is a correct assumption for purposes of writing
DLL's for AmiBroker.
If this assumtion is NOT correct, then you may want consider what to do
about the AmiBroker specs before casting them in concrete. Thanks in
advance for your consideration.
Providing the ability for the user to write their own DLL's is a VERY
POWERFUL policy decision that I highly commend you for!! Thank you for
your SANE approach to EFFECTIVE software development for users!!!
Buzz
-------------------------
Buzz M. Ross, President
Creative Consulting Co.
Boulder, CO 80301
-------------------------------------
On Sat, 22 Sep 2001 09:36:26 +0200 "Tomasz Janeczko" <amibroker@xxxx>
writes:
>Hello,
>
>In this e-mail I want to present you some features of a DLL plugin
>interface
>being developed for version 3.8. I would like to know your thoughts
>about
>it before I close the specification.
>
>The purpose of AmiBroker's plugin interface is to allow to extend AFL
>built-in function set
>by any user or third party software vendor.
>
>Main goals are:
>1. speed - there will be virtually no performance differences between
>internal and external
> functions
>2. simplicity -
> a) the interface is very simple, flat API-like (no COM for now).
> b) writing plugins will be as easy as adding a new function(s) to a
>sample C project
> c) Installation of a plug-in will be as easy as just copying the
>DLL into "Plugins" directory
>3. tight integration with AFL engine -
> a) external functions will be available directly from
> AFL without the need to call any additional function like ExtFml.
> b) all external functions will be highlighted properly in a new
>syntax coloring editor
> c) AFL engine will check types of parameters passed to the external
>function
> d) ability to call-back any built-in AFL function from within
>external DLL (this includes
> also calling functions from one external DLL to another)
> e) ability to overwrite built-in functions
>
>For technical reasons (mainly point 3.) plugin DLLs will have to be
>written in some flavour
>of C/C++ language. Visual C++ 6 is preferred, however free compilers
>like PGPP (GNU) and
>free Borland C/C++ 5 compliers will be supported also. It is yet to be
>tested if it is possible
>to write compatible DLLs using Delphi.
>
>Visual Basic and other COM-only languages will not be supported at
>this stage.
>COM-based interface is planned later (next year).
>
>Best regards,
>Tomasz Janeczko
>===============
>AmiBroker - the comprehensive share manager.
>http://www.amibroker.com
________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today! For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
|