Hello,
I am posting this discussion, because I want to share what I have
learned, and get feedback about possibly doing these things an an easier way
--or perhaps some ideas will emerge for future versions of AB.
I reviewed Bill Barnards params code. It was a tough read for me,
but I was able to take his work and couple it with other hints on this site to
create almost everything I wanted to do with params:
1. I am plagued by edits to my AFL causing AB to do a "Reset all"
params about every 4th edit. I loved Bill's idea of saving the last
param values and that also fixes that problem. Also by saving each param
to its own file, I can edit my param AFLs on the fly and not loose most of the
settings.
2. I have a ton of params. I have to scroll several
screenfuls to find the ones I want, and I usually only want to change a few at
a time --but not always located next to each other. The current AB
(<5.0) does not remember which param sections were open
and collapse the others. So it is a pain to work with.
Bill's method of putting param statements inside of conditional
code and using the "reset all" button to force AB to rearrange the params
window is a clever idea. It makes it possible to have both the missing
functionality of remembering which sections are open, but also lets
me implement multiple levels of hierarchy or
conditional data params --a real plus.
3. Controlling the organization of the params window from AFL is
very flexible. By controlling which params are displayed, and replacing
the displayed text, I could go as far as being able to set any number of
params with what looked like a single param, by interacting with the user in a
"20 questions" sort of way. Not very user friendly to do that, but it
gives the flavor of the flexibility.
The down side is that it is a bit convoluted in the AFL. However, I
tried to modularize the AFL as much as possible and made a set of functions to
do do most of the dirty work.
I only put a single param in a persistent var (disk file). I read
in the disk params only once on the first AFL pass, and cache them into static
variables after that. When I change a param, I save it in both the
static var and the persistent var (write through). I did this for
performance reasons, though I did not try it without the cache to see how much
difference it really makes. List params are tricker, as I had to save
the text and find and save the selected item value.
I did identify params as belonging to a specific chart by including
GetChartID() as part of the name.
The example is mostly written so that only open params will have their
default values reset on command, but I did show one example of how to have
some or all params reset to default by a Reset All Params button.
The test AFL is not exhaustive for all param types, but
covers the basics.
There are some drawbacks to doing the params this way:
1. AFL does not have a command to do a "Reset all" of the
params after the current pass is complete, so the user must manually click the
"Reset all" button on the params window to make his param
reorganization selection take effect. This is a big
drawback!
2. The existing section labels may be removed, but the replacement
labels can not be colored to stand apart as section dividers.
3. I don't have a good way to initialize everything for the first
time. The user has to open all menus and "Reset Visible Params". I
had to choose to reset all params or just expanded params. To do both I
would have had to duplicate the defaults in two different places, and I choose
the version I thought would be more useful.
4. Because each param is stored in a separate file and for each
chart, the folder can have quite a few files in it. If a chart or param
is no longer used, the extra param files have to be manually cleaned up.
One idea is to use a separate folder for each chart just for
params.
I have uploaded the example AFL to the Amibroker Library as it was a bit
bulky to post here. It is named Flexible Parameter Layouts.
Please try it out and comment on the implementation and
add more ideas to improving it.
Dennis
On Jul 20, 2007, at 11:21 PM, Dennis
Brown wrote:
I just saw this and downloaded the files and read the
docs. This is
the answer to something I had wanted to do --hierarchical
and
conditional params. All we need now to make it fully
seamless, is to
have an AFL command that resets the params. Extremely
cool. Of
course it would be even better if it was built in so everyone
could
use it without a lot of AFL expertise.
Dennis
A strong second on Bill Barnards param statements! I
thought I'd
done some decent work with Params until I saw Bill's
presentation
last year. It was a jaw-dropper. I
realized that I was just
scratching the surface. I immediately glommed onto
his techniques
and implemented them in my own work.
Yes, Bill is the MASTER param dude! He makes AB stand up
and
dance! And it's not just some minor coding
tricks. His approach
the caching parameters and reusing them is a completely
new
approach. He thinks WAY outside the box.
Regards,
Dan.