Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Потому что надо вместо OrderOpenPrice поставить OrderOpenTime()
Точно. Перепутал. :)
Должен признать, что результаты теста меня немного удивили.
Вот именно поэтому я и хотел, чтобы ты сделал все сам, а не давать готовых решений, которые что о стенку горохом.
Я слышал об указателях на функции. Однако, у меня очень мало функций. Именно из за этого, нет пространства и необходимости применения ООП.
У меня иная концепция разработки. Я считаю, что работа целостных много-функциональных блоков эффективнее, чем больших комплексов маленьких функций.
Переспективнее, с точки зрения развития механизмов.
Такое у меня мнение...
Больших блоков у меня несколько. Чтобы применить ООП, их нужно разбить на маленькие функции, организовать в классы, а потом, использовать указатели и прочие вещи.
Но у меня не получится это сделать. Просто по тому, что я мыслю иначе.
Концепция ООП не совпадает с особенностями моего мышления, и я не могу в нем развернуться. В этом причина.
Заметь, Николай, что в вопросе программного развития, у меня нет проблем. Все развивается очень быстро.
При этом, механизмы работают нормально.
Сейчас я освоил юнионы, и вижу их применение в одной конкретной задаче, - запись строк в ресурс.
Я попробую проверить скорость и нагрузку на процессор в тестовом советнике и выложу результат.
Если он будет хорошим, перестрою связь между движом и советником, сделав ее на ресурсах.
Для того, чтобы использовать ресурсы для передачи строк неопределенной длинны, эти строки нужно записать в массив сhar.
Однако, похоже их размер объявляется только внутри юниона и потом не меняется.
Я попробывал изменить размер массива сhar из юниона, через ArrayResize, но эффекта нет.
Похоже, размер массива сhar должен быть установлен заранее. И он должен быть максимальным.
Вот код:
Теперь однозначно понятно, что размер массива char в юнионе, должен быть заранее известен. Потому что ArrayResize(u.Char, StrSize) не меняет его.
Значит, придется устанавливать размер массива равный длинне максимальной строки...
Хорошая новость. Все работает хорошо.
Строка записывается в ресурс и читается другим советником на другом графике.
Нагрузки на процессор нет. Нагрузку дает только вызов Алерта печатающего строку.
Вот код советников:
1. Советник формирующий строку и записывающий ее в ресурс.
Советник читающий строку из ресурса на другом графике:
Буду использовать ресурсы для связи. Единственный недостаток - нужно устанавливать максимальный размер массива char в юнионе. Зато, не нужно думать о размерах строки и количестве MT-объектов.
Этот метод более медленный, чем метод связи через MT-объекты, но вполне подходящий.
У вас интересная теория, хотя она не совсем соответствуем результатам моих опытов, которые я сейчас выложу ниже.
Как показала проверка, именно инициализация массива пикселей нагружает процессор больше всего.
Проверьте тестовый советник ниже.
Перечитал задачу:
Vasiliy Sokolov:
Петр, вот задание. Сделай панель, отображающую текущие открытие ордера в МТ4. Полную копию системной панели делать не надо, отобрази максимально простую таблицу с базовыми свойствами открытых ордеров: цена открытия, направление, профит. Остальное на твое усмотрение. Главное, что бы при закрытии ордера, его отображение в твоей таблице также исчезало. И наоборот, при открытии нового ордера, он появлялся бы в этой таблице.
Здесь видны две необходимых операции перерисовки при изменении таблицы на экране: 1. при закрытии сделки и 2. при открытии сделки. Зачем перерисовывать пикселы в остальное время?
Вы решаете какую-то другую задачу?
Перечитал задачу:
Vasiliy Sokolov:
Здесь видны две необходимых операции перерисовки при изменении таблицы на экране: 1. при закрытии сделки и 2. при открытии сделки. Зачем перерисовывать пикселы в остальное время?
Вы решаете какую-то другую задачу?
Так они перерисовываются именно так, как вы сказали.
А нагрузка на процессор возникает при анимации :
Здесь происходит постоянная переинициализация значений в массиве пикселей. Каждый 16 миллесекунд. Это нагружает процессор до 40%.
Я пытался понять, что именно нагружает. Думал, сохранение ресурса или его чтение. Оказалось, что именно переинициализация массива в цикле рисования.
Также оказалось, что постоянный вызов ObjectSetInteger(0,"MT object",OBJPROP_SELECTED,1); (Каждый 16 миллесекунд) тоже нагружает процессор. Примерно на 10%.
Этот вызов я использую для сообщения другому советнику, что ему нужно прочитать ресурс с данными анимации.
В сумме, получается +~50% нагрузки на процессор при анимации.