Thanks Dennis. I fall in the other interested persons, though too much of a novice to comment and add stuff!
Regards, Kar --- In [email protected], Dennis Brown <[EMAIL PROTECTED]> wrote: > > Dingo and other interested persons, > > Version 2.3 of "Flexible Parameter Layouts" just uploaded to the AFL > Library. > > I added the ability to select different named sets of params for a > chart. > > While working on my system, I realized that there are many different > param setups for different situations that I would like to keep, or > even to flip back and forth for comparison of the trading indicator > results. For instance, if the market changes character from trending > to range bound, I could switch to the alternate settings I used last > time that happened. > > So I added a "Param Set Name" parameter to select a given set. If > the set does not exist yet, it will create a set with default > values. I also removed the chartID from the individual param files > so that the set folder could be copied to another chart's sets. > > I also cleaned up the reset and startup sequences to run smoother, > and switch some of the example code, since I was not happy with the > Manual Trades not working well with the current version. > > Enjoy, > Dennis Brown > > > On Sep 11, 2007, at 9:57 PM, dingo wrote: > > > Neato! I'll download and take a look.. > > > > d > > > >> -----Original Message----- > >> From: [email protected] > >> [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Brown > >> Sent: Tuesday, September 11, 2007 9:50 PM > >> To: [email protected] > >> Subject: Re: [amibroker] Re: Discussion about Params, > >> hierarchical, conditional, tricks... > >> > >> Dingo, > >> > >> Version 2.2 just uploaded to the AFL Library. > >> > >> That is a good idea. If I had a non-displayable character that was > >> still recognizable by AB as part of a name, then I could > >> automatically append another character for each new top level menu. > >> I already use "." and "_" and spacing for real things to align > >> indents etc., so a non printable would be ideal. > >> > >> While experimenting, I noticed that some characters (like "\" > >> or "&") > >> displayed other things in the label --it seems all characters > >> are not > >> treated equally. It looks like they may be treated like a text > >> command escape sequence or something. Leading and trailing blanks > >> are removed from a name, and a tab char embedded will display a > >> section header. My experimenting did not yield any good prospects. > >> > >> However, a light bulb went off in the process, and I realized > >> through > >> a bit of experimenting that I can have half my cake and eat it too! > >> > >> If I treat the _Section_Begin("SectionName"); command as just an AFL > >> command to display a section header, and create the unique names for > >> the section, I can make them conditionally pop up and say what I > >> want, when I want it. So, I can replace the top level menu with a > >> section divider when it is open, to make the sections stand out, AND > >> make the names unique. I do not have to have a _Section_End command > >> to make this work. This is cool and is 90% of what I wanted > >> to get. > >> I still have to use up one param slot below an open section to close > >> it, but that is not too bad. > >> > >> I just have to keep in mind that using params this way is not meant > >> for the kind of drag and drop functionality built into AB at the UI > >> level, but more as a complete custom user interface for a complex > >> system. Each has its place. > >> > >> If I could tell what state the native top level param section is in > >> (open or closed) or alternatively, that it was clicked on like a > >> ParamTrigger(), I could even get 98% of what I want. > >> > >> Tomasz put a lot more flexibility into the way Params and Sections > >> work than I realized when I started this task --I just can't quite > >> get a hook into everything I would like to make this seamless. > >> Unfortunately, the next change TJ makes to the Params window could > >> break my methods if he does not make a specific allowance for > >> them or > >> an alternative. That is the risk of coding on the edge. > >> > >> Version 2.2 just uploaded to the AFL Library. > >> > >> Thanks, > >> Dennis > >> > >> > >> On Sep 11, 2007, at 1:43 PM, dingo wrote: > >> > >>> Try adding non-displayable characters to the end of the literal like > >>> null(s). > >>> > >>> Or add a "." or "_" to the end. Or an extra space between words. > >>> > >>> d > >>> > >>>> -----Original Message----- > >>>> From: [email protected] > >>>> [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Brown > >>>> Sent: Tuesday, September 11, 2007 12:59 PM > >>>> To: [email protected] > >>>> Subject: Re: [amibroker] Re: Discussion about Params, > >>>> hierarchical, conditional, tricks... > >>>> > >>>> Hi, > >>>> > >>>> I have noticed a small gotcha to my method of Params --you must not > >>>> "Label" two params the same thing, even though they are in > >> different > >>>> "pseudo sections". The displayed label for a param is the "Name" > >>>> that it is known by internally (with the addition of the real > >>>> section > >>>> name appended to it, etc.). > >>>> > >>>> Normally _Section_Begin("SectionName") could be used to "divide" > >>>> params up so that when you have for instance, 2 moving average > >>>> sections, and want to label a param in each as "Periods" > >> there is no > >>>> conflict. However, it also displays a top level menu item in the > >>>> params window. > >>>> > >>>> I have replaced menu sections with my own top level menus. > >> in order > >>>> to conserve param window space, I do not use the sections > >>>> commands to > >>>> divide parameters, or if I do, I would have to call the > >> section name > >>>> "" to keep it from displaying anything in the Params window --which > >>>> does not solve this problem. > >>>> > >>>> I would like to be able to use the _Section commands, but > >> be able to > >>>> suppress the output to the Params window or solve the problem > >>>> in some > >>>> other way --to be able to display a param label that is not always > >>>> unique for esthetic reasons. I have a unique "ParamName" for every > >>>> param of course, but I would not like to display that as > >> part of the > >>>> displayed label name. > >>>> > >>>> Ideas anybody? > >>>> > >>>> Best regards, > >>>> Dennis > >>>> > >>>> On Sep 11, 2007, at 7:47 AM, Dennis Brown wrote: > >>>> > >>>>> Joe, > >>>>> > >>>>> I have not run a speed test other than just watching the "display > >>>>> chart timing" preference. I can not see any time > >> difference between > >>>>> a a fully open and a collapsed window (which only > >> executes half the > >>>>> parameter code). So I would have to say it is in the noise > >>>> level. I > >>>>> have a lot of very compute intensive indicators, and that > >>>> is where my > >>>>> time goes. However, I have been making progress on creating new > >>>>> algorithmic approaches to some which have gained me an order of > >>>>> magnitude speed increase. That has given me the breathing room to > >>>>> move forward with my system ideas. > >>>>> > >>>>> Dennis > >>>>> > >>>>> On Sep 11, 2007, at 1:39 AM, J. Biran wrote: > >>>>> > >>>>>> > >>>>>> I am just curious, does using this very impressive code > >>>> slow down AB? > >>>>>> > >>>>>> > >>>>>> Joseph Biran > >>>>>> ____________________________________________ > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: [email protected] > >> [mailto:[EMAIL PROTECTED] > >>>>>> On Behalf > >>>>>> Of Dennis Brown > >>>>>> Sent: Monday, September 10, 2007 9:44 AM > >>>>>> To: [email protected] > >>>>>> Subject: Re: [amibroker] Re: Discussion about Params, > >> hierarchical, > >>>>>> conditional, tricks... > >>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> I have uploaded a new version (2.1) to the AB Formula Library > >>>>>> "Flexible Parameter Layouts Version 2.1" > >>>>>> > >>>>>> I made it much more friendly when starting a new chart > >>>> with it, and I > >>>>>> also added a button for resetting all parameters to > >>>> defaults --hidden > >>>>>> or not. It turned out to be easier than I thought to do that --I > >>>>>> just force all the menus open for one pass of the reset to > >>>> defaults. > >>>>>> It can also be tried without installing AutoIt now > >> because it lets > >>>>>> you know with a popup window that it is not installed and > >>>> asks you to > >>>>>> Manually click the Reset all button when needed (a pain, > >> but it is > >>>>>> polite). > >>>>>> > >>>>>> This is getting closer to being ready to put on the UKB. > >>>>>> Critical comments on my AFL are very welcome. > >>>>>> > >>>>>> Best regards, > >>>>>> Dennis > >>>>>> > >>>>>> > >>>>>> On Sep 8, 2007, at 9:26 PM, Dennis Brown wrote: > >>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> Sorry to respond with criticism of my own post so soon, > >> but one of > >>>>>>> the things I do not like about my new Params methods is > >>>> that when a > >>>>>>> new chart is started, a new set of param files have to > >> be created, > >>>>>>> and the only way to initialize them to their defaults is to open > >>>>>>> every level (which can be tricky with a lot of sub menus) > >>>> and click > >>>>>>> the reset all open params. I would like to be able to > >>>> just start > >>>>>>> out > >>>>>>> with everything initialized by a single "Reset ALL" button. > >>>>>>> > >>>>>>> I can do that easily enough. However, I did not want to > >>>> give up the > >>>>>>> ability to also reset only the open params. Doing both > >>>> means that I > >>>>>>> would have to supply the default values in two > >> different places in > >>>>>>> the AFL. I really only wanted to specify the default > >> value in one > >>>>>>> place to remove possible errors --so I would have to > >>>> assign another > >>>>>>> bunch of intermediate variables just to hold default values. > >>>>>>> > >>>>>>> The reason I am mentioning this is because I want to > >>>> publish this in > >>>>>>> the UKB, but I want to do it right the first time that > >>>> covers all > >>>>>>> the > >>>>>>> bases with a solution that is simple to use. I wanted > >> to get some > >>>>>>> other takes or implementation ideas on this reset to > >> default issue > >>>>>>> before I do a lot of rewriting of my AFL and examples. > >>>>>>> > >>>>>>> Just to recap, the form that a param takes is two parts. > >>>> The first > >>>>>>> reference is the one that always reads in the param value > >>>> every AFL > >>>>>>> pass (first pass from a file, other passes from a static > >>>> variable). > >>>>>>> The second reference is made inside some conditional AFL and is > >>>>>>> executed only if the param is open in the Parameters > >>>> window. The > >>>>>>> new > >>>>>>> form would look like: > >>>>>>> > >>>>>>> myParamVar = GetParamVar("ParamName", > >> defaultxxx=default); //this > >>>>>>> default on for Reset ALL Params > >>>>>>> > >>>>>>> if (thisMenuIsOpen) > >>>>>>> { > >>>>>>> myParamVar = Param2("paramName", "ButtonText", > >>>> defaultxxx, minVal, > >>>>>>> maxVal, stepVal); //this default on for Reset Visible Params > >>>>>>> } > >>>>>>> > >>>>>>> Comments? > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Dennis > >>>>>>> > >>>>>>> On Sep 8, 2007, at 12:13 AM, Dennis Brown wrote: > >>>>>>> > >>>>>>>> Thanks for your interest. > >>>>>>>> > >>>>>>>> I created and uploaded an Example AFL to the AmiBroker Library > >>>>>>>> under > >>>>>>>> the name: > >>>>>>>> Flexible Parameter Layouts Version 2.0 > >>>>>>>> > >>>>>>>> Enjoy, and please give feedback for improvements. > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Dennis > >>>>>>>> > >>>>>>>> On Sep 7, 2007, at 12:53 PM, Dennis Brown wrote: > >>>>>>>> > >>>>>>>>> Experienced AFL Scripters, > >>>>>>>>> > >>>>>>>>> I have completed coding a complete replacement set of AFL > >>>>>>>>> Param...() > >>>>>>>>> functions that save the parameters in files and allow > >>>> hierarchical > >>>>>>>>> menus including conditional menus (like if different > >> ParamList() > >>>>>>>>> selections need to show additional or different > >> parameters). It > >>>>>>>>> also > >>>>>>>>> remembers the last state of the open menus. > >>>>>>>>> > >>>>>>>>> They look just like the old param... statements, > >> except with the > >>>>>>>>> addition of a name for the saved parameter, and there are some > >>>>>>>>> differences with how they are used in the AFL structure. > >>>>>>>>> > >>>>>>>>> It requires installing the free AutoIt (see below) to function > >>>>>>>>> properly (AutoIt installs a COM that lets AFL push the > >>>> "Reset all" > >>>>>>>>> button on the parameters window). > >>>>>>>>> > >>>>>>>>> You can not successfully mix old style and new style > >>>> params in the > >>>>>>>>> same set window (because the new ones will keep > >>>> resetting the old > >>>>>>>>> ones to default values), > >>>>>>>>> > >>>>>>>>> The new top level menus do not have the nice darker > >> tan color of > >>>>>>>>> the > >>>>>>>>> original. > >>>>>>>>> > >>>>>>>>> I will go to the effort of uploading an example set > >> of these if > >>>>>>>>> anyone is interested in using or playing with them. > >>>>>>>>> However, only more experienced AFL scripters should > >>>> attempt to use > >>>>>>>>> these. > >>>>>>>>> > >>>>>>>>> Just let me know. > >>>>>>>>> > >>>>>>>>> (I attached a couple of screen shots to the end of this > >>>> email for > >>>>>>>>> those who get the email version) > >>>>>>>>> > >>>>>>>>> Dennis > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Aug 15, 2007, at 11:51 PM, Dennis Brown wrote: > >>>>>>>>> > >>>>>>>>>> Bruce, > >>>>>>>>>> > >>>>>>>>>> Thank you. This is great! > >>>>>>>>>> > >>>>>>>>>> I have it running and I am recoding my params AFL > >> logic to take > >>>>>>>>>> advantage of single click operation (since the > >> second click is > >>>>>>>>>> automatic now). This opens up a lot of other things I wanted > >>>>>>>>>> to do > >>>>>>>>>> with the UI but could not do it with AFL before. > >>>>>>>>>> > >>>>>>>>>> Stay tuned! > >>>>>>>>>> Thanks again, > >>>>>>>>>> > >>>>>>>>>> Dennis > >>>>>>>>>> > >>>>>>>>>> On Aug 15, 2007, at 8:43 PM, bruce1r wrote: > >>>>>>>>>> > >>>>>>>>>>> AFL code fragment - > >>>>>>>>>>> > >>>>>>>>>>> autoit = CreateStaticObject( "AutoItX3.Control" ); > >>>>>>>>>>> if ( ! IsNull( autoit ) ) > >>>>>>>>>>> { > >>>>>>>>>>> rc = autoit.controlclick( "Properties of:", > >> "Reset all", > >>>>>>>>>>> 403 ); > >>>>>>>>>>> } > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> AutoItX COM control can be found at - > >>>>>>>>>>> > >>>>>>>>>>> http://www.autoitscript.com/autoit3/downloads.php > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> --- In [email protected], Dennis Brown <see3d@> > >>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Tomasz, > >>>>>>>>>>>> > >>>>>>>>>>>> Thank you for your comments. That helps me understand how > >>>>>>>>>>>> far I > >>>>>>>>>>>> might take this idea on my own. > >>>>>>>>>>>> I appreciate that you are open minded about how > >>>> people may use > >>>>>>>>>>>> AB in > >>>>>>>>>>>> ways not originally intended. > >>>>>>>>>>>> > >>>>>>>>>>>> A question for you or anyone else: > >>>>>>>>>>>> I am not a Windows programmer (I run everything on Macs --I > >>>>>>>>>>>> use a > >>>>>>>>>>>> virtual XP for AB). > >>>>>>>>>>>> I was wondering if it is possible for AFL (perhaps > >> through a > >>>>>>>>>>>> DLL) to > >>>>>>>>>>>> click the Parameter Window "Reset all" button for me? > >>>>>>>>>>>> (short of a robotic mouse of course) > >>>>>>>>>>>> > >>>>>>>>>>>> Thank you, > >>>>>>>>>>>> Dennis > >>>>>>>>>>>> > >>>>>>>>>>>> On Aug 15, 2007, at 11:29 AM, Tomasz Janeczko wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Param window was designed to be used as parameters for > >>>>>>>>>>>>> indicators > >>>>>>>>>>>>> exactly the way as > >>>>>>>>>>>>> formulas shipped with AmiBroker use them. And > >> that won't be > >>>>>>>>>>>>> changed. > >>>>>>>>>>>>> > >>>>>>>>>>>>> You are free however to (ab)use it in any other way you > >>>>>>>>>>>>> want :-) > >>>>>>>>>>>>> Here is the beauty of AmiBroker that it actually > >>>> allows to be > >>>>>>>>>>>>> used > >>>>>>>>>>>>> in ways that were not > >>>>>>>>>>>>> originally designed for unlike products from other, bigger > >>>>>>>>>>>>> companies that usually > >>>>>>>>>>>>> apply the design of "the program knows better than you". > >>>>>>>>>>>>> > >>>>>>>>>>>>> I am often asked why program "does not prevent from doing > >>>>>>>>>>>>> this or > >>>>>>>>>>>>> that". And the answer > >>>>>>>>>>>>> is the flexibility - you can do what you want as > >> long as you > >>>>>>>>>>>>> know > >>>>>>>>>>>>> what you are doing. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>> Tomasz Janeczko > >>>>>>>>>>>>> amibroker.com >
