Tomasz, Thanks much for answering. I was not insisting that it was necessarily a bug, I just think that if it's a legitimate code, then probably it should be documented. It's natural for a developer to count on a function to return one of the documented codes, otherwise some unexpected behaviour may occur, such as in my case.
Cheers, Sergei --- In [email protected], Tomasz Janeczko <gro...@...> wrote: > > Hello, > > It is not a bug. Status("action") == 0 is used for show arrows because > the formula is run in the context that is NOT indicator, nor backtest, > nor commentary, > nor exploration, etc. > The behaviour is correct and won't be changed. > You should either use action (old code that does not need detailed info) > or actionex (new code, that requires detailed info). > > Best regards, > Tomasz Janeczko > amibroker.com > > On 2010-02-21 19:08, wml67 wrote: > > Tomasz, > > > > I installed the current beta as you suggested and found that a > > bug/inconsistency I reported a while ago > > (http://finance.groups.yahoo.com/group/amibroker/message/143245) is still > > there. > > > > In a nutshell: in ShowArrows context Status("actionEx") is set to > > actionExAAShowArrows as expected BUT Status("action") is set to 0 (zero), > > which is an undocumented value. > > > > Insert the following line in any indicator code to reproduce: > > > > _TRACE("Action = " + WriteVal(Status("action"), 1.0) +", ActionEx = " + > > WriteVal(Status("actionEx"), 1.0)); > > > > This will screw up user code that relies on Status("action") returning a > > documented value, as it did screw up mine (see link above). > > > > I ended up having this in my code: > > > > if((Status("action") == actionBacktest) OR (Status("action") == 0)) > > { > > > > Cheers, > > > > Sergei > > > > > > > > --- In [email protected], Tomasz Janeczko<groups@> wrote: > > > >> Hello, > >> > >> Wrong approach. > >> > >> Instead use user-definable backtest / optimization charts that are > >> available since version 5.26. > >> It does everything you want without scripting and without need to worry > >> about synchronization. > >> > >> Excerpt from read me: > >> > >> CHANGES FOR VERSION 5.26.0 (as compared to 5.25.0) > >> Implemented user-definable report charts > >> > >> Now it is possible for the user to create any number of charts that will > >> be automatically generated and included in the backtest report. > >> > >> To add user-defined chart to the report, simply save your chart formula > >> under "Report Charts" folder. > >> > >> That's all. > >> > >> Any formula present in the "Report Charts" folder will be executed after > >> completion of the backtest using ~~~EQUITY as selected symbol. > >> > >> The beta ships with 3 sample charts: > >> a) portfolio equity > >> b) underwater equity (drawdown) > >> c) profit table > >> > >> The charts are displayed in alphabetical order (using file name as a > >> chart name). > >> > >> > >> Best regards, > >> Tomasz Janeczko > >> amibroker.com > >> > >> On 2010-02-21 15:06, wml67 wrote: > >> > >>> > >>> Hi, I'm trying to take snapshots of resulting equity curves during > >>> Optimization. > >>> > >>> Here's a snippet of AA code: > >>> > >>> // .... > >>> > >>> MAlb = Optimize("MA lookback",15,5,30,5); > >>> > >>> // .... > >>> > >>> if (Status("action") == actionPortfolio) > >>> > >>> { > >>> > >>> bo = GetBacktesterObject(); > >>> > >>> optPass = "MAlb" + MAlb; // optPass is unique string, containing info > >>> on this optimizer pass > >>> > >>> StaticVarSetText("SVoptPass", optPass); > >>> > >>> bo.Backtest(); > >>> > >>> oAB = CreateObject("Broker.Application"); > >>> > >>> oAB.RefreshAll(); > >>> > >>> // lots of processing, studying trades, creating custom metrics, etc > >>> > >>> // ................. > >>> > >>> } > >>> > >>> A snippet of code from the indicator I have running in the active window: > >>> > >>> optPass = StaticVarGetText("SVoptPass"); > >>> > >>> Plot(Foreign("~~~Equity", "C"), " Equity"); > >>> > >>> _N(Title = optPass); // title of the chart = static var set in AA code > >>> > >>> oAB = CreateObject("Broker.Application"); > >>> > >>> oAW = oAB.ActiveWindow; > >>> > >>> rc = oAW.ExportImage(optPass + ".png", 800, 600); // name of the file > >>> = static var set in AA code > >>> > >>> The idea is obvious: when the data is ready, AA code generates > >>> RefreshAll(), indicator code is thus invoked, it plots the curve and > >>> exports the image. The name of the file and the title on the chart > >>> should be equal. > >>> > >>> In fact this approach sorta works, but not entirely as expected. > >>> Firstly, most of the times filename and the chart title don't match, > >>> eg, filename is MAlb10 and the title of the chart is MAlb15. Sometimes > >>> one chart with the same title appears several times under different > >>> filenames. Some charts seem to be caught in mid-rendering or > >>> something, etc etc. > >>> > >>> Now I should say I tried all methods of invoking RefreshAll() and > >>> ExportImage() I know -- the one shown in the snippets above (for sheer > >>> simplicity), its modification using CreateStaticObject, also tried this: > >>> > >>> OWSHShell = CreateObject( "WScript.Shell" ); > >>> > >>> rc = OWSHShell.Run( "myscript.vbs", 4, False ); > >>> > >>> , tried all possible combinations of these... The results varied a > >>> little, but unfortunately none was reliable. I moved the code around, > >>> tried moving ExportImage() part from indicator into AA code (very end > >>> of Status("action") == actionPortfolio block) -- same stuff... I also > >>> had this wild thought: maybe indicator code is somehow being > >>> re-entered and enclosed it in the code below, but this didn't help > >>> either: > >>> > >>> if (NOT Nz(StaticVarGet("_snapshot_running"))) > >>> > >>> { > >>> > >>> StaticVarSet("_snapshot_running", True); > >>> > >>> // main indicator code > >>> > >>> StaticVarSet("_snapshot_running ", False); > >>> > >>> } > >>> > >>> I came to the conclusion that most function calls are asynchronous, > >>> RefreshAll() is not guaranteed to be honored when it's issued, > >>> rendering is not guaranteed to be finished when the next line of code > >>> after Plot() is being executed and so forth. That's why AFL is so > >>> quick, I guess... > >>> > >>> Now, if only I had a way to suspend the AA code for a sec yielding > >>> processor time to other threads (like indicator), I could solve my > >>> problem... (Tomasz? Not all code is real-time!) Synchronous version of > >>> Plot() would also help. > >>> > >>> Any ideas, anyone? It's a shame to be so close to the solution yet > >>> unable to reach it!!! > >>> > >>> Many thanks! > >>> > >>> > >>> > >>> > >>> > >> > > > > > > > > ------------------------------------ > > > > **** IMPORTANT PLEASE READ **** > > This group is for the discussion between users only. > > This is *NOT* technical support channel. > > > > TO GET TECHNICAL SUPPORT send an e-mail directly to > > SUPPORT {at} amibroker.com > > > > TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at > > http://www.amibroker.com/feedback/ > > (submissions sent via other channels won't be considered) > > > > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG: > > http://www.amibroker.com/devlog/ > > > > Yahoo! Groups Links > > > > > > > > > > >
