|
PureBytes Links
Trading Reference Links
|
Hi Tomasz,
Sorry for the late reply. Yes it does support the _stdcall, etc.
conventions. When declaring the function you simply append the
convention to the end of the line. An example:
Function DoSomething(x: Integer; y: Integer): LongInt; StdCall;
I've also pasted an excerpt from the help file below. Hope this helps!
Daniel
------------------------------------------------------------------------
----
When you declare a procedure or function, you can specify a calling
convention using one of the directives register, pascal, cdecl, stdcall,
and safecall. For example,
function MyFunction(X, Y: Real): Real; cdecl;
...
Calling conventions determine the order in which parameters are passed
to the routine. They also affect the removal of parameters from the
stack, the use of registers for passing parameters, and error and
exception handling. The default calling convention is register.
The register and pascal conventions pass parameters from left to right;
that is, the leftmost parameter is evaluated and passed first and the
rightmost parameter is evaluated and passed last. The cdecl, stdcall,
and safecall conventions pass parameters from right to left.
For all conventions except cdecl, the procedure or function
removes parameters from the stack upon returning. With the cdecl
convention, the caller removes parameters from the stack when the call
returns.
The register convention uses up to three CPU registers to pass
parameters, while the other conventions pass all parameters on the
stack.
The safecall convention implements COM error and exception
handling.
The table below summarizes calling conventions.
Directive Parameter order Clean-up Passes parameters in
registers?
register Left-to-right Routine Yes
pascal Left-to-right Routine No
cdecl Right-to-left Caller No
stdcall Right-to-left Routine No
safecall Right-to-left Routine No
The default register convention is the most efficient, since it usually
avoids creation of a stack frame. (Access methods for published
properties must use register.) The cdecl convention is useful when you
call functions from DLLs written in C or C++, while stdcall and safecall
are used for Windows API calls. The safecall convention must be used for
declaring dual-interface methods. The pascal convention is maintained
for backward compatibility. For more information on calling conventions,
see Program control.
The directives near, far, and export refer to calling conventions in
16-bit Windows programming. They have no effect in 32-bit applications
and are maintained for backward compatibility only.
------------------------------------------------------------------------
----
-----Original Message-----
From: Tomasz Janeczko [mailto:amibroker@x...]
Sent: Saturday, September 22, 2001 1:14 PM
To: amibroker@xxxxxxxxxxxxxxx
Subject: Re: [amibroker] DLL interface
Hi,
Thank you. A quick question: does Delphi handle different calling
conventions like _stdcall, _cdecl, _fastcall ?
Best regards,
Tomasz Janeczko
===============
AmiBroker - the comprehensive share manager.
http://www.amibroker.com
----- Original Message -----
From: "Daniel Ervi" <trader@xxxx>
To: <amibroker@xxxxxxxxxxxxxxx>
Sent: Saturday, September 22, 2001 5:46 PM
Subject: RE: [amibroker] DLL interface
> Tomasz,
>
> Count me in on testing the Delphi .DLLs for you. I have a number of
> .DLL functions that I wrote for Neuroshell Trader in Delphi that would
> be very simple to port over to AmiBroker.
>
> I also use C++, so if you need any beta-testing help let me know!
>
> Daniel
>
> -----Original Message-----
> From: Tomasz Janeczko [mailto:amibroker@x...]
> Sent: Saturday, September 22, 2001 3:36 AM
> To: amibroker@xxxxxxxxxxxxxxx
> Subject: [amibroker] DLL interface
>
> 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
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>
>
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
|