Приход нового поколения торговых программ. Каким должен стать интерфейс советников? - страница 12
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Как все запущено :)
Я говорил о примере создания интерфейса с помощью вашего индикатора файлового навигатора, реализованного в эксперте. Но не цепляйтесь за слова "файловый навигатор", это ж пример задачи, а подобных задач в экспертах может быть много: навигатор окон терминала, объектов на чарте, индикторов в терминале ... И это только небольшой пласт задач, реализуемых через список(таблицу) строк, которые вы хотите получить в свой индикатор через глобальные переменные.
1. Концепция графического движка.
2. Концепция графического ядра.
3. Этапы создания визуальной студии для платформы МТ.
4. Описание механизма создания интерфейса советника.
1. Графический движок представляет из себя программу выполненную в качестве индикатора. Данная программа создана исключительно для управления пользовательским интерфейсом. Выполняет набор базовых функций:
Графический движок добавляется на график также, как и любой другой индикатор. Он включает в себя следующий набор окон:
На этом, в принципе, понятие графического движка исчерпывается. Важно, что без него работа интерфейса невозможна.
2. Графическое ядро это блок информации, содержащий в себе данные всех объектов и окон интерфейса, записываемый в массиве и сохраняемый в файле.
Этот блок является цифровым отражением графического интерфейса. Загружается графическим движком по указанию пользователя. Сам графический движок имеет свое собственное, внутреннее граф. ядро которое обеспечивает работу его собственных окон, и внутри этого ядра отведено свободное место для интеграции в него пользовательского интерфейса (в цифровом виде). Интеграция осуществляется в процессе загрузки графического ядра из файла.
3. Создание визуальной студии на платформе МТ, в моем понимании делится на два этапа:
4. Я хочу изложить механизм процесса создания интефейса в общих чертах и немного приоткрыть завесу над его технологией. Пояснить, откуда появится легкость создания интерфейса через файл.
Дело в следующем: в движке имеется спец. функция, которая создает полноценное графическое ядро на основе одного файла, с минимальным количеством загрузочной информации. Загрузочная информация в этом файле имеет самопонятный и читабельный для человека вид. Ее легко писать и редактировать. Например, для создания окна досточно написать "_CREATE_NEW_WINDOW", а для создания чекбокса "_CHECKBOX" и имя этого чекбокса, (движок автоматически распознает имя элемента, как наименование самого элемента и как наименование его параметра).
Данная функция называется "G_CORE_BUILDER()" и она строит графическое ядро принимая данные из двух основных источников: из загрузочного файла создаваемого пользователем, и из массива "CONTENT[]", в котором записаны все стандартные группы объектов входящие в состав платформ окон и элементов управления. "CONTENT[]" содержит также состояния и сценарии объектов. Все в одном массиве. В общем, исходный материал из "CONTENT[]" + загрузочный файл создаваемый пользвателем используются функцией "G_CORE_BUILDER()" для построения графического ядра, с которым работает движок.
Во избежание путаницы, хочу добавить, что загрузочный файл может быть двух форматов:
1. В виде набора инструкций составленных пользователем, в которых описаны окна, элементы управления и свойства их параметров. В этом случае, на этапе загрузки запускается функция "G_CORE_BUILDER()" и строит графическое ядро.
2. В виде готового графического ядра, которое загружается напрямую в движок. В этом варианте нет необходимости в использовании функции "G_CORE_BUILDER()".
Первый вариант будет использоваться в конструкторе интерфейса, а второй для запуска уже готового интерфейса любого приложения.
Загружать готовое графическое ядро будет упрощенная версия движка, из которой будет удалена система построения ядра - ("G_CORE_BUILDER()" и массив "CONTENT[]") , с целью облегчения его работы.Нарисовать картинку - это еще не интерфейс, самый главный вопрос умалчиваете - как эксперт будет взаимодействовать с индикатором, через "глобальные переменные" как-то туманно звучит.
1. Напомню то, что известно всем, - каждая глобальная переменная находится в области видимости всех загруженных на график программ. Чтобы создать глоб. переменную, нужно вызвать спец. функцию, и передать в нее наименование переменной и ее значение.
2. Глобальные переменные будут создаваться движком на этапе загрузки интерфейса, который будет считывать загрузочный файл. В самом загрузочном файле будут записаны имена глоб. переменных и их сохраненные (или предустановленные) значения.
3. Внутри движка есть специальный блок, который отвечает за управление значениями параметров элементов управления в соответствии с типом элемента, типом его значения и свойствами параметра. Когда пользователь ставит галочку в чекбоксе или перемематывает значения в элементе "spin edit", то блок взаимодействия элемента управления с параметром осуществляет конкретные действия с конкретным значением, конкретной переменной.
4. Благодаря тому, что переменная глобальна, ее значение будет постоянно "наблюдатся" экспертом и он будет реагировать на изменение значения каждой из глоб. переменных в соответствии с заложенными в него алгоритмами.
5. С стороны эксперта, может осуществлятся не только "наблюдение" за глобальными переменными, но и полноценная работа с их значениями со стороны его функционала. Здесь важно понимать, что глоб. переменные будут условно делится на два типа: переменные "подконтрольные" пользователю, значения которых будут устанавливатся пользователем посредством элементов управления в интерфейсе, и переменные "подконтрольные" функционалу советника, значение которых будут определять пользовательские функции.
6. Движок, свою очередь, будет работать с обоими условными типами глоб. переменных. Принцип работы "блока взаимодействия элемента управления с параметром" со значениями переменных "подконтрольных" пользователю я описал, а принцип работы со значениями "подконтрольными" функционалу эксперта, будет заключаться в следующем: тот же блок условно делит элементы управления на две категории: те, что управляют значением, и те что выводят значения (отображают его любым способом). Каждый такой элемент (поле ввода, progress bar и т.д...) подписан на событие изменения значения своей переменной. Как только происходит изменение значения любой переменной, блок обращается к соответствующему элементу и осуществляет манипуляцию с этим элементом, которая предусмотрена в типе элемента по умолчанию.
Замечу, что блок делает цикл по всем глоб. переменным на частоте таймера, таким образом "следя" за поведением значений подконтрольных функционалу переменных.
//--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------P.S. По поводу вопроса о способе загрузки настроек советника из пользовательского интерфейса, то в моем представлении, это будет осуществлятся след. образом:
Значения всех глобальных переменных, с которыми работает советник (в том числе и тех, что представляют настройки советника), перед уничтожением на событии выгрузки эксперта, будут сохранятся в загрузочном файле. При каждой загрузке интерфейса, эти же самые глобальные переменные будут создаваться вновь и принимать свои прежнии значения. Далее, будет загружаться эксперт и обращатся к своим переменным.
Как передать текст (например, имя файла) через глобальную переменную?
Как эксперт сможет активировать/деактивировать окно?
Как эксперт сможет создать новое окно в процессе работы эксперта?
...
1. Как передать текст (например, имя файла) через глобальную переменную?
2. Как эксперт сможет активировать/деактивировать окно?
3. Как эксперт сможет создать новое окно в процессе работы эксперта?
...
1. Эта задача еще не решена. На вскидку могу предложить пару вариантов:
a) передача строки посредством имени самой глоб. переменной. Поскольку переменные индексируются, то нужно чтобы движок и эксперт всегда "знали" индекс той глоб. переменной, которая будет стираться и создаваться вновь для передачи текста, каждый раз меняя свое имя и передавая через него строку. На первый взгляд, вариант выглядит коряво, но кто знает, может его можно доработать...
б) Передавать строку через значение одной переменной, последовательно но буквам, где вместо самих букв будут передаваться соответствующие им номера, и процесс передачи будет осуществлятся в n-ное кол-во периодов таймера.
2. На текущий момент в моей концепции отсутствует метод активации/деактивации окон со стороны эксперта. Честно говоря, не совсем понимаю, что Вы имеете ввиду. С окнами будет иметь дело только пользователь и движок. Эксперт работает только с переменными и своими функциями. Доступа к интерфейсу у него пока нет. (Да и какой в этом смысл?)
3. Новые (композитные) окна по которым пользователь сможет группировать наборы (компонентных) окон по своему усмотрению, будет создавать движок а не эксперт, например при нажатии на пункт главного меню "новое окно". Важно, чтобы все группируемые окна были уже созданы в интерфейсе, а количество композитных окон используемых для группировки нужной пользователю информации, может быть (условно) неограничено. Наборы окон и их содержание будут сохранятся в файле.
Смысл основополагающий. События возникают не только в интерфейсе.
На пути вашего "титаника" будет еще не один айсберг. Вы начали проект не с того края и глобальные переменные здесь не помогут.
Смысл основополагающий. События возникают не только в интерфейсе.
На пути вашего "титаника" будет еще не один айсберг. Вы начали проект не с того края и глобальные переменные здесь не помогут.
Хорошо, а с какого краю я должен был начать проект по Вашему мнению, и что мне может помочь?
Думаю начинать надо от эксперта. Я привел три типа задач, которые актуальны для эксперта, но оказывается в вашем интерфейсе они не реализуемы.
А что может помочь? Возможно, более глубокая интеграция, или ограничение проекта до "пульта дистанционного управления".