Реter Konow / 프로필

추가된 주제 새로운 세대의 거래 프로그램이 도래했습니다. 고문의 인터페이스는 무엇이어야 합니까?

추가된 주제 하이테크 속임수 CME. 상인 = 피해자?

추가된 주제 MT4 플랫폼의 Visual Studio.

추가된 주제 인공 지능 2020 - 진전이 있습니까?

추가된 주제 초보자를 위한 순진한 전략.

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

게재된 코드 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.

Вот с пояснениями:

Скоро в кодо-базе...