Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
И всё равно, даже если это сделано для расширения диапазона доступных магиков. Разве что-то бы поменялось если бы функция возвращала ulong, в справке так и было бы написано, а пользователи при желании могли бы загонять в структуру отрицательные значения long и при считывании значения магика делать преобразование к long? И работало бы так же, и в справке всё было корректно написано насчёт работы функций.
Хороший суппорт и мануал это отдельный редкий талант)
А вот это похоже как раз на ту потребность, которую удовлетворяли, принимая такое решение по поводу возвращаемого значения. По сути Вы описали рецепт, как сидеть на полутора стульях, располагая только одним стулом.))
Серьёзно. Если бы эти изящные решения (с расширением рабочего диапазона без расширения размера типа) находили отражение в справочнике, было бы куда лучше.
Имхо, ветка ни о чём. Считаю, что, в частности, даже диапазона интов хватит для эффективной работы с тикетами, а с магиками и подавно...
Ветка о расхождениях в справке, а не о том, хватает значений long для магиков или не хватает. Для уникальности магиков мне бы и uchar хватило. Я не собираюсь запускать одновременно 256 советников или даже больше.
Еще можно доколупаться до того, что функция называется "OrderGet Integer", а возвращает long.
Это можно) А ведь она ещё и datetime может вернуть внутри long'a. Её бы следовало назвать:
Но моя претензия имела больше оснований. Пользуясь не пользовательскими, а базовыми структурой и функцией языка и полностью соблюдая справку, я гарантированно получал ошибку выйдя за пределы long, а такая возможность есть при полном соблюдении справки.
Господа, вам уже 63 битного числа мало для magic?
Вот прям спать не можете от необходимости последнего 64 бита? При том, что у нас это работает и передается идеально.
Функции доступа универсальна и отдает сырое 64 битное число не взирая на знаки и без преобразований. Засунете в long - будет считаться знаковым, в ulong - беззнаковым.
Плодить дубли функций никто не будет. Все сделано чисто и осознанно, документация правиться не будет.
Господа, вам уже 63 битного числа мало для magic?
Вот прям спать не можете от необходимости последнего 64 бита? При том, что у нас это работает и передается идеально.
Функции доступа универсальна и отдает сырое 64 битное число не взирая на знаки. Засунете в long - будет считаться знаковым, в ulong - беззнаковым.
Плодить дубли функций никто не будет. Все сделано чисто и осознанно, документация правиться не будет.
Числа более чем достаточно. Просто хотелось бы согласовать в справочнике тип целых полей структуры MqlTradeRequest (ulong) и тип возвращаемого значения функций Order-/Position-GetInteger (long).
Господа, вам уже 63 битного числа мало для magic?
Вот прям спать не можете от необходимости последнего 64 бита? При том, что у нас это работает и передается идеально.
Функции доступа универсальна и отдает сырое 64 битное число не взирая на знаки. Засунете в long - будет считаться знаковым, в ulong - беззнаковым.
Числа более чем достаточно. Просто хотелось бы согласовать в справочнике тип целых полей структуры MqlTradeRequest (ulong) и тип возвращаемого значения функций Order-/Position-GetInteger (long).
Ответ был дан - нет. Мы знаем, что делаем.
Про идеальность мироустройства нужно в другом месте топить.