|
Dennis,
Some quick comments.
1) Thanks for doing this and sharing your work.
I loaded it and as you probably knew it would, it fired up right
away.
2) I've mined Bill's parameter work recently for a
conditional ATC write and your work is going into the InfoSelect
datamine.
3) In addition to using this in flexible
parameters, the use of fileIO, dynamic variable naming for VarSet,
string handling, and static variables examples are clear and
useful/productive in other areas.
Regards
Joe L.
----- Original Message -----
From: Dennis Brown
To: amibroker@xxxxxxxxxps.com
Sent: Tuesday,
August 14, 2007 3:00 PM
Subject: [amibroker]
Discussion about Params, hierarchical, conditional, tricks...
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
On Jul 20, 2007, at 6:51 PM, dan_public@xxxxxxxxnet wrote:
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.
|