|
PureBytes Links
Trading Reference Links
|
Hello,
In fact there are 3 issues that decide if particular language is
capable of creating plugins for AmiBroker:
- ability to use cdecl calling convention (altrough I am considering switching
to stdcall being more-API like, but this would require significant changes)
- ability to call functions via function pointers (the function pointer is what
WINAPI GetProcAddress returns)
- ability to handle C-like string pointers (char *), floating point array pointers (float *)
and structs (records) of those variable types.
All flavours of C/C++ support these and Delphi supports these also.
Visual Basic in the current version is not able to create "normal" (not COM) DLLs
and there is no control over calling convention used.
These requirements are enforced because plugins will support two-way function calls
AmiBroker->ExternalDLL and ExternalDLL->AmiBroker and AFL will make
no distinction between these calls. (NOTE: yes I know this could be also done
using COM but some of you probably know that writing COM in C/C++ requires much more
work and I would like to provide an easy way to write the plugin DLLs for you)
I don't know if PowerBasic supports the features I mentioned,
but for VisualBasic and other COM-based languages I will provide the ability
to call functions in COM (ActiveX) objects. However this will be handled
by separate function Call( object, "functionname", params,...) (or Invoke).
In this second approach features listed in point 3 will not be available.
Best regards,
Tomasz Janeczko
===============
AmiBroker - the comprehensive share manager.
http://www.amibroker.com
----- Original Message -----
From: "Buzz M Ross" <buzzmr@xxxx>
To: <amibroker@xxxxxxxxxxxxxxx>
Sent: Saturday, September 22, 2001 10:07 PM
Subject: Re: [amibroker] DLL interface
> 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.
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
|