Мой подход. Ядро - Движок. - страница 140
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Да. Именно так. Вся информация необходимая для движка, чтобы он воспроизвел конкретный GUI и работал с ним. Сейчас я устанавливаю ее напрямую в движок, а потом сделаю загружаемой из файла, который печатает конструктор.
Как всё сложно и запутано.
Не проще ли будет пользователю вашего шайтан-кипятильника сделать так, чтобы он после построения пользователем требуемых форм, окон и элементов, просто выдавал mqh-файл для подключения к программе посредством #include? В файле уже прописаны OnChartEvent(), OnTimer(), OnTick() и прочие связующие элементы. Останется только прописать ему нужные действия, которые в любом случае ему нужно прописывать, но при этом ещё и учить ваш язык разметки. А так - ничего этого не нужно - прописал на mql то, что нужно в сгенерированном mqh-файле, и радуйся.
Вы же зачем-то пошли по пути создания языка разметки и подключения при помощи непонятного пользователю языка. Это решение не привлечёт к продукту пользователей mql-языка.
Походу, глядя на чудеса из этой ветке - больше всего умственных усилий человек склонен прилагать к тому, чтобы оставаться дураком.
но оно же перетрёт все пользовательские правки-привязки которые в эвентах ?
Как только меняется GUI, - пользователь нажимает кнопку и печатает новые файлы. Движок загружает новые ядра, а польз.приложение должно подключить обновленные файлы сопряжения.
При этом, один файл нужно просто заменить (Сonnection Properties), а второй - переподключить. Но, можно скопировать уже написанный код из прежнего файла.
Главное, не заполнять файлы подключения раньше, чем человек определится с GUI. Если добавляются новые окна, то это почти не затронет ничего. Если меняются прежние окна и элементы, то возможно придется и в программе переделывать код.
Это все в конструкторе. Пишется KIB-код и перекомпилируется файл.
Вот как работать с конструктором https://www.mql5.com/ru/blogs/post/717782
Поглядел... Глупые детские ошибки с именами файлов и папок, в редакторе тоже работаете как будто первый раз его открыли...
И что понял - так это же и не конструктор вовсе. Я-то думал, что у вас визуальный конструктор...
И вот эту вашу концепцию вы называете прорывом? Откуда и куда?
Как всё сложно и запутано.
Не проще ли будет пользователю вашего шайтан-кипятильника сделать так, чтобы он после построения пользователем требуемых форм, окон и элементов, просто выдавал mqh-файл для подключения к программе посредством #include? В файле уже прописаны OnChartEvent(), OnTimer(), OnTick() и прочие связующие элементы. Останется только прописать ему нужные действия, которые в любом случае ему нужно прописывать, но при этом ещё и учить ваш язык разметки. А так - ничего этого не нужно - прописал на mql то, что нужно в сгенерированном mqh-файле, и радуйся.
Вы же зачем-то пошли по пути создания языка разметки и подключения при помощи непонятного пользователю языка. Это решение не привлечёт к продукту пользователей mql-языка.
Кстати, да.
У меня вот именно таким путем иду при перекомпиляции. Правда, я не стал делать готовые MQH-файлы, пишу обычные текстовые, и потом из них переношу текст инициализационных процедур в основные модули, но идея - та же самая.
Петер, действительно - это весьма облегчит жизнь твоим пользователям, если вместо настроек, которые надо запоминать как использовать - генерировался бы готовый MQH-файл с готовыми установками настроек !
И вот эту вашу концепцию вы называете прорывом? Откуда и куда?
Артем, ты не прав. Это прорыв - от людей, которые хотят готовые советники с одной кнопкой "рубить бабло" (ну или, на худой конец с двумя кнопками, еще одна - "рубить огромное бабло") - к людям, которые будут торговать в полуавтоматическом режиме, открывая сделки, сопровождая их и закрывая при помощью визуальных компонент Петера !
Я убежден, что если такой народ появится - это реально будет прорыв.
У меня лишь сомнение, что такое возможно. Люди - по своей натуре ленивые, а уж для торговли руками (даже полуавтоматической) - нужен большой опыт, а откуда он у местного бомонда ?
Кстати, да.
У меня вот именно таким путем иду при перекомпиляции. Правда, я не стал делать готовые MQH-файлы, пишу обычные текстовые, и потом из них переношу текст инициализационных процедур в основные модули, но идея - та же самая.
Петер, действительно - это весьма облегчит жизнь твоим пользователям, если вместо настроек, которые надо запоминать как использовать - генерировался бы готовый MQH-файл с готовыми установками настроек !
Не понял, о каких настройках речь. Но, сделаю что смогу.
Поясните подробнее.
документации нет, поэтому ссылки по памяти (где-то от глубин треда) :-)
у вас генерируется файл с функцией с множеством вложенных switch который диспетчеризует сообщения от элемнтов интерфейса до "pressed" "released". Пользователь туда вбивает реакцию на события.
Поменяли-поредактировали интерфейс, что теперь с этим файлом ?
Какой объём работы например должен проделать пользователь чтобы вышеприведённую панель разделить на два окна - в одном кнопки, во втором таблица (чтобы можно было например закрыть и не маячила на экране).
И например нексолько колонок поменять местами. Это просто типично - сделали макет, попользовались, поменяли внешний вид на поудобнее
Не понял, о каких настройках речь. Но, сделаю что смогу.
Суть в том, что после построения всех форм, окон, визуальных элементов - создавался бы готовый MQL-файл, предназначенный для непосредственной компиляции.
Как я понимаю, сейчас пользователи должны сами вписывать все размеры, координаты, отступы... Это - весьма кропотливая и нудная работа. Было бы неплохо, если бы она была автоматизирована. Ее результатом - был бы MQH-файл, который готов к перекомпиляции.
Не понял, о каких настройках речь. Но, сделаю что смогу.
Учите ООП, и уже давно бы сделали, и не только то, что смогли бы, а гораздо больше - перед вами бы открылось огромное пространство для творчества, о котором вы сейчас даже не подозреваете. Быстро, качественно и профессионально.
А вы годами мутыжите свой постоянно раздуваемый моторчик.
Причём, если гордитесь количеством написанного кода, то вы "индус" в программировании. Это не обзывательство - просто поиском найдите сиё определение - оно точно подходит под то, чем вы занимаетесь.
Можно написать код в тысячу строк, и написать код в сотню, и оба будут делать одинаковый набор заложенных в них действий. Но изменить или дополнить раздутый код гораздо сложнее, чем нераздутый. Но вы предпочитаете бахвально заявлять о количестве написанных строк (тыча ими в нос Николаю), называя всё это огромным проектом. Как дитя ей-богу.