Особенности языка mql5, тонкости и приёмы работы - страница 310

 
Andrey Khatimlianskii #:

получат ли они разные цифры?

Уверен, что, например, GetMicrosecondCount можно всегда использовать для получения гарантированных разных значений при любом разумном количестве параллельно работающих программ.

 
fxsaber #:

Уверен, что, например, GetMicrosecondCount можно всегда использовать для получения гарантированных разных значений при любом разумном количестве параллельно работающих программ.

Кажется, я натыкался на неуникальные значения. Наверное, при старте терминала или подключении к счету. Но точно не помню.

 
fxsaber #:

Я уверен, что, например, GetMicrosecondCount всегда можно использовать для получения гарантированно разных значений при любом разумном количестве параллельно работающих программ.

Осторожно, микросекунды начинаются с запуска программы. Миллисекунды начинаются с запуска компьютера.
 
Dominik Egert #:
Осторожно, микросекунды начинаются с запуска программы. Миллисекунды начинаются с запуска компьютера.

Вы можете попробовать поймать одинаковые значения в разных программах.

 
fxsaber #:

Вы можете попробовать поймать одни и те же значения в разных программах.

Это будет трудно сделать специально. Но если вы рассчитываете на то, что оно будет уникальным, то рано или поздно вы столкнетесь с тем, что одно и то же значение будет повторяться. Поскольку это будет "состояние гонки", отлаживать его станет очень сложно.

Лучшим подходом было бы использование алгоритма UUID для повышения уникальности.


 

В недалеком прошлом определение точек привязки изменилось.

Кто-нибудь может помочь мне расшифровать значение этой документации, пожалуйста:

https://www.mql5.com/ru/book/applications/objects/objects_anchor


Насколько я могу судить, она теперь гораздо более ограничена (и, как мне кажется, сильно ограничивает возможности), не определено четко, как использовать какой тип ENUM в каких ситуациях.

Сейчас есть два типа ENUMS, оригинальный и новый вариант. Но в примере кода они не используются. Как и в каком смысле эти два перечисления совместимы друг с другом?

EDIT:

Лично я нахожу это гораздо более запутанным и ограничивающим, чем требуется. - Как поставить "Stop-Arrow" по цене закрытия свечи? - Это уже невозможно. Это обычно считается регрессом в функциональности.

Также невозможно рассчитать правильное смещение, чтобы поместить стрелку в "центр", потому что нет возможности определить высоту. OBJPROP_WIDTH и OBJPROP_XSIZE оба дают NULL в качестве результата.

"Решение" состоит в том, чтобы использовать текстовую метку и поставить шрифт wingdings с правильным кодом символов для "эмуляции" стрелок, рисуемых типом ObjectArrow, но это не то решение, так как текстовые метки ведут себя немного иначе, чем стрелки, и вы не можете отличить стрелку от текстовой метки. - Чтобы добиться такого различия, необходимо скрыть некоторую информацию о флагах в альфа-значении цветовой информации, но это недокументировано и чревато изменениями в поведении.


EDIT2:

OBJ_TEXT поддерживает угол для поворота отображения текста на графике. - Но терминал не может правильно отобразить не-TTF-шрифты при применении угла к текстовому полю. Текст будет отображаться за пределами предполагаемого текстового поля.

MQL5 Book: Creating application programs / Graphical objects / Defining anchor point on the object
MQL5 Book: Creating application programs / Graphical objects / Defining anchor point on the object
  • www.mql5.com
Some types of objects allow you to select an anchor point. The types that fall into this category include text label (OBJ_TEXT) and bitmap image...
 
Dominik Egert #:

Это не ошибка как таковая, а задокументированное изменение дизайна. MetaQuotes разделила концепцию привязки на два разных перечисления:

  • ENUM_ANCHOR_POINT для текста или растровых объектов (более гибкое, с 9 возможными позициями).
  • ENUM_ARROW_ANCHOR для стрелок, где привязка ограничена TOP/BOTTOM или даже фиксирована в зависимости от типа стрелки (покупка/продажа/стоп и т.д.).

Поэтому сейчас она кажется более "ограниченной": стрелки предназначены не для пиксельного управления, а как быстрые графические маркеры.

Такие свойства, как OBJPROP_XSIZE или YSIZE, не поддерживаются в этих объектах, поэтому вы не можете рассчитать смещение для точного центрирования значка на ближней линии.

Если вам нужна точность, практичной альтернативой является использование OBJ_LABEL или OBJ_BITMAP_LABEL со шрифтом (например, Wingdings) или пользовательским растровым изображением. Там вы можете контролировать привязку и, в некоторых случаях, размер.

Итог: Да, это реальное ограничение, но оно намеренное и документировано MetaQuotes. Для них стрелки - это декоративные элементы с фиксированной логикой, а не свободно позиционируемые объекты.

 
Miguel Angel Vico Alba #:

Это не ошибка как таковая, а задокументированное изменение дизайна. MetaQuotes разделила концепцию привязки на два разных перечисления:

  • ENUM_ANCHOR_POINT для текста или растровых объектов (более гибкое, с 9 возможными позициями).
  • ENUM_ARROW_ANCHOR для стрелок, где привязка ограничена TOP/BOTTOM или даже фиксирована в зависимости от типа стрелки (покупка/продажа/стоп и т. д.).

Именно поэтому сейчас она кажется более "ограниченной": стрелки не предназначены для пиксельно точного управления, а являются быстрыми графическими маркерами.

Такие свойства, как OBJPROP_XSIZE или YSIZE, не поддерживаются в этих объектах, поэтому вы не можете рассчитать смещение, чтобы точно отцентрировать значок на закрытии.

Если вам нужна точность, практичной альтернативой является использование OBJ_LABEL или OBJ_BITMAP_LABEL со шрифтом (например, Wingdings) или пользовательским растровым изображением. Там вы можете контролировать привязку и, в некоторых случаях, размер.

Итог: Да, это реальное ограничение, но оно намеренное и документировано MetaQuotes. Для них стрелки - это декоративные элементы с фиксированной логикой, а не свободно позиционируемые объекты.


Я не согласен. Это регресс. Документация неполная, а поведение более или менее неопределенное из-за отсутствия надлежащей документации.

BTW, изменения такого рода всегда преднамеренны, это не исправляет регрессию.

Edit: Я не утверждал, что это ошибка.
 
Dominik Egert #:

Я не согласен. Это регресс. Документация неполная, а поведение более или менее неопределенное из-за отсутствия надлежащей документации.

BTW, изменения такого рода всегда преднамеренны, это не исправляет регрессию.

Так было много лет. Не увидел никаких изменений.

 
Artyom Trishkin #:

Так было уже много лет. Никаких изменений.

Она изменилась, мне лень выяснять, когда именно, но в 38xx была старая версия.


EDIT: Извините за утверждение, что она изменилась в версии 38xx, на самом деле она уже была такой и в версии до 2000 года. - Так что тогда я это уже пропустил.