tol64: Thank you. I'll keep that in mind. Maybe someone can tell me when this column is filled in and when it is not (as in my case). If anything, I will ask at Service Desk.
This is the identifier assigned to your order by the execution platform - the exchange.
Found this uncertainty with type_filling: only one mode is allowed
string symbol = "EURUSD";
int flags = SymbolInfoInteger( symbol, SYMBOL_FILLING_MODE );
//разрешен только SYMBOL_FILLING_ALL_OR_NONE
at the same time SendOrder places orders equally successfully with
MqlTradeRequest request;
request.type_filling = ORDER_FILLING_FOK; //соответствующий флаг разрешения 1
as well as with
request.type_filling = ORDER_FILLING_RETURN; //соответствующий флаг разрешения 0
And after successful placement the actual property of the placed order ORDER_TYPE_FILLING always = ORDER_FILLING_RETURN even if we have specified request.type_filling = ORDER_FILLING_FOKin the query
MqlTradeResult result;
OrderSelect( result.order );
int tpAfter = OrderGetInteger( ORDER_TYPE_FILLING );
//tpAfter всегда = ORDER_FILLING_RETURN
Seems to me a mismatch between the list of allowed modes and the actual properties of the order after placement
Please help to analyse the situation, the following code:
void CStrategyMA::FitnessFunction(int chromos)
{
double res=0.0;
// Выбор символа (m_strategy_symbol) из масива используемых символов (m_name_symbols[]) количаством (m_count_symbols)// Пример: m_count_symbols = 1; m_name_symbols[0] = "EURUSD.e";
m_strategy_symbol = m_name_symbols[(int)MathRound(Colony[1][chromos]*(m_count_symbols-1))];
// Выбор периода из масива по индексу (от PERIOD_M5 (индекс - 5) до PERIOD_D1 (индекс - 19))// Для наглядности:// ENUM_TIMEFRAMES PERIOD_INDEX [22] = {PERIOD_CURRENT,// PERIOD_M1, PERIOD_M2,PERIOD_M3,PERIOD_M4,PERIOD_M5,PERIOD_M6,PERIOD_M10,PERIOD_M12,PERIOD_M15,PERIOD_M20,// PERIOD_M30,PERIOD_H1,PERIOD_H2,PERIOD_H3,PERIOD_H4,PERIOD_H6,PERIOD_H8, PERIOD_H12,PERIOD_D1, PERIOD_W1,// PERIOD_MN1};
m_period = PERIOD_INDEX[(int)(MathRound(Colony[2][chromos]*5)+14)];
// Освобождаю дескриптор загруженого ранее индикатораIndicatorRelease(m_handle);
// Создаю новый индикатор с периодом - (int)(MathRound(Colony[3][chromos]*100)+1)// от 1 до 100
m_handle=iMA(m_strategy_symbol,(ENUM_TIMEFRAMES)m_period,(int)(MathRound(Colony[3][chromos]*100)+1),0,MODE_EMA,PRICE_CLOSE);
// Без использования Sleep(1000); - генерируется последующая ошибка при использовании в коде ф-ции: CopyBuffer// "ошибка доступа к историческим даным", хоть дескриптор и создан!?!?!?Sleep(1000);
if(m_handle<0)
{
Alert("Ошибка при создании индикатора MA - номер ошибки: ",GetLastError()," ",m_strategy_symbol," ",m_period);
} else
{
// Аналитический процес
res = HistoryCheckTradeConditions();
}
AmountStartsFF++;
Colony[0][chromos]=res;
}
When using this function, error "2012.11.28 09:58:32 4194304 bytes not available", help me to understand, increased swap file to 10GBt.
Also, I am confused by Sleep(1000); help me understand.
A100: There is an inconsistency with type_filling: Only one mode is allowed while SendOrder places orders equally successfully as with
And after successful placement, the actual property of the placed order ORDER_TYPE_FILLING always = ORDER_FILLING_RETURN, even if request.type_filling = ORDER_FILLING_FOKwas specified in the request
I think there is a discrepancy between the list of allowed modes and the actual properties of the order after it has been placed
I've already tried to deal with similar issues here: https://www.mql5.com/ru/forum/2248/page5#comment_197730(two posts in a row). After that there were some changes in the help materials. But I became not interested in the question itself, so what exactly has changed - I can't say. Have another look at terminal's user manual. I think the description of these modes has been updated there too.
Thank you. I'll keep that in mind. Maybe someone can tell me when this column is filled in and when it is not (as in my case). If anything, I will ask at Service Desk.
1. Insert the code correctly.
2. how is the m_period parameter optimised/selected? I.e. what is its value during your optimization?
A vague question can only be answered in the same vague way - Graph periods
I am interested in your comments on the error: " 2012.11.28 09:38:18 4194304 bytes not available "
I am interested in your comments on the error: " 2012.11.28 09:38:18 4194304 bytes not available "
This is the identifier assigned to your order by the execution venue, the exchange.
Thank you all for your replies.
Found this uncertainty with type_filling: only one mode is allowed
at the same time SendOrder places orders equally successfully with as well as withrequest.type_filling = ORDER_FILLING_RETURN; //соответствующий флаг разрешения 0And after successful placement the actual property of the placed order ORDER_TYPE_FILLING always = ORDER_FILLING_RETURN even if we have specified request.type_filling = ORDER_FILLING_FOK in the query
Seems to me a mismatch between the list of allowed modes and the actual properties of the order after placement
tol64:
And please clarify what is meant by external trading system, in case I misunderstand it too.
You said that
You said that you havetol64:
Yes, I checked it carefully and nothing shows up in this field at the moment of order triggering.
So, was it checked during exchange trading or not?
Not enough memory.
Thank you.
Please help to analyse the situation, the following code:
When using this function, error "2012.11.28 09:58:32 4194304 bytes not available", help me to understand, increased swap file to 10GBt.
Also, I am confused by Sleep(1000); help me understand.
And after successful placement, the actual property of the placed order ORDER_TYPE_FILLING always = ORDER_FILLING_RETURN, even if request.type_filling = ORDER_FILLING_FOK was specified in the request
I think there is a discrepancy between the list of allowed modes and the actual properties of the order after it has been placed