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 > > > > >> 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... > > > > > > >>>> Hi All, > > > > >>>> 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 > > >> (submissions sent via other channels won't be considered) > > > > >> For NEW RELEASE ANNOUNCEMENTS and other news always check 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 > > > (submissions sent via other channels won't be considered) > > > > > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG: > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > >
|