Мой подход. Ядро - Движок. - страница 165
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Наверно да. Но если ГУИ, то это еще один файл, а это невозможно в маркете.
Может быть . Не знаю. Но, думаю, этот вопрос решаем, если у Петра что-то ценное получиться.
Ты все понял правильно, Николай. Советник работает и без движка. Движок создает GUI советника, как только закидывается на отдельный график и получает от него комманду. Движок может переключаться между разными советниками. При переключении, он просто перезагружает другое ядро из текстового файла. Его можно вообще не убирать, а выделить отдельный график и всегда его там держать.
по существующим правилам нельзя распространять через маркет продукты имеющие дополнительные зависимости. Более того, подозреваю что подобное юридически запрещено или довольно затруднительно .
Нельзя использовать внешние библиотеки ex*, включая и те, что не содержат вызовов к dll. Однако к индикаторам, коим и является движок Петра, это ограничение не относится.
Нельзя использовать внешние библиотеки ex*, включая и те, что не содержат вызовов к dll. Однако к индикаторам, коим и является движок Петра, это ограничение не относится.
я кода-то этот вопрос специально выяснял, расспрашивая сервис-деск маркета. Ответ был вполне однозначный, хотя тогда и не порадовал :-) продукт маркета должен быть вещь-в-себе и не требовать установки никаких других компонент. Все необходимые индикаторы и библиотеки должны быть упихнуты внутрь через Ресурсы.
что кстати логично - человек купил продукт и этот продукт (и все его заявленные свойства) должны быть сразу-же доступны без лишних телодвижений.
И не было ситуации когда какая-то зависимость обновилась, а отвалился советник :-)
А вообще, трейдинг это:
мой доход - "ядро - движок"
;)Есть мысль избавить пользователя от необходимости таскать везде файл с ядром, чтобы движок мог его закачать. При производстве GUI, конструктор производит файл с ядром. Вместо сохранения в файле, конструктор может сохранять ядро в ресурс, а в файле Сonnection Properties прописать строку подключения этого ресурса. Когда пользователь подключит созданный файл Сonnection Properties, то при инициализации своего советника, этот ресурс с ядром окажется интегрированным. Далее, при подключении к движку, последний просто прочтет ресурс с ядром из советника и воспроизведет GUI. Таким образом, таскать файлы с ядром не нужно будет.
Во, блин, а я то думал, что у тебя так и реализовано. Конечно, какой смысл таскать с собой файлы настроек.
А подробнее можешь рассказать? Как, что и зачем.
...
Николай, если ты предлагаешь открытыть код движка для всех, чтобы каждый его помещал в советник, то я думал над этим. Увы, это установит лимит развития движка. Все будет происходить в потоке одного приложения, что ограничит используемые ресурсы и большая часть преимуществ которые можно достичь распараллеливанием вычислений, будет утерена. К тому же, пользователи начнут вносить свои поправки в движок и распостронять модифицированные версии, что породит хаос и новые проблемы развития.
Поэтому, идея в теории хороша, а на практике увы...(
Николай, если ты предлагаешь открытыть код движка для всех, чтобы каждый его помещал в советник, то я думал над этим. Увы, это установит лимит развития движка. Все будет происходить в потоке одного приложения, что ограничит используемые ресурсы и большая часть преимуществ которые можно достичь распараллеливанием вычислений, будет утерена. К тому же, пользователи начнут вносить свои поправки в движок и распостронять модифицированные версии, что породит хаос и новые проблемы развития.
Поэтому, идея в теории хороша, а на практике увы...(