[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [amibroker] Re: Discussion about Params, hierarchical, conditional, tricks...



PureBytes Links

Trading Reference Links

Neato!  I'll download and take a look..

d 

> -----Original Message-----
> From: amibroker@xxxxxxxxxxxxxxx 
> [mailto:amibroker@xxxxxxxxxxxxxxx] On Behalf Of Dennis Brown
> Sent: Tuesday, September 11, 2007 9:50 PM
> To: amibroker@xxxxxxxxxxxxxxx
> 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: amibroker@xxxxxxxxxxxxxxx
> >> [mailto:amibroker@xxxxxxxxxxxxxxx] On Behalf Of Dennis Brown
> >> Sent: Tuesday, September 11, 2007 12:59 PM
> >> To: amibroker@xxxxxxxxxxxxxxx
> >> 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: amibroker@xxxxxxxxxxxxxxx 
> [mailto:amibroker@xxxxxxxxxxxxxxx]
> >>>> On Behalf
> >>>> Of Dennis Brown
> >>>> Sent: Monday, September 10, 2007 9:44 AM
> >>>> To: amibroker@xxxxxxxxxxxxxxx
> >>>> 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 amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@xxx>
> >>>>>>>>> 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
> >>>>
> 
> 
> Please note that this group is for discussion between users only.
> 
> To get support from AmiBroker please send an e-mail directly to 
> SUPPORT {at} amibroker.com
> 
> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> http://www.amibroker.com/devlog/
> 
> For other support material please check also:
> http://www.amibroker.com/support.html
>  
> Yahoo! Groups Links
> 
> 
> 



Please note that this group is for discussion between users only.

To get support from AmiBroker please send an e-mail directly to 
SUPPORT {at} amibroker.com

For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/

For other support material please check also:
http://www.amibroker.com/support.html
 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/amibroker/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/amibroker/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:amibroker-digest@xxxxxxxxxxxxxxx 
    mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx

<*> To unsubscribe from this group, send an email to:
    amibroker-unsubscribe@xxxxxxxxxxxxxxx

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/