|
Bruce,
Thank you! That works perfectly to force an immediate refresh. A simple and elegant solution.
I should caution anyone contemplating using this, that it should only be used when you want to chain several passes together without any delays, but not as a normal update mode. In other words, it should only be used under specific conditions that will only last one or a very few passes, because this almost completely locks out the UI until the sequence of passes is completed. Sending the F5 key overrides any other UI operations.
Now I am able to do all the normal RequestTimedRefresh( -1 to n ) modes, plus an auto time mode to refresh at 1 or 2 seconds longer than the time it takes to execute the AFL, plus the new 0 second delay mode for internal context switching sequences.
Best regards,
Dennis
On Mar 10, 2009, at 7:14 AM, bruce1r wrote:
"I would be happy to create a condition that forces an immediaterefresh of my chart after it exits. What kinds of events could I makehappen just before I exit my chart AFL that would force an immediaterefresh?"
_TRACE( " " );
_TRACE( "START" );
Plot( C, "C", colorDefault );
if ( NOT Nz( StaticVarGet( "_oneshot" ) ) )
{
_TRACE( " Normal execution" );
_TRACE( " SENDKEYS");
StaticVarSet( "_oneshot", True );
WSHShell = CreateObject( "WScript.Shell" );
WSHShell.AppActivate( "AmiBroker" );
WSHShell.Sendkeys( "{F5}" );
}
else
{
_TRACE( " Refresh" );
StaticVarSet( "_oneshot", False );
}
_TRACE( "END" );
I have experimented and notice that my DLL which pokes the --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown & lt;see3d@xxx> wrote:
>
> 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 wrot e:
>
> > 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 ta ke 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 numb er 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 p asses, 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 coul d 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 amibroker@xxxxxxxxxxxxxxx, "sidhartha70" sidhartha70@
> > >> 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 amibroker@xxxxxxxxxxxxxxx, "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
> >
> >
> >
> >
> >
> &g t;
> > >> ------------------------------------
> >
> > >> **** 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
> >
> >
> >
> >
> >
> >
> > > ------------------------------------
> >
&g t; > > **** 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
|