Do you mean that the first value in BarIndex() is always 0? This will be the case if you are running the latest version of Amibroker. The implementation of BarIndex has changed in version 5.29.6
http://www.amibroker.com/devlog/ Point 13 on the above page notes - "BarIndex() now returns values always starting from zero (even if QuickAFL is turned on)." Plugins have no effect on the way Amibroker handles data. You have access to exactly the same amount of data as you would in the afl script that you're running from. You can use gSite.GetArraySize() to get the number of bars available. I.e. BarCount. By the way Sid, in case you're not aware, there's an Amibroker dll forum here: http://finance.groups.yahoo.com/group/amibroker-dll/ Jules. --- In [email protected], "Rob" <sidharth...@...> wrote: > > Actually Jules, while I've got you, one further question... when you load the > AB stock arrays using gSite.GetStockArray() it seems to load the entire array > from a BarIndex() value of zero... > > I'm a touch surprised by that. Why doesn't quick AFL apply...? Because it > seems to when you pass arrays as parameters to the C++ function from AFL. > > --- In [email protected], "jooleanlogic" <jooleanl@> wrote: > > > > As far as I know Sid, the ftol2 is the assembler code for converting a > > float to an int. > > Are you trying to step into that line of code (F11) during debugging or > > does it give you that error no matter what? > > There's not much point stepping into the assembler file for that, just step > > over it with F10. > > > > Mp stuff's coming along fine. Visually, I've been using it for a few months > > but work under the hood will be ongoing for a while. > > > > Jules. > > > > --- In [email protected], "Rob" <sidhartha70@> wrote: > > > > > > TJ or anyone else, > > > > > > I'm just playing around with the Visual Studio debugger looking at TJ's > > > 'ExampleMA' function... when I get to the following line, > > > > > > int nRange = (int) ArgsTable[ 1 ].val; > > > > > > I consistently get told that the 'source code is not available'... it > > > seems to be looking for a file "ftol2.asm"... > > > > > > I have been googling all morning and seem have enabled the automatic > > > downloading of all the Microsoft symbol's at > > > http://msdl.microsoft.com/download/symbols > > > > > > Any ideas what's going on here...? > > > > > > TIA > > > > > > --- In [email protected], "jooleanlogic" <jooleanl@> wrote: > > > > > > > > Yes you can attach to the Broker.exe process and step through your dll > > > > code. > > > > The Visual C++ Debugger is excellent. > > > > > > > > As DNSFAB noted, the C code equivalent is not as straight forward as > > > > afl as there is glue code needed, but Tomasz has made the plugin as > > > > easy as possible to get started with and there's clear code examples. > > > > If you're new to C, then that's going to be your biggest headache > > > > initially. > > > > > > > > Jules. > > > > > > > > --- In [email protected], "Rob" <sidhartha70@> wrote: > > > > > > > > > > Tuzo, > > > > > > > > > > Thanks. But I'm pretty much where you described. I have a very > > > > > efficient piece of AFL code that HAS to use loops. There is simply no > > > > > other way to do it... and I've spoken to some very good AFL coders in > > > > > the process. > > > > > > > > > > That routine takes up about 70% of my AFL execution time... I'm > > > > > running 12 charts and have to spilt them across 2 separate instances > > > > > of AmiBroker to keep my speed at day trading levels. (i.e. I'm > > > > > overloading the CPU on one instance) > > > > > > > > > > I think I'm definitely at the point where optimization of speed via a > > > > > C++ dll would be beneficial!!! I'd just be interested to see how much > > > > > speed it actually adds. > > > > > > > > > > While I'm here, can I ask a question about debugging AB dll's... > > > > > what's the best way...? Can I attach to the AB process or can I > > > > > simulate an AB call within Visual Studio...? > > > > > Sorry if that's a silly question... but I'm brand new to Visual > > > > > Studio... > > > > > > > > > > > > > > > --- In [email protected], "tuzo_wilson" <j.tuzo.wilson@> > > > > > wrote: > > > > > > > > > > > > --- In [email protected], "Rob" <sidhartha70@> wrote: > > > > > > > > > > > > > > Thanks Jules. Very informative. > > > > > > > > > > > > > > "This is why you should always try and use the built in functions > > > > > > > and array arithmetic operators where possible." > > > > > > > > > > > > That makes sense. Not only are they fast but they've been tested > > > > > > by thousands of users. > > > > > > > > > > > > > Or indeed code any looping structures that can't be avoided in > > > > > > > AFL and are called regularly in C++ as a DLL. > > > > > > > > > > > > Not to start a religious war, but as the saying goes, "premature > > > > > > optimization is the root of all evil". > > > > > > > > > > > > http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize > > > > > > > > > > > > Why not keep it simple and code in AFL, then see how that > > > > > > performance meets with the requirements? If there actually is an > > > > > > issue, then some design changes can be made to increase performance. > > > > > > > > > > > > > > > > > > Tuzo > > > > > > > > > > > > > > > > > > > > >
