Мой подход. Ядро - Движок. - страница 170

 
jdjahfkahjf:
Вы еще не поняли что будущее трейдинга, и его пик, это кнопки.
И эти кнопки, Петр, будет продавать другим продавцам. Которые в свою очередь продают что? Угадали, тоже кнопки.
Но, для того что бы продавать кнопки продавцам кнопок, придется самому покупать кнопки у других создателей кнопок.

Угараю :)))

 
Dmitry Fedoseev:

Молодец, вы******* возьми с полки пирожок.   

Хорошо, попробую обосновать:

Если пойти по твоему решению, пользователю все равно придется копировать в проект исходный код статик-класса, который будет транслировать события, запускать форму в отдельном потоке ну и т.д. Кроме того, придется статически линковать форму к этому классу, т.е. в него явно вводить имя класса-формы и ее компонентов. Т.е. явно модифицировать твой код-прослойку, когда изменится форма или добавится какой-то элемент. Иными словами простое и прямое решение, хорошо будет работать для демонстрации взаимодействия с конкретной формой, что и было тобой показано. В обобщенном случае, лучше разделить логику управления и логику отображения, что и было мной сделано. Также такое разделение позволяет обезопасить контроллер от неквалифицированного изменения. 

Вот комментарий точно отвечающий на вопрос, почему было сделано именно так а не иначе: 

Igor Makanu:

наверное Вы правы, для пользователя проще набросать графических элементов в форму в VS2017, затем проверить путем запуска в VS свое творение, убедившись, что  "все крутится", он может переходить к созданию взаимодействия программы на .Net и МТ5

...

Ваш путь наверное более практичный.

 
Реter Konow:

Именно так. Будет огромная база Киб-кодов с картинками. Зашел, выбрал, получил код, вставил в конструктор, получил ядро с файлами подключения. И подключение уже все продумано и значительно проще.

Так и там каждая форма в отдельном файле. Даже если бы было проще, возможности ограничены.

 
Dmitry Fedoseev:

Так и там каждая форма в отдельном файле. Даже если бы было проще, возможности ограничены.

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

 
Реter Konow:

Василий, не в обиду, но такая панель:

у меня имеет примерно такой код:

Этот код можно просто передавать друг другу, или поместить в общую базу и не нужно специально каждому рисовать форму.

Вставил в конструктор и получил еще одно окно со всеми параметрами элементов и подключениями.

Петр, что бы нарисовать такую же панель у тебя, мне нужно изучить твой язык разметки. Что бы пользователю нарисовать эту панель в Visual Studio не нужно ничего, только мышка и базовые навыки. Чувствуешь разницу?

 
Реter Konow:

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

А я про ограниченность не про решение Василия писал.

 
Vasiliy Sokolov:

Петр, что бы нарисовать такую же панель у тебя, мне нужно изучить твой язык разметки. Что бы пользователю нарисовать эту панель в Visual Studio не нужно ничего, только мышка и базовые навыки. Чувствуешь разницу?

Василий, один изучает мой язык разметки и пишет панель. Тысяча других видят картинку панели и берут готовый киб-код. Вставляют в мой конструктор и получают эту панель у себя в программе.

 
Реter Konow:

Предварительно ознакомился, но буду и дальше перечитывать, чтобы вникнуть в детали.

1. Почему в статье говорится о 5-ти запросах в секунду? У меня частота 30 мс.

2. Можешь показать как выглядит связь с таблицей в тысячу ячеек?

3. Насколько я понял, обращение к элементам в форме по их именам, посылаемым в функцию   GuiController::SendEvent? Нужно указывать все параметры? Имя, событие, значение? Еще какие то нули... А в таймере делать цикл по событиям?

Иначе говоря, пользователь сам состовляет очередь событий, а потом в таймере ее передает в Контроллер?


Должен сказать тебе спасибо, за отличную рекламу моей темы. 

1) Без разницы. Частоту можно ставить любую.

2) Таблицы сейчас не поддерживаются (повод для твоего ликования кстати отличный:)

3) Да, обращение по именам, нужно указывать все параметры. Но, и это самое важное, какой-то одной монолитной событийной модели нет. Хочешь свою модель - пожалуйста. Сделать ее элементарно. Без таймера правда не обойтись.

Очередь событий обощенный алгоритм для надежной работы с событиями. Пользователь ничего не составляет, события генерируемые им сами попадают в очередь. Сама очередь 99.9% времени состоит только из одного события.

 
Vasiliy Sokolov:

Хорошо, попробую обосновать:

Если пойти по твоему решению, пользователю все равно придется копировать в проект исходный код статик-класса, который будет транслировать события, запускать форму в отдельном потоке ну и т.д. Кроме того, придется статически линковать форму к этому классу, т.е. в него явно вводить имя класса-формы и ее компонентов. Т.е. явно модифицировать твой код-прослойку, когда изменится форма или добавится какой-то элемент. Иными словами простое и прямое решение, хорошо будет работать для демонстрации взаимодействия с конкретной формой, что и было тобой показано. В обобщенном случае, лучше разделить логику управления и логику отображения, что и было мной сделано. Также такое разделение позволяет обезопасить контроллер от неквалифицированного изменения. 

Вот комментарий точно отвечающий на вопрос, почему было сделано именно так а не иначе: 

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

А вот то выделенное в цитате - что сено, что солома одно и тоже? Да! Что бы съесть банан, надо очистить кожуру. 

 
Реter Konow:

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

там нет ограничений возможностей, все ограничено ни больше и ни меньше функционалом графических элементов Windows, читайте статью с раздела " Под капотом у GuiController ", добавляете необходимые элементы управления в дизайнере форм и какие события считаете нужным  получать в МТ5 дописывайте в <элемент - список обработчиков событий>

Vasiliy Sokolov:

2) Таблицы сейчас не поддерживаются (повод для твоего ликования кстати отличный:)

тож обрадую Петра, я сделал работу таблицы в отдельной форме в .dll на .Net, события правой мыши, сортировка и прочие прелести dataGridView все работает, делал в части экспериментов таблицу как терминале, но довольно капризный и тормозной dataGridView , много что пробовал с ним делать ( и заполнял клон datatable и потом копировал в datatable который привязан к dataGridView  и ... и неделю гуглю и экспериментирую, пока с dataGridView полное фиаско - нельзя в него чаще 3-5 секунд писать)  таблица 10 х 11 уже критична, хоть форма с таблицей и работает в отдельном потоке

ЗЫ: на Делфи лет 5 назад за 2 часа прикрутил к МТ4 StringGrid, вообще не парился как там все работало, но все летало, с Майкрософтским dataGridView  беда однако, сегодня попробую со сторонним SourceGrid поэкспериментировать, по отзывам быстрее dataGridView