Реter Konow / Профиль

Добавил тему AI 2023. Встречайте ChatGPT.

Добавил тему Искусственный интеллект 2020 - есть ли прогресс?

Добавил тему Представление объекта в программировании.

Временно удалил Виз.редактор. В начале месяца опубликую новую версию!

Добавил тему Краудсорсовый GUI. Открытое бета-тестирование.

Добавил тему Закат программирования?

Добавил тему Алгоритмическая ''центрифуга''

Добавил тему Вопрос знатокам ООП.

Опубликовал код Last 10 bars table

Если кому то нужна такая видео-инструкция к программе, могу реализовать в виде индикатора, который пользователь сам добавит на график. Обращайтесь, помогу. Бесплатно.

Единственная причина по которой еще не опубликовал обещанный стакан в кодо-базе, так это потому, что хочу сделать его приложением принципиально нового уровня. Уровня, ранее не досягаемого ни для одного программиста на MQL. Что это значит? В первую очередь, - API. Стакан будет самостоятельной программой-индикатором, которая будет предоставлять другой программе (советнику или индикатору) подключение с двусторонней взаимосвязью. Со стороны стакана можно будет получать события кнопок и данные, а со стороны клиента будут передаваться маркеры для цен в стакане. По мимо этого, стакан должен иметь как собственную иллюстрированную документацию, так и подробную документацию API. Все это требует от меня очень серьезного подхода. Нужно было расширить методику печатания на канвасе через конструктор с установкой свойств текста, текствых блоков, раскраской ключ.слов, ссылками для перехода между обзацами, сжатие больших картинок, создание гифов и многое другое. Нужно понимать, что каждая новая идея, даже воплощаемая удачно, приносит не только вдохновение и прогресс, но и проблемы, в виде больших переделок, исправлений и новых багов. Все это забирает время. Но в итоге, стакан получится приложением MQL такого уровня, какого еще не было. А потом, постепенно, все серьезные mql-приложения станут писать на таком уровне. API, документация, взаимодействие с пользователем через интерфейс, двусторонняя передача данных + отдельные платные функции... Так мне кажется...))

ЗЫ. Рекламные баннеры забыл добавить. Теперь это уже легко сделать.

Вот пример сжатия гифа. Здесь гиф состоит из 17 картинок размером 800х600 пикселей каждая. Мне удалось их так сжать, что 17 картинок занимают около 320 кб. То есть, ~80 000 ячеек int в массиве. Совсем немного для гифа таких размеров. Это означает, что и картинки я могу также. Конyhечно, они сжимаются компилятором при добавлении в программу через директиву #resource, но когда я создаю загрузочный файл для движка, мне необходимо выбрать из всех ресурсов конструктора только нужные для движка изображения, и следовательно, приходится брать их и сжимать самому. Иначе, в движке нужно каждый раз писать эту дерективу для каждой картинки или лейбла из конструктора, а это слишком утомительно.

Я разработал свои гифы. Повторяющиеся видео-фрагменты внутри MQL - программы. Они работают на канвасе моих окон и добавляю я их туда из КИБ-кода. Производство гифа происходит следующим образом:

Сначала подготавливаются картинки. Для короткого гифа нужно 8-10 картинок одного размера. Картинки редактируются в сторонней программе обработки фото или графическом редакторе. Далее, я сохраняю их в формате bmp в папке Images. Потом, запускаю специальный скрипт, который сжимает картинки по моему алгоритму и производит гиф. Гиф загружается ресурсом в программму и проигрывается на канвасе специальным алгоритмом. Все.)

Ниже показан один из гифов которые я добавил в документацию своего движка.

Должен сказать, что сжатие гифа достаточно мощное, и 10 картинок гифа в сумме занимают меньше места чем одна исходная картинка. Далее, приведу еще пример.

Да, так у меня бывает. Начал делать стакан цен и в итоге переделал массу вещей в конструкторе и движке, а стакан ещё не закончил.))

Однако, система генерации GUI упрощена на треть. Генератор ядра граф.интерфейса перестал быть необходим. Одна функция добавленная в конструктор заменила огромный блок, который из KIB-кода, с нуля создавал два ядра - графическое и параметров. Суть в том, что это мог делать конструктор, но он создаёт пользовательское ядро внутри своего ядра, а эффективно разделить их была большая проблема. Поэтому, я сделал отдельный генератор, собирающий сугубо пользовательское ядро из KIB-кода, которое и переноситься в движок. Теперь, пользовательское ядро можно извлекать прямо из ядра конструктора и обойтись без его генерации с первой ступени, - с киб-кода.

Это огромный шаг вперёд, к студии.

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

Окно документации стакана цен (создано на языке разметки KIB).

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

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

Таким образом, вместо трёх файлов, теперь будет распространяться только один, - движок, и он сам будет печатать файл своего API.