как создавать объекты динамически? (Некоторые вопросы ООП) - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
2. Framework from scratch.
Similar here. When I started to go a bit deeper into the standard libraries I found many things, which I did not like. Not only the bad performance of those, but also lack of flexibility and also because of an incomplete architecture. I am missing for example a global CMouse class/object as well as a class between CWnd and CObject, because CWnd objects are childs of the chart as well as lines are, and there is no connection to such and no final implementation of any such objects at all like I described it above. And, there is no master object, which holds all such chart objects which makes it possible to show/hide all of them with one command, destroy them, whatever. CCanvas, same thing, a nice class but where is the implementation with CWnd which allows me to create interactive objects based on bitmaps that inherit from CWnd? And so on.
Какова роль глобального CMouse? Служит ли он конечному пользователю только как отдельный класс, чтобы получить легкий доступ к управлению мышью? Как он связан с фреймворком?
Что касается класса между CWnd и CObject, я не понимаю, почему вы считаете их необходимыми. Объекты CWnd являются дочерними для графика, как и линии - я не понимаю, в чем проблема, и почему нет связи?
Вы также говорите, что нет окончательной реализации таких объектов, как вы описали выше? (где вы описали?)
Возможность глобального объекта мыши, по крайней мере в моем GUI, состоит в том, чтобы сохранить любую информацию о мыши (положение, положение нажатия, цена положения и т.д.), доступную для каждого класса, работающего с такой информацией. Кроме того, объект мыши хранит информацию об эксклюзивном использовании мыши, например, при перетаскивании. Это просто экономит много процессорного времени, пока что-то перетаскивается или собирается быть нажатым и т.д.
И последнее, но не менее важное: Ничто из стандартной библиотеки не работает в тестере стратегий при использовании в советниках, потому что нет событий мыши. И если вы хотите реализовать поддержку мыши в тестере стратегий, вы будете благодарны за такой класс мыши, потому что классу не важно, откуда берется информация о движении мыши, но объекты, которым нужна эта информация, все равно знают, где их искать.
---
Мне не хватает не только класса между CWnd и CObject, мне не хватает главного объекта/контейнера, который хранит объекты на основе пикселей, а также объекты на основе времени/цены. Как вы упомянули, все они являются объектами графика, поэтому логическим мастером должен быть объект, который представляет график и который содержит все объекты. И чтобы реализовать это, должен быть класс между CWnd и CObject.
В основе этой идеи лежит не только логика, но и вопрос производительности. В моем случае, когда график как-то меняется, мастер-объект обнаруживает это, он обходит все содержащиеся объекты, которые могут быть контейнерами линий, контейнерами CWnd, а также любыми отдельными объектами любого из этих типов, и "информирует" любой объект, который хочет быть проинформированным об этом. Это означает, что в коде есть один единственный цикл в одной точке, и благодаря использованию контейнеров и подконтейнеров это чрезвычайно эффективно.
Я также использую этот мастер для замораживания всех объектов сразу и предотвращения любых физических обновлений всего одной строкой кода. Разница в производительности радикальна. Пример: Когда я создаю все визуальные объекты, необходимые для моего эксперта, а в некоторых случаях их более 1000, я замораживаю этот мастер-объект заранее, создаю другие объекты и "размораживаю" его после этого, что приводит к одному физическому обновлению графика. Без замораживания этот процесс может занять целую минуту. С заморозкой он занимает менее 2 секунд.
Прежде чем я начал создавать GUI самостоятельно, я действительно попробовал его со стандартными библиотеками. Позже я попытался сохранить хотя бы некоторые части. Но проблема была в том, что просто невозможно было реализовать то, что я задумал, из-за неполной реализации и архитектуры, которая как бы ... LetsMakeSomethingThatWorksSomehowForWeDontKnow. Визуальная производительность достигается с помощью четкой иерархии, но стандартные библиотеки как-то анархичны.
В любом случае, я не первый, кто это понял. И, как уже упоминал Ален, я не уверен, что это действительно поможет, потому что это слишком теоретично. Я просто могу рассказать о своем опыте работы со всем этим, который основан не только на MQL, но мое мнение - это всего лишь мое мнение и, конечно, не закон.
Но для второго типа людей образ мышления и соображения, обсуждаемые здесь, очень ценны и очень практичны. Конечно, статья была бы лучше, но тем не менее.
Я не думаю, что люди будут строить фреймворки, прочитав только эту тему, но все же в ней есть хорошая информация и соображения, которых, кажется, не хватает даже тем, кто уже построил публичные MQL-фреймворки.
Итак, для мыши и тестера, если я правильно вас понял, вы используете ::OnTester() для вызова мыши вместо пользовательского ввода, если я вас понял.
Еще раз спасибо, Doerk.
Возможность глобального объекта мыши, по крайней мере в моем GUI, состоит в том, чтобы сохранить любую информацию о мыши (положение, положение нажатия, цена положения и т.д.), доступную для каждого класса, работающего с такой информацией. Кроме того, объект мыши хранит информацию об эксклюзивном использовании мыши, например, при перетаскивании. Это просто экономит много процессорного времени, пока что-то перетаскивается или собирается быть нажатым и т.д.
И последнее, но не менее важное: Ничто из стандартной библиотеки не работает в тестере стратегий при использовании в советниках, потому что нет событий мыши. И если вы хотите реализовать поддержку мыши в тестере стратегий, вы будете благодарны за такой класс мыши, потому что классу не важно, откуда берется информация о движении мыши, но объекты, которым нужна эта информация, все равно знают, где ее искать.
Или я что-то упускаю?
Объект мыши не смотрит сам, находится ли он над объектом или используется ли он в данный момент объектом, это делают сами объекты. Но объект мыши является центральным "местом", где может храниться такая информация.
Стандартные классы управления работают таким образом, что при каждом движении мыши все объекты зацикливаются, чтобы выяснить, имеет ли это движение какое-то отношение к ним, это занимает много процессорного времени, что можно легко увидеть, если запустить диспетчер задач и просто подвигать мышью, когда загружен советник или индикатор, и объект CDialog является частью советника или индикатора. Чем сложнее диалог, тем выше загрузка процессора.
В моем GUI, благодаря существованию глобального объекта мыши, это делается по-другому. У вас может быть 10000 объектов, а использование процессора при перемещении мыши не растет. Это сделано таким образом, что только как только кнопка мыши опустилась на определенный объект, этот один конкретный объект сообщает объекту мыши, что он имеет фокус, и как только мышь перемещается после этого события нажатия кнопки, никакому другому объекту не нужно заботиться об этом, и любое дальнейшее движение мыши / любое дальнейшее событие перемещения мыши направляется непосредственно на объект, который имеет фокус - который всегда эксклюзивный - с помощью его указателя.
И в силу того обстоятельства, что все объекты графика, независимо от того, основаны ли они на времени/цене (линии тренда и т.д.) или на пиксельных координатах (панели и т.д.), имеют общий базовый класс, все эти объекты могут использовать общий набор перегруженных функций для обработки этого. Это также причина, по которой я упомянул, что между CWnd и CObject отсутствует класс, потому что этот базовый класс между является тем же базовым классом, который используется объектами, основанными на времени/цене, и только это позволяет эффективно взаимодействовать и эффективно обрабатывать такие события.
Да.
Тем не менее, у меня есть возможность отлавливать любые движения, если нажать или нет, а также с лучшей производительностью процессора и без использования имен объектов, но здесь вопрос был не в этом.