How often does OnChartEvent get the attention of the processor?

 

Hi,

I am building a multipurpose EA, with the following approximate structure:

int OnTick()
{
 Call Very_Lengthy_Scanning_Function1();
 Call Very_Lengthy_Scanning_Function2();
 Call Very_Lengthy_Scanning_Function3();
}

void Very_Lengthy_Scanning_Function1()
// many loops here

void Very_Lengthy_Scanning_Function2()
// many loops here

void Very_Lengthy_Scanning_Function3()
// many loops here

void OnChartEvent(..)
// click some buttons here
Well the problem is that if I click a button, it gets too much time to un-click and run its code.
I even inserted an Alert function wright after the click is processed,
and that Alert is very slow to come,  so the problem is clearly that the "OnChartEvent" function is not listened to much often.
Can I remedy that? can I call that OnChartEvent explicitely from time to time inside my loops?
 
  1. When a Chart Event, Tick Received, or Timer Click happens, an entry is added to the queue (if not already there.) Once your code returns to the terminal, the next entry is run.

    While your lengthy OnInit is running, nothing else will ever run.

  2. Don't try to use any price or server related functions in OnInit (or on load,) as there may be no connection/chart yet:
    1. Terminal starts.
    2. Indicators/EAs are loaded. Static and globally declared variables are initialized. (Do not depend on a specific order.)
    3. OnInit is called.
    4. For indicators OnCalculate is called with any existing history.
    5. Human may have to enter password, connection to server begins.
    6. New history is received, OnCalculate called again.
    7. New tick is received, OnCalculate/OnTick is called. Now TickValue, TimeCurrent, account information and prices are valid.

  3. If your "scanning" takes too long, break it up into multiple sections using GetTickCount called from OnTimer after you get the first tick.
 

whroeder1

I am very sorry, but it was a Typo: I meant to say

int OnTick()
{
 Call Very_Lengthy_Scanning_Function1();
 Call Very_Lengthy_Scanning_Function2();
 Call Very_Lengthy_Scanning_Function3();
}

I corrected it above also...

Also, I am actually roughly breaking the operation with self made Tick counter... But it is not enough...

I guess my problem is that I am putting those Tick counters inside the lengthy functions that get always called, so I should better put them in the OnTick function itself...

Would some sleep works (This is an EA, not Indicator)?

 
If your lengthy functions have ArrayResize in them , try to PreSize these arrays on Init .
Create a context boolean (global) "ScanningBusy" and when its true do not allow Further scanning to get into the queue
 
Ziad El: Would some sleep works (This is an EA, not Indicator)?

What part of until "your code returns to the terminal," "nothing else will ever run" was unclear?

 
Does the returning to the Terminal means a One Single call of  OnTick()?
 

It is definitely getting better, by dividing the scanning Pairs x Timeframes into many packets, each packet taking one OnInit().

But still it is good to know your opinions.

As for Resizing Arrays, I am doing this already in OnInit (in fact all my arrays are made of custom purpose structurs).

 

So you have a set amount of Bars to process across all pairs.
Do you(or your users) need all pairs + timeframes ?

I suspect some ArrayCopying is also taking place sometimes in the scanning functions

 

I have in total 25 pairs and 3 timeframes (so 75 calls to the ScanManager)

The ScanManager will ask for 4 function to return 20 results for such Pair x TimeFrame.

Inside each of these 4 functions, I make just one filling of data (MqlRates rates[]; ArraySetAsSeries(rates,true); int copied=CopyRates(ThisPair,ThisTime,1,Tail,rates);...)

One function returns all possible data from Moving Averages and Rates (candles) (a dozen results)

Another one will return Zigzag data (one result)

Another one will return Bollinger Bands data (one result)

The final function will return many results regarding stochastic indicator.

I am confident my routines are efficient, since I ask (say) for rates once, and do all possible calculations before returning the results to the calling ScanManager.

Then the ScanManager will combine these 20 results in 7 types of combination (flavours...) by using simply custom made SumProduct function and pre-set weighting matrices (one for each flavour).

The ScanManager will then propose the best flavour (the one with the best grade), and supposedly, the BuyManager will adapt its SL, TP, LOTSIZE, etc to the winning flavour (work on progress.)

I am just fine tuning my Tick counters, so each on each counter the ScanManager will scan just (around) 10 Pairs x Time, so in 7 OnTick() I will complete the full scanning.

Of course, the first run will scan everything...

It is good to mention (and I am very proud of it, since I assume no one else made it before) than my software can work in parallel in 4 different windows:

The older window will assume all calculations, and the 3 remaining windows will easily take the best 3 results and 'invite' on their window the winning Pair x Times... So the user can see in one glance (Tiled Windows) the best 4 Pairs x Times at each time... with possibility of manual trading as well as automatic trading.


As for my customers, no, I am my own customer :)
 
Ziad El: Does the returning to the Terminal means a One Single call of  OnTick()?

Any Event Handling Functions

Ziad El: each packet taking one OnInit().

You meant OnTick

 
Ziad El:

Hi,

I am building a multipurpose EA, with the following approximate structure:

Well the problem is that if I click a button, it gets too much time to un-click and run its code.
I even inserted an Alert function wright after the click is processed,
and that Alert is very slow to come,  so the problem is clearly that the "OnChartEvent" function is not listened to much often.
Can I remedy that? can I call that OnChartEvent explicitely from time to time inside my loops?

First if you're using indicators data you could run it only once by bar. Just that I think will be enough to make your program much more faster.

Reason: