|
PureBytes Links
Trading Reference Links
|
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
<*> 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/
|