Мой подход. Ядро - Движок. - страница 170
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Угараю :)))
Молодец, вы******* возьми с полки пирожок.
Хорошо, попробую обосновать:
Если пойти по твоему решению, пользователю все равно придется копировать в проект исходный код статик-класса, который будет транслировать события, запускать форму в отдельном потоке ну и т.д. Кроме того, придется статически линковать форму к этому классу, т.е. в него явно вводить имя класса-формы и ее компонентов. Т.е. явно модифицировать твой код-прослойку, когда изменится форма или добавится какой-то элемент. Иными словами простое и прямое решение, хорошо будет работать для демонстрации взаимодействия с конкретной формой, что и было тобой показано. В обобщенном случае, лучше разделить логику управления и логику отображения, что и было мной сделано. Также такое разделение позволяет обезопасить контроллер от неквалифицированного изменения.
Вот комментарий точно отвечающий на вопрос, почему было сделано именно так а не иначе:
наверное Вы правы, для пользователя проще набросать графических элементов в форму в VS2017, затем проверить путем запуска в VS свое творение, убедившись, что "все крутится", он может переходить к созданию взаимодействия программы на .Net и МТ5
...
Ваш путь наверное более практичный.
Именно так. Будет огромная база Киб-кодов с картинками. Зашел, выбрал, получил код, вставил в конструктор, получил ядро с файлами подключения. И подключение уже все продумано и значительно проще.
Так и там каждая форма в отдельном файле. Даже если бы было проще, возможности ограничены.
Так и там каждая форма в отдельном файле. Даже если бы было проще, возможности ограничены.
Честно говоря, я еще не до конца вник в технологию, потому об ограниченности возможностей решения Василия еще ничего сказать не могу.
Василий, не в обиду, но такая панель:
у меня имеет примерно такой код:
Этот код можно просто передавать друг другу, или поместить в общую базу и не нужно специально каждому рисовать форму.
Вставил в конструктор и получил еще одно окно со всеми параметрами элементов и подключениями.
Петр, что бы нарисовать такую же панель у тебя, мне нужно изучить твой язык разметки. Что бы пользователю нарисовать эту панель в Visual Studio не нужно ничего, только мышка и базовые навыки. Чувствуешь разницу?
Честно говоря, я еще не до конца вник в технологию, потому об ограниченности возможностей решения Василия еще ничего сказать не могу.
А я про ограниченность не про решение Василия писал.
Петр, что бы нарисовать такую же панель у тебя, мне нужно изучить твой язык разметки. Что бы пользователю нарисовать эту панель в Visual Studio не нужно ничего, только мышка и базовые навыки. Чувствуешь разницу?
Василий, один изучает мой язык разметки и пишет панель. Тысяча других видят картинку панели и берут готовый киб-код. Вставляют в мой конструктор и получают эту панель у себя в программе.
Предварительно ознакомился, но буду и дальше перечитывать, чтобы вникнуть в детали.
1. Почему в статье говорится о 5-ти запросах в секунду? У меня частота 30 мс.
2. Можешь показать как выглядит связь с таблицей в тысячу ячеек?
3. Насколько я понял, обращение к элементам в форме по их именам, посылаемым в функцию GuiController::SendEvent? Нужно указывать все параметры? Имя, событие, значение? Еще какие то нули... А в таймере делать цикл по событиям?
Иначе говоря, пользователь сам состовляет очередь событий, а потом в таймере ее передает в Контроллер?
Должен сказать тебе спасибо, за отличную рекламу моей темы.
1) Без разницы. Частоту можно ставить любую.
2) Таблицы сейчас не поддерживаются (повод для твоего ликования кстати отличный:)
3) Да, обращение по именам, нужно указывать все параметры. Но, и это самое важное, какой-то одной монолитной событийной модели нет. Хочешь свою модель - пожалуйста. Сделать ее элементарно. Без таймера правда не обойтись.
Очередь событий обощенный алгоритм для надежной работы с событиями. Пользователь ничего не составляет, события генерируемые им сами попадают в очередь. Сама очередь 99.9% времени состоит только из одного события.
Хорошо, попробую обосновать:
Если пойти по твоему решению, пользователю все равно придется копировать в проект исходный код статик-класса, который будет транслировать события, запускать форму в отдельном потоке ну и т.д. Кроме того, придется статически линковать форму к этому классу, т.е. в него явно вводить имя класса-формы и ее компонентов. Т.е. явно модифицировать твой код-прослойку, когда изменится форма или добавится какой-то элемент. Иными словами простое и прямое решение, хорошо будет работать для демонстрации взаимодействия с конкретной формой, что и было тобой показано. В обобщенном случае, лучше разделить логику управления и логику отображения, что и было мной сделано. Также такое разделение позволяет обезопасить контроллер от неквалифицированного изменения.
Вот комментарий точно отвечающий на вопрос, почему было сделано именно так а не иначе:
Самая большая заморочка - запуск формы в отдельном потоке, но она решается двумя строками кода, то есть в итоге проблемой не является. К тому же в моем примере специально сделано открытие второй формы, что бы показать как легко и просто это делать, и как можно открывать в отдельных потоках любое количество форм.
А вот то выделенное в цитате - что сено, что солома одно и тоже? Да! Что бы съесть банан, надо очистить кожуру.
Честно говоря, я еще не до конца вник в технологию, потому об ограниченности возможностей решения Василия еще ничего сказать не могу.
там нет ограничений возможностей, все ограничено ни больше и ни меньше функционалом графических элементов Windows, читайте статью с раздела " Под капотом у GuiController ", добавляете необходимые элементы управления в дизайнере форм и какие события считаете нужным получать в МТ5 дописывайте в <элемент - список обработчиков событий>
2) Таблицы сейчас не поддерживаются (повод для твоего ликования кстати отличный:)
тож обрадую Петра, я сделал работу таблицы в отдельной форме в .dll на .Net, события правой мыши, сортировка и прочие прелести dataGridView все работает, делал в части экспериментов таблицу как терминале, но довольно капризный и тормозной dataGridView , много что пробовал с ним делать ( и заполнял клон datatable и потом копировал в datatable который привязан к dataGridView и ... и неделю гуглю и экспериментирую, пока с dataGridView полное фиаско - нельзя в него чаще 3-5 секунд писать) таблица 10 х 11 уже критична, хоть форма с таблицей и работает в отдельном потоке
ЗЫ: на Делфи лет 5 назад за 2 часа прикрутил к МТ4 StringGrid, вообще не парился как там все работало, но все летало, с Майкрософтским dataGridView беда однако, сегодня попробую со сторонним SourceGrid поэкспериментировать, по отзывам быстрее dataGridView