
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Чуть перебрал
Я не могу понять этого
у меня получается что нужно делать так
Order.m_trade_elements; Order.m_trade_elements.magic=227; Order.m_trade_elements.type=OP_BUY;
Я думаю это не правильно, но как сделать по другому не пойму..
В общем вот мой финал, если есть предложения пишите и предлагйте
Конечно этот финал не идеал и часть кода было бы в другие классы засунуть, но пока так
Разве это не проверка на дробность лота ?
А откуда такая уверенность что всегда на всех ДЦ шаг лота будет меняться с кратностью 10???
Торговые элементы - это набор параметров, к-рые нужны для торговли. Можно, но конечно не обязательно, это дело оформить в виде структуры. Пример привёл выше.
Тогда свойства члена-данные m_trade_elements по умолчанию задаются при создании объекта, здесь CTrade. Как правило, это методы:
m_trade_elements - публичного доступа к нему нет. Поэтому перед совершением торговой операции можно воспользоваться уже готовой структурой типа STradeElements, либо создать set-метод доступа к m_trade_elements для изменения торговых элементов. Например так: CTrade::SetTradeElements(const STradeElements &_elements).
В методах класса CTrade() доступ к m_trade_elements получаем свободно. Как-то так:
Почему торговые элементы объединены в структуру? Да чтобы не плодить члены-данные класса CTrade и скомпоновать всё в какую-то совокупность...
Торговые элементы - это набор параметров, к-рые нужны для торговли. Можно, но конечно не обязательно, это дело оформить в виде структуры. Пример привёл выше.
Тогда свойства члена-данные m_trade_elements по умолчанию задаются при создании объекта, здесь CTrade. Как правило, это методы:
m_trade_elements - публичного доступа к нему нет. Поэтому перед совершением торговой операции можно воспользоваться уже готовой структурой типа STradeElements, либо создать set-метод доступа к m_trade_elements для изменения торговых элементов. Например так: CTrade::SetTradeElements(const STradeElements &_elements).
В методах класса CTrade() доступ к m_trade_elements получаем свободно. Как-то так:
Почему торговые элементы объединены в структуру? Да чтобы не плодить члены-данные класса CTrade и скомпоновать всё в какую-то совокупность...
Вот бы небольшой пример от Вас типа
struct st
{
double per;
}
class cl
{
st strut;
}
cl rez;
В общем вот мой финал, если есть предложения пишите и предлагйте
Конечно этот финал не идеал и часть кода было бы в другие классы засунуть, но пока так
Вольдемар, зер гут!
А если серьёзно, то посмотрите на код в той же самой Стандартной библиотеке. Увидите разницу :-)
Вольдемар, зер гут!
А если серьёзно, то посмотрите на код в той же самой Стандартной библиотеке. Увидите разницу :-)
В четверке нет...
А какая разница? Просто структура кода у Вас пёстрая какая-то...
Вот к примеру, взял из MQL5 сделал для MQL4:
Теперь этот шаблон можно развивать. И даже можно определить структуры MqlTradeRequest, MqlTradeResult и MqlTradeCheckResult для MQL4. Может быть не все поля будут такими как в MQL5, но начало будет положено.
К пример прототип OrderSend() в MQL4 такой:
Прикиньте, как эти параметры можно завернуть в структуру...
А откуда такая уверенность что всегда на всех ДЦ шаг лота будет меняться с кратностью 10???
Кратно настройке, пофиг на 10: