Галерея UI написанных на MQL - страница 41

Новый комментарий
 

1.



2.


3.



4.



5. 



6.



7.


DiscussionForumPosting - Schema.org Type
  • schema.org
Schema.org Type: DiscussionForumPosting - A posting to a discussion forum.
 

Окна настроек выше предназначены для тестирования подключения и реагирования на события интерфейса пользовательским функционалом.

Для этого откройте файл API и пропишите свои вызовы.

 По умолчанию, события интерфейса вызывают функцию Alert() печатающую их идентификатор и значение параметра на событиях воздействия на элементы. 

 
Я протестирую новую версию позже.
 

Перечень исправлений и обновлений в этом и следующем релизе:

Глобальные перемены:

  • Файл Internal_API был переименован в просто АРI. 
  • Из файла API были удалены все дефайны и функции которые не имеют отношение к работе пользователя с элементами управления. Частично они были перенесены в файл UIDATA.
  • Принципиально изменен метод связи пользовательского кода с элементами управления. Пользователь получит прямой доступ к ядру G_CORE в котором хранятся элементы управления. Доступ реализован через функции обертки которые печатаются автоматически в файле UIDATA.
  • В названия функций-оберток добавлен специальный префикс для легкости нахождения элементов через интеллисенс. 
  • Открыта возможность создания контекстного меню для пользовательского приложения. Выделена специальная область в файле #include<(2) KIB PROJECTS\(1) Must be included\User section\My menu section.mqh>
  • Добавлена возможность устанавливать кнопки в правую часть пользовательского таскбара. Для этого подготовлена специальная область в файле   #include<(2) KIB PROJECTS\ (1) Must be included\User section\ \My Taskbar section.mqh>
  • Пользовательское контекстное меню и таскбар теперь вызываются из контекстного меню конструктора и не мешают редактировать другие окна:


  • Пользовательское контекстное меню может вызывать младшие окна меню. 
        Так это выглядит после сохранения проекта и перехода в режим польз.приложения на другом графике:


  • Поведение окон контекстного меню аналогично их поведению в среде виндоус приложения. 

  • Опции контекстного меню могут вызывать функции или окна. Если пункт меню вызывает окно, значек окна автоматически устанавливается слева.



  • Локальные изменения и улучшения:

  • Исправлена проблема с прыгающим таскбаром при переключении графиков. Теперь он лучше и быстрее адаптируется к изменению размеров окна.
  • Налажена работа слайдеров: 
  • Табло со значением (S_WIDGET) всегда вмещает цифры значения и принимает размер в зависимости от размера текста максимального (или минимального) значения. 
  • Табло позиционируется с одной из 4-ех сторон по желанию пользователя (задается флагами).
  • Слайдер переключает любые значения в любом диапазоне с любым количеством знаков после запятой, и черерз любой заданный шаг.
  • Количество знаков после запятой (точность значения) задается пользователем (к.слово DIGITS).
  • Размер слайдера и диапазон значений роли не играют. Алгоритм рассчитывает движение ползунка через диапазон таким образом, что у одного конца всегда будет минимум, а у второго максимум.
  • При нажатии на колею слайдера ползунок автоматически прыгает на место нажатия и продолжает движение синхронно с пользователем если нажата кнопка мышки.
  • Планируется добавить возможность прокрутки ползунка через колею слайдера колесиком мышки.

    


  • Исправлены проблемы с выпадающим списком. 

  • При нажатии на кнопку открытия список больше не прыгает.
  • Исправлена проблема исчезания списка при прокрутки в самый низ.
  • Список можно прокручивать колесиком даже если курсор на полосе прокрутки или на кнопках.
  • Ускорена прокрутка списка колесиком мышки.


  • Решена проблема ложного нажатия:

  1. Ранее при нажатии на кнопку или другой похожий элемент происходила смена состояний даже если отжатие случалось вне пространства элемента. Данная проблема решена. Если пользователь нажал на элемент но передумал и отвел курсор, или перевел его на другой элемент или свободное пространство графика, то элемент первого нажатия всегда вернется к прежнему состоянию. Как будто ничего не произошло. Событие будет отменено и изменения значения параметра не последует. Фиксация ложного нажатия дает возможность отменить нажатие в последний момент просто переведя курсор (с еще нажатой кнопкой мышки) на другое пространство.


  • Было принято решение сосредоточится на создании шаблонов профессиональных виндоус-подобных окон настроек для упрощения их создания пользователям. Хорошим примером таких окон являются вошедшие в сборку окна Settings example 1  и  Settings example 2 (вызываемые из контекстного меню и польз.таскбара):

    


  • Довлена возможность блокирующих сообщений.

    Пример:

Сначала откройте разные окна настроек. Их кнопки внизу таскбара. Затем зайдите в контекстное меню (дабл-клик на график) и откройте окно "Sorry, this order is blocked". Оно находится здесь:


Затем попробуйте кликнуть на любое ранее открытое окно при открытом окне  "Sorry, this order is blocked". Любые действия с другими окнами будут заблокированы до закрытия этого окна. Однако можно ограничить список блокируемых окон в свойствах окна в киб-коде. Тогда какие то окна будут блокироваться, а какие то нет. В зависимости от решения пользователя.


  • Теперь диалоговые окна могут отрываться со звуком. Задается через KIB код в свойствах окна.
  • У диалоговых окон существует особый приоритет перед другими окнами и они всегда рисуются поверх окон настроек. 
  • Кнопки диалоговых окон (Ок, Cancel, Confirm, Close) работают и закрывают свои окна при нажатии автоматически.


  • У диалоговых окон может быть отключена возможность минимизации. В этом случае они не могут оказаться на таскбаре.


  • Название окна может распологаться слева или в центре. Устанавливается флагом в свойствах окна (киб-код).
  • Диалоговые окна смогут вызываться программно из приложения пользователя.
  • Диалоговые окна могут закрыватся автоматически при нажатии на другое окно или график. Возможность задает пользователь в свойствах окна в киб-коде. 


 

Добавлено:

Теперь окна меню всегда остаются внутри пространства графика и не уходят за пределы видимости. Пример:

НЕ ВЫХОДЯТ ЗА ПРАВУЮ ГРАНИЦУ ГРАФИКА:


НЕ ВЫХОДЯТ ЗА НИЖНЮЮ ГРАНИЦУ ГРАФИКА:


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

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

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

И так, как я это представляю:

1. Программное управление элементами интерфейса. 

Одна из главных задач на текущий момент. Сейчас юзер может только "ловить" события GUI в файле API, но не получать/менять свойства элементов или значения параметров. Взвешивая сложность, могу сказать что задача легкая и будет решена до следующего релиза. Предоставлю пользователю программный доступ к широкому набору свойств элементов и окон графического интерфейса. 


2. Обычные и динамические таблицы. 

Обычные таблицы уже реализованы. Их работа неоднократно тестировалась. Работали такие возможности как перетаскивание колонок и рядов (смена их места в таблице), сворачивание/разворачивание рядов таблицы (добавление элемента T_FOLDER) или скрытие/явление колонок. Работала автоматическая интеграция элементов управления в таблицу. Например чекбоксы, выпадающие списки, кнопки, слайдеры, поля ввода с кнопками и простые поля ввода - все сами встраивались в таблицу при ключевом слове IS_TABLE в заголовке группы. Значения в ячейках могли раскрашиваться в цвета в зависимости от величины. Таблицы даже могли встраиваться в древовидные списки.

Однако, стоит ли тратить время на возвращение всех прежних возможностей?

Сложно сказать. 

Думаю, в первую очередь нужно вернуть базовые возможности обычных таблиц и убедится что они хорошо работают. Остальное как получится.

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

Вывод:  динамичные таблицы - приоритетная задача.

(Нужно приступить к разработке.)


3. Древовидные списки.

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

Вывод:  древовидный список не является приоритетом дальнейшей разработки.

(Будет время - доделаю.)


4. Динамичные окна.

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

Вывод: завершение динамичных окон приоритетная задача.

(Может занять пару-тройку дней упорной работы с энтузиазмом.) 


5. Сворачиватели групп и таблиц.

Элементы G_FOLDER  и T_FOLDER.  Уже очень хорошо работали в прошлом. Как они работают сейчас не знаю, т.к. не было времени на тестирование. Интересно, что в последней разработке функции явления элементов добился унификации управления древовидным списком и этими двумя типами сворачивателей. Одна функция управляла работой трех элементов и при этом была не более 400 - 500 строк в размере (что не много по моим меркам). Если верну работу этой функции (сейчас она отключена), то все три элемента заработают идеально. Посмотрим. 

Вывод: элементы G_FOLDER  и T_FOLDER не в приоритете.

(Будет возможность и желание - сделаю).



Ну и последняя сейчас пришедшая на ум приоритетная задача:

6. Создание ветки шаблонов групп элементов и окон написанных на языке разметки. 

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


Если у кого то есть мысли по  приоритетам дальнейшей разработки, делитесь. Приму к сведению.

 

Да, программное управление - самое важное, нужно всем, кто будет пользоваться движком.

Для меня обязательное - динамические таблицы. Мне интерфейс нужен в основном для визуализации событий и отчётов в реальном времени. Элементы управления - это обвязка для управления ими (фильтры и пр.) С реализацией этого я бы смог начать интегрировать движок.

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

Третий приоритет - графики. Не знаю, насколько сложно. Возможно, надо использовать стандартные средства для канваса, если они достаточно гибкие. Я никогда не пробовал кроме Fast And Furious Easy And Fast v1.

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

 
Edgar Akhmadeev #:

Да, программное управление - самое важное, нужно всем, кто будет пользоваться движком.

Для меня обязательное - динамические таблицы. Мне интерфейс нужен в основном для визуализации событий и отчётов в реальном времени. Элементы управления - это обвязка для управления ими (фильтры и пр.) С реализацией этого я бы смог начать интегрировать движок.

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

Третий приоритет - графики. Не знаю, насколько сложно. Возможно, надо использовать стандартные средства для канваса, если они достаточно гибкие. Я никогда не пробовал кроме Fast And Furious Easy And Fast v1.

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

1. Программное управление элементами будет уже в следующем релизе. Ориентировочно через 7 - 10 дней. 

2. Динамические таблицы "поступили в разработку". Сколько займут времени сказать пока не могу. Процесс может быть очень быстрым... или не очень. Неизвестно.

3. Полноэкранное окно у Вас уже есть. Попробуйте его. В свойствах окна пропишите "DINAMIC" вместо "SETTINGS". Протестируйте и напишите о впечатлениях. (Только перейдите на поледнюю релизную версию конструктора). Можете менять размеры потянув за края окна или масштабировать верхней кнопкой. Есть вариант с дабл-кликом на верхнюю полосу (где название окна), или просто ухватите окно за "шапку" и тащите вверх пока оно само не масштабируется. В обратую сторону работают те же манипуляции.

4. Напечатайте файл API своего окна и выложите сюда. Посмотрю и пойму как печатаются там таблицы. Это важно для реализации будущего программного подключения.


5. Над пользовательскими чартами серьезно подумаю. Реализацию Анатолия видел, но не пробовал повторить этот элемент.

 

Важный нюанс при работе с динамичным окном:

Окно не принимает элементы типа V_BOX, потому что они содержат собственный канвас. Получается наложение одного канваса на другой. Поэтому этот элемент нужно закоментировать вместе со всеми строками i, IN, "V1", .

То есть группы которые помещены в элемент  V_BOX, должны быть просто в окне на "MF". Не нужно специально прописывать строку  i, IN, "V1".

Если не получится, завтра покажу более подробно. В картинках.

1...343536373839404142434445464748...64
Новый комментарий