There is no solution that I like. I have a firm policy against using third party software as the solution. Once you get software on the resources (time and money) drip feed you can't get them off.
When it is time to upgrade, or do a reinstall, as a layperson, I end up with a full weeks work before I get the computer ready for action again, not to mention that 80% of the third party software I have purchased ends up unused after a few months and half the time, when I look through my programs list, I can't even remember what I downloaded some of them for in the first place. That is not my style ... I like to keep my computers clean and simple with a short program list (load Windows, load Office, Load AB and away I go. --- In [email protected], "brian_z111" <brian_z...@...> wrote: > > A lot of the heavy hitters collect and archive code from this forum etc and > manage their snippets via third party software .... I assume they cut/copy > and paste snippets as required e.g. Herman and others use Infoselect. > > > --- In [email protected], "brian_z111" <brian_z111@> wrote: > > > > So far I haven't had the need for long algorithms, or a lot of them, but I > > have found that maintaining AFL files lacks a few tools. > > > > Admittedly I am a messy worker and only saved by the fact that I don't > > archive other peoples code and don't archive all of my own forever. > > > > Up until now I have just relied on creating folder hierarchies and using > > the P_XYZ convention, etc, to delineate which files are primarily written > > as an indicator or scan etc. > > > > On top of that I have experimented with creating templates, with some all > > purpose code pre-written in them, but not as an #include. > > > > #includes seems like one of the 'logical' options .... the algorithmic > > traders seem to go down that path. > > > > I imagine that this also requires some ongoing management and possibly the > > need to remember what is in each #include template, as well as tracking > > versions, adding deleting new stuff as required .... I am generally opposed > > to continually adding tasks to my computer maintenance list. > > > > I am not sure if there are any execution implications that flow on from > > always loading up, at preprocessing, if you aren't going to use most of > > what is loaded (seems to be massive overkill). > > > > > > > > Three things seem to be lacking from my perspective: > > > > - finding the file you want from amongst a large number of files/folders > > ... AB needs the ability to search amongst the AFL files to find the file > > that has certain code in it > > > > > > - custom auto complete (like an excel macro that we assign to a key). > > > > One solution might be to use another editor, to get the benefit of search > > and customcomplete, but then any useful features in the AFLEditor will be > > lost and new maintenance issues created. > > > > For me the only two features of the AFLEditor I would miss are syntax > > checking and synchronisation between the current edit and the charts (I use > > apply indicator and watch the indicator to see how my code changes change > > the plot quite a bit ... if it wasn't for that basic need I would change > > editors). > > > > > > --- In [email protected], "ics4mer" <ics4mer@> wrote: > > > > > > > > > Hi all, > > > > > > Just wondering how people out there are organising their > > > AFL code between plots, backtests, explorations etc. > > > > > > Lets say I have 5 indicators which each require 50 lines > > > of code to draw a plot, in other words too large to > > > maintain in separate AFL files. > > > > > > Lets say I also want them all in a single exploration. > > > > > > So logically it seems that I should place each indicator > > > into an include file and include that into each of the AFL > > > "types" so I'd have "include <myTA_Tool.h>" in my b_backtest, > > > e_exploration, and p_plot files? > > > > > > Just wondering how everybody else is handling this? > > > > > > RZ > > > > > >
