Herman,
Your solution is clever, but does not apply to me. I already have
realtime event handling in my general includes for my chart -- and I
really only have one realtime chart that I use, so that is not my
problem.
However, your other statement is interesting:
"You could also write a DLL to deal with non-price events. You could
probably force a refresh by simulating some event that refreshes afl."
I would be happy to create a condition that forces an immediate
refresh of my chart after it exits. What kinds of events could I make
happen just before I exit my chart AFL that would force an immediate
refresh?
I have experimented and notice that my DLL which pokes the Reset all
button and that does cause a refresh of the chart, so one down.
Clicking on the chart via DLL might cause a refresh (or other side
effects), or maybe not since it is still in the AFL when the click
happens. Is there some foolproof way to do this that you have
discovered?
To give you the idea, here is the comments from my sequencer to change
parameter sets when selecting a new timeframe or named set in Flexible
Parameters.
// make a sequence to close all menus, switch sets, then restore menus
again and the timeframe setting in prefs
// Pass 1: New set or symbol detected, Close all menus (Internal
variables switched, but not the Params window ones)
// Pass 1.5: DLL clicks the Reset all button
// if we have a pending reset at this point, the params window must
not be open, so skip all the rest
// Pass 2: Close all menus and recompile(clear) the Params window params
// Pass 3: Hold all menus closed in case the UI did not get the Reset
all yet
// Pass 3.5: DLL clicks the Reset all button
// Pass 4: Recompile the Params window params to sync Params window to
new internal params
//
// Since this can be slow, we also speed up the processing by reducing
the number of bars processed in loops
And while I am discussing this sequence, it sure would be nice to have
a status that says the current AFL pass is compiling the parameters.
Then I could close the loop and make sure my request to reset all
parameters was indeed done on the next pass. I am always worried that
there is some condition that will cause it to not happen. Right now,
I am giving it two passes just to make sure, since it sometimes failed
with just one pass. Another slow down.
BR,
Dennis
On Mar 9, 2009, at 4:35 PM, Herman wrote:
You could use the common include (put it in all your formulas) i
mentioned in the other email. It would execute the second you exit a
formula, and execute whatever you need before entering the next
formula, without respect for which pane or window was completed or
which is on the queue to execute next.
herman
Monday, March 9, 2009, 4:20:32 PM, you wrote:
>
Herman,
What I said is that I have to exit AFL between passes. That is to
let operations take place that will not run while I am inside the
AFL loop. For instance, recompiling the Parameters window (after
poking the Reset all button with my DLL) takes a whole new AFL pass
from the start. Poking a Preference and applying it with AutoIt can
not take effect while inside the AFL loop. Some things happen at a
higher level than AFL and I have to exit AFL and get back in to let
them take place.
If you know another way to do this, I am all ears.
BR,
Dennis
On Mar 9, 2009, at 3:41 PM, Herman wrote:
Dennis, for code that needs to re-execute before the next second
refresh you can use a while loop. For example, i use the following
in some of my code:
Repeat = 0;
While( Repeat )
{
most of my code in here, if it requires re-execution it sets Repeat
to True. It will re-execute at max afl execution rates until my code
sets Repeat to False.
}
This works well however you want to put limits on the number of
repeats, or break out on the next second refresh, to prevent it from
staying in the loop to long.
herman
Monday, March 9, 2009, 12:19:17 PM, you wrote:
> Gordon,
> AFL is event driven. Some event causes your AFL program to execute.
> You can check to see which event caused it to run and run all or a
> portion of your program depending on the event.
> Check back on your suggestion again for an example of bar closed.
> You can suggest a new event type that is not already covered if you
> need one. However, because the AFL engine is shared between all
> charts, a particular chart's AFL will have to wait until a currently
> executing chart is done before the next one can be executed. So the
> AFL engine looks for the next chart that has an event only when it
is
> idle.
> One event that has been suggested before, that would be useful to me
> as well, is an AFL self programmed event. This would be some AFL
> statement that would cause the currently running chart to be put
into
> the queue to be run again as soon as possible --subject to some CPU
> loading constraints, or after a specified delay less than a second.
> Currently, if no quotes are coming in, one second is the fastest
> guaranteed repeat AFL execution. I have some sequences related to
> changing parameters that require 4 passes of the AFL to trigger
> certain conditions that have to happen between AFL passes. I shut
> down all but the essential AFL during these sequential passes, but
> time drags on when you have to wait for one second each pass.
> Best regards,
> Dennis
> On Mar 9, 2009, at 11:50 AM, Gordon wrote:
>> Hi sidhartha70,
>> Thanks for your thoughts. I actually did try something like that,
>> but seemed to find some sensitive timing issues. My objective was,
>> as soon as I detected a new bar (this was using one minute bars),
to
>> access information about the just completed bar. At least in my
>> experience, it was necessary to introduce a delay so that the
>> Ref(XYZ, -1) function returned information about the bar I was
>> interested in and not the one before it. In the end, I just felt
>> uncomfortable that I had an approach I could rely on as being rock
>> solid.
>> I think I'll revisit it, but in the end, would love to be able to
>> rely on a built-in function. Assuming I'm successful in revisting a
>> one-off solution, I'll post the results (code).
>> The exploration start/stop is a little tougher. One way to do it is
>> to invoke AA through VBScript, and do your own pre- and post-
>> processing. Another might be to create ficticious symbols
guaranteed
>> to be the first and last symbols visited by the exploration code
and
>> use the name() function to test for them.
>> Regards,
>> Gordon
>> --- In [email protected], "sidhartha70" <sidharth...@...>
>> wrote:
>>> Gordon,
>>> I'm pretty sure you can code for this type of stuff already in
AFL.
>>> You can simply set up your on checks to see if an event has
>>> occurred, and if it has, execute any code you want...
>>> For example, OnBar() that you are talking about could be achieved
>>> by looking for a change in DateTime() of the most recent bar...
>>> --- In [email protected], "Gordon" <gordon@> wrote:
>>>> Hi All,
>>>> I just posted a new suggestion at www.Amibroker.com/feedback. It
>>>> occurred to me that most AB users don't know about or use the
>>>> feedback area. So, I wanted to take a second to highlight the
>>>> value of using the site to add suggestions and provide feedback
>>>> for existing ones. If you haven't gone there (you need to be a
>>>> registered AB user), there are tons of neat suggestions.
>>>> My second reason for posting is, I'm curious to know how many
>>>> would find the addition event-based AFL coding useful -- e.g.
>>>> functions you write that would be executed automatically upon the
>>>> occurrence of specific events, such as the current bar jused
>>>> completed (geared toward tick and other intra-day charts),
>>>> backtester started, exploration finished, etc.
>>>> Regards,
>>>> Gordon
>> ------------------------------------
>> **** IMPORTANT PLEASE READ ****
>> This group is for the discussion between users only.
>> This is *NOT* technical support channel.
>> TO GET TECHNICAL SUPPORT send an e-mail directly to
>> SUPPORT {at} amibroker.com
>> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
>> http://www.amibroker.com/feedback/
>> (submissions sent via other channels won't be considered)
>> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
>> http://www.amibroker.com/devlog/
>> Yahoo! Groups Links
> ------------------------------------
> **** IMPORTANT PLEASE READ ****
> This group is for the discussion between users only.
> This is *NOT* technical support channel.
> TO GET TECHNICAL SUPPORT send an e-mail directly to
> SUPPORT {at} amibroker.com
> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> http://www.amibroker.com/feedback/
> (submissions sent via other channels won't be considered)
> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> http://www.amibroker.com/devlog/
> Yahoo! Groups Links
