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" <sidharth...@...> 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 > > > > > > > > > >
