Новая версия платформы MetaTrader 5 build 1640: создание и тестирование собственных финансовых инструментов - страница 43
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Сейчас разработчики делают акцент на возможности создания серьезных проектов, т.е. сразу показывают те "фичи", о которых знают единицы: файлы тестера, ресурсы и т.п. Все эти фичи позволяют полнее раскрыть потенциал языка.
90% обновления - shared projects, а не GUI ME. И фичи, которые существуют годами, но которые никто почти не использует, никак не влияют на решение писать что-либо сообща.
90% обновления - shared projects, а не GUI ME.
Не представляю массовым явление MQL-Маркет-программ, которые бы были написаны более, чем одним человеком. MQL-проги - это что-то особенное. Совсем не C++.
ЗЫ Единственное, что вижу возможным, это написание сообща мат. программ под Облако. Например, майнеров. Это даже не написание, а некоторое адаптирование под MQL. Но сомнительно, что Облако сейчас является мотиватором для подобного.
90% обновления - shared projects, а не GUI ME.
Ранее в папке Project можно было использовать древовидную структуру папок для хранения проектов.
Теперь структура хранения в папке SharedProject претендующая на "большие групповые проекты" имеет один уровень вложенности
- группировочные подпапки в SharedProject создавать нельзя, а возможно только внутри проекта.
То есть при работе уже с несколькими десятками проектов мы будем иметь абсолютно необозримую мусорную свалку проектов,
без возможности классификации и группировки.
Ранее в папке Project можно было использовать древовидную структуру папок для хранения проектов.
Теперь структура хранения в папке SharedProject претендующая на "большие групповые проекты" имеет один уровень вложенности
- группировочные подпапки в SharedProject создавать нельзя, а возможно только внутри проекта.
То есть при работе уже с несколькими десятками проектов мы будем иметь абсолютно необозримую мусорную свалку проектов,
без возможности классификации и группировки.
Сейчас тоже никто не мешает делать древовидную структуру внутри проекта и держать там что угодно.
Хоть несколько проектов.
Нельзя переименовать корневую папку проекта.
Зачем так сделано?
Сейчас тоже никто не мешает делать древовидную структуру внутри проекта и держать там что угодно.
Хоть несколько проектов.
В таком случае становится во многом бессмысленным файл описания проекта, например версия, тип программы, платформа, иконка - для группы проектов практически не имеют смысла.
Разумнее кажется разрешить при необходимости создание просто папок в корне Shared Projects - для иерархии разработок, и размещать внутри их проекты.
Так как это сделано сейчас - это проекты ради проектов, а не ради программ (советников и пр.)
И неудобства при значительном числе различных разработок (с развитой иерархией) очень существенны.
Например вот такая структура
будет на верхних уровнях сплошь замусорена совершенно не нужными файлами групп проектов, хотя непосредственно проекты будут находится лишь на нижних уровнях.
В таком случае становится во многом бессмысленным файл описания проекта, например версия, тип программы, платформа, иконка - для группы проектов практически не имеют смысла.
Разумнее кажется разрешить при необходимости создание просто папок в корне Shared Projects - для иерархии разработок, и размещать внутри их проекты.
Так как это сделано сейчас - это проекты ради проектов, а не ради программ (советников и пр.)
И неудобства при значительном числе различных разработок (с развитой иерархией) очень существенны.
1) А вы вообще работаете с системами типа сабвершена/гита, знаете как они функционируют?
2) Почему вы вдруг решили, что вам запрещают создавать древовидные структуры внутри проекта хранилища без всяких mqproj? Я же четко сказал - создавайте, если хотите.Нельзя переименовать корневую папку проекта.
Зачем так сделано?
Потому что это разделяемый проект в хранилище, к которому привязываются и другие участники. Много что в системе имеет прямую привязку к имени проекта.
Смена имени очень не рекомендуется с технической точки зрения. Поэтому, если работаете с разделяемыми проектами, надо выбирать хорошее публичное имя, которое не придется менять.