tol64: Gracias. Lo tendré en cuenta. Quizá alguien pueda decirme cuándo se rellena esta columna y cuándo no (como en mi caso). En todo caso, preguntaré en el Servicio de Atención al Cliente.
Es el identificador asignado a su orden por la plataforma de ejecución, la bolsa.
Encontré esta incertidumbre con type_filling: sólo se permite un modo
string symbol = "EURUSD";
int flags = SymbolInfoInteger( symbol, SYMBOL_FILLING_MODE );
//разрешен только SYMBOL_FILLING_ALL_OR_NONE
al mismo tiempo que SendOrder realiza los pedidos con igual éxito con
MqlTradeRequest request;
request.type_filling = ORDER_FILLING_FOK; //соответствующий флаг разрешения 1
así como con
request.type_filling = ORDER_FILLING_RETURN; //соответствующий флаг разрешения 0
Y después de la colocación con éxito la propiedad real de la orden colocada ORDER_TYPE_FILLING siempre = ORDER_FILLING_RETURN incluso si hemos especificado request.type_filling = ORDER_FILLING_FOKen la consulta
MqlTradeResult result;
OrderSelect( result.order );
int tpAfter = OrderGetInteger( ORDER_TYPE_FILLING );
//tpAfter всегда = ORDER_FILLING_RETURN
Me parece que hay un desajuste entre la lista de modos permitidos y las propiedades reales del pedido después de la colocación
Por favor, ayude a analizar la situación, el siguiente código:
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;
}
Al utilizar esta función, error "2012.11.28 09:58:32 4194304 bytes no disponibles", ayúdame a entender, aumentó el archivo de intercambio a 10GBt.
Además, estoy confundido con Sleep(1000); ayúdame a entender.
A100: Hay una incoherencia con type_filling: sólo se permite un modo mientras que SendOrder coloca los pedidos con el mismo éxito que con stack y con
Y después de la colocación exitosa, la propiedad real de la orden colocada ORDER_TYPE_FILLING siempre = ORDER_FILLING_RETURN, incluso si request.type_filling = ORDER_FILLING_FOKse especificó en la solicitud
Creo que hay una discrepancia entre la lista de modos permitidos y las propiedades reales del pedido después de haberlo realizado
Aquí es donde ya intenté tratar temas similares: https://www.mql5.com/ru/forum/2248/page5#comment_197730(dos posts seguidos). Después hubo algunos cambios en los materiales de ayuda. Pero no me interesó la pregunta en sí, así que lo que ha cambiado exactamente, no lo puedo decir. Vuelve a mirar el manual de usuario del terminal. Creo que también se ha actualizado la descripción de estos modos.
Gracias. Lo tendré en cuenta. Quizá alguien pueda decirme cuándo se rellena esta columna y cuándo no (como en mi caso). En todo caso, preguntaré en el Servicio de Atención al Cliente.
1. Introduzca el código correctamente.
2. ¿cómo se optimiza/selecciona el parámetro m_period? Es decir, ¿cuál es su valor durante su optimización?
Una pregunta imprecisa sólo puede responderse de la misma manera imprecisa: periodos gráficos
Me interesan sus comentarios sobre el error: " 2012.11.28 09:38:18 4194304 bytes no disponibles "
Me interesan sus comentarios sobre el error: " 2012.11.28 09:38:18 4194304 bytes no disponibles "
Es el identificador asignado a su orden por la plataforma de ejecución, la bolsa.
Gracias a todos por sus respuestas.
Encontré esta incertidumbre con type_filling: sólo se permite un modo
al mismo tiempo que SendOrder realiza los pedidos con igual éxito con así como conrequest.type_filling = ORDER_FILLING_RETURN; //соответствующий флаг разрешения 0Y después de la colocación con éxito la propiedad real de la orden colocada ORDER_TYPE_FILLING siempre = ORDER_FILLING_RETURN incluso si hemos especificado request.type_filling = ORDER_FILLING_FOK en la consulta
Me parece que hay un desajuste entre la lista de modos permitidos y las propiedades reales del pedido después de la colocación
tol64:
Y por favor, aclare qué se entiende por sistema de comercio exterior, por si yo también lo he entendido mal.
Usted dijo que
Has dicho que tienestol64:
Sí, lo he comprobado detenidamente y no aparece nada en este campo en el momento de la activación del pedido.
Entonces, ¿se ha comprobado durante la negociación de la bolsa o no?
No hay suficiente memoria.
Gracias.
Por favor, ayude a analizar la situación, el siguiente código:
Al utilizar esta función, error "2012.11.28 09:58:32 4194304 bytes no disponibles", ayúdame a entender, aumentó el archivo de intercambio a 10GBt.
Además, estoy confundido con Sleep(1000); ayúdame a entender.
Y después de la colocación exitosa, la propiedad real de la orden colocada ORDER_TYPE_FILLING siempre = ORDER_FILLING_RETURN, incluso si request.type_filling = ORDER_FILLING_FOK se especificó en la solicitud
Creo que hay una discrepancia entre la lista de modos permitidos y las propiedades reales del pedido después de haberlo realizado