Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Кратко, про инженерию :
если есть позыв улучшить некое "А" методом повторной разработки, надо конкретизировать его критические недостатки. Просто их перечислить и объяснить почему это неустранимо в процессе эволюционного развития "А".
с другой стороны, никто-же не запрещает. Нравится писать код, пиши... Перепишешь "А", но по своему, зато оно будет новое
Макс, привет!
Ну я уже неоднократно описывал "недостатки", которые с моей точки зрения я вижу в стандартной библиотеке и в библиотеке Анатолия.
У обеих библиотек есть один существенный, на мой взгляд, недостаток: интерфейс строится на дискретных объектах чарта, То есть чем больше элементов управления в интерфейсе, тем больше обособленных объектов на самом графике. С одной стороны это вроде как само по себе не представляет проблемы, а с другой стороны это представляет проблему при перетаскивании диалогов, так как перетаскивается не единый объект "форма с элементами", а множество различных элементов. А на это расходуются дополнительные ресурсы.
Библиотека Анатолия очень шикарна, но она сложна по своему составу и сложна в интеграции в основную программу. А стандартная библиотека ограничена в самих элементах управления, хотя исходная архитектура очень даже хорошая на мой взгляд.
По сути лучшим решением было бы то, что пытается сделать Петр Конов: графический конструктор создания интерфейсов с генерацией кода GUI, но только с расширенной событийной моделью, чтобы при интеграции с основной программой не приходилось лазить в огромный код GUI (что-то вроде аналога MVVM), ну и конечно же с объектами, которые пользователи могли бы самостоятельно расширять.
Макс, привет!
Ну я уже неоднократно описывал "недостатки", которые с моей точки зрения я вижу в стандартной библиотеке и в библиотеке Анатолия.
У обеих библиотек есть один существенный, на мой взгляд, недостаток: интерфейс строится на дискретных объектах чарта, То есть чем больше элементов управления в интерфейсе, тем больше обособленных объектов на самом графике. С одной стороны это вроде как само по себе не представляет проблемы, а с другой стороны это представляет проблему при перетаскивании диалогов, так как перетаскивается не единый объект "форма с элементами", а множество различных элементов. А на это расходуются дополнительные ресурсы.
Библиотека Анатолия очень шикарна, но она сложна по своему составу и сложна в интеграции в основную программу. А стандартная библиотека ограничена в самих элементах управления, хотя исходная архитектура очень даже хорошая на мой взгляд.
По сути лучшим решением было бы то, что пытается сделать Петр Конов: графический конструктор создания интерфейсов с генерацией кода GUI, но только с расширенной событийной моделью, чтобы при интеграции с основной программой не приходилось лазить в огромный код GUI, ну и конечно же с объектами, которые пользователи могли бы самостоятельно расширять.
цитату правильно читать снизу-вверх. Внизу (то что подчёркнуто) более важное. Оно вообще определяющее
довольно удивительно, при всём современном развитии всех Human Interface, видеть что во главу ставятся представления координат и элементы форм.
При этом все спокойно пользуются броузерами c Rest/Ajax, в курсе что такое MVC но про интерфейс между советником и его GUI не задумываются.
если модель описана и есть протокол как с ней работать, то GUI может быть любой и не будет зависть от советника. Директивно вбивать окошки в советник, это какое-то злое-злое-зло. У советников основная задача это торговать, всё прочее должно быть вынесено из основного кода и быть опциональным.
цитату правильно читать снизу-вверх. Внизу (то что подчёркнуто) более важное. Оно вообще определяющее
довольно удивительно, при всём современном развитии всех Human Interface, видеть что во главу ставятся представления координат и элементы форм.
При этом все спокойно пользуются броузерами c Rest/Ajax, в курсе что такое MVC но про интерфейс между советником и его GUI не задумываются.
если модель описана и есть протокол как с ней работать, то GUI может быть любой и не будет зависть от советника. Директивно вбивать окошки в советник, это какое-то злое-злое-зло. У советников основная задача это торговать, всё прочее должно быть вынесено из основного кода и быть опциональным.
Полагаю что тут стоит исходить из того, что изначально разработчики не задумывались над тем, что может потребоваться функциональность интерфейсов. Если ты помнишь, то на ранних стадиях не было даже никакого ООП в mql, его основное предназначение скатывалось только к написанию индикаторов и все было под это заточено.
А сегодня мы наблюдаем что метаквоты уже работают и с сокетами и с базами данных, причем на уровне самого ядра программы... А механизмы взаимодействия между пользователем и программой так и остались в стороне.
При этом сами разработчики почти десять лет назад заявили что разработка интерфейсов является очень важным механизмом взаимодействия между пользователем и приложением и разработали под это дело стандартную библиотеку, но вот только ее применимость под задачи не показали и по сути даже на сегодняшний день очень многие программисты не знают о ее существовании.
Будем стараться устранять пробелы. Даже если это не потребуется другим участникам, определенный опыт все равно будет приобретен.
Начал именно с Вашей библиотеки, за что спасибо, потом немного причесал, потом еще, потом еще))) изменил в итоге все включая переписанных функций линий, также функцию широкой линии это из исходника канваса , убрал фейковые функции, поставил заглушку на эвент. еще не полностью ушел от структуры W хотя там тоже мало чего осталось. Добавил вычисление бара с лева и справа по бинарному поиску среди сторонних элементов, соответственно добавил сам бинарный поиск двухсторонний с возможность выбора большего или меньшего значения. Также добавил возможность построения от массивов любого вида (таймсерия/обычный ) И пришел к вывод что надо менять конструкцию))))))
Классно.
Да, библиотеки должны быть или универсальные для начинающих программеров, или узконаправленными уже для более продвинутых.
У самого несколько версий моего же iCanvas для разных целей.
Поэтому и заговорил о формулировки списка намерений и целей или хотябы обозначить направление. И поместить этот список в первое сообщение, пока оно доступно для редактирования.
Вобщем либо я что-то не так делаю либо шаблоны на объявление классов (пустых) не хочет работать. Что делает код не особо удобным
Думаю как изменить
Ребята, раз вы меня учили, дайте и я вас поучу.
Погоди судить - это даже не более чем основа основ. Да и то что я доделаю ГУИ мало вероятно - эт я еще в начале говорил. По поводу больших проектах - скажу так в Вашем коде строчек маловато чтобы тягаться с большими проектами.....
сейчас вопрос почему не работает такой фокус
...
сейчас вопрос почему не работает такой фокус