Любые вопросы новичков по MQL4 и MQL5, помощь и обсуждение по алгоритмам и кодам - страница 520
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Чем пагубна такая конструкция?
Или лучше привести datetime к типу long?
Но очевидна тяга к повышению точности (datetime мягко говоря больше time_t)
и скорее это long надо приводить для сравнения времён. Если компилятор чё-то оптимизирует, то он это выкинет, а задаток на будущее останется :-)
пока я не вижу проблем.
Но очевидна тяга к повышению точности (datetime мягко говоря больше time_t)
и скорее это long надо приводить для сравнения времён. Если компилятор чё-то оптимизирует, то он это выкинет, а задаток на будущее останется :-)
Значит можно использовать не изменяя без последствий?
Значит можно использовать не изменяя без последствий?
ну как это без последствий :-)
за long x = TimeCurrent(); уже "бьют по морде" в приличной компании :-) Мало того что типы по физике разные, так они ещё и разноразмерные и вы приводите большую размерность к меньшей.
а так то да, все секунды из (datetime)TimeCurrent вроде помещаются в long
есть замечательная функция StringFind() - ищите вхождение строки "#" или сразу "from #"
и что с ней делать?
В StringSubstr всё понятно, сразу получили цифры - тикет, а здесь в StringFind что, мы и так знаем что в комменте есть "to #"
Нашли
и что с ней делать?
В StringSubstr всё понятно, сразу получили цифры - тикет, а здесь в StringFind что, мы и так знаем что в комменте есть "to #"
но не знаем где :-) StringFind - скажет что искомый "to #" точно вот с такой позиции. или нету его вовсе. Никогда не полагайтесь на то что приходит из сети и вы лично/персонально не контролируете :-) Мы же тут в деньги играем - тут всё серьёзно
но не знаем где :-) StringFind - скажет что искомый "to #" точно вот с такой позиции. или нету его вовсе. Никогда не полагайтесь на то что приходит из сети и вы лично/персонально не контролируете :-) Мы же тут в деньги играем - тут всё серьёзно
нужно выделить тикет из комментария, а "to #" выкинуть.
нужно тикет открытой позиции сравнить с тикетом содержащемся в комментарии закрытой позиции
зачем мы его "to #" вообще ищем?
Функция StringSubstr возвращает нужную часть комментария. Почему эта функция возвращает профит открытой позиции а не закрытой? Перебираю же в MODE_HISTORY
Чем пагубна такая конструкция?
Или лучше привести datetime к типу long?
нужно выделить тикет из комментария, а "to #" выкинуть.
нужно тикет открытой позиции сравнить с тикетом содержащемся в комментарии закрытой позиции
зачем мы его "to #" вообще ищем?
Ищем для того, чтобы понять "а есть ли вообще to# или from#" в комментарии. Если нету, то этот ордер не является частью закрытой позиции, и он нам не нужен.
Если же StringFind(OrderComment(),"#to") больше, либо равен нулю, значит в комментарии есть искомая подстрока, и вот только теперь можно вычислить позицию номера тикета в этой строке.
Функция StringSubstr возвращает нужную часть комментария. Почему эта функция возвращает профит открытой позиции а не закрытой? Перебираю же в MODE_HISTORY
А это и есть ответ на этот вопрос
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Любые вопросы новичков по MQL4, помощь и обсуждение по алгоритмам и кодам
PolarSeaman, 2018.04.07 00:25
Нашлии что с ней делать?
В StringSubstr всё понятно, сразу получили цифры - тикет, а здесь в StringFind что, мы и так знаем что в комменте есть "to #"
А вот если нету, то получишь совсем не то что ожидалось.