Artyom Trishkin: Уже ведь был ответ. Через дефайн языка компиляции. То, что должно иметь несколько языков - настройки например - пишется для каждого языка.
Далее #ifdef в помощь.
Я немного не понимаю, есть ли возможность программно менять язык настроек советника в зависимости от языка терминала ???
Программно на уровне программы - нет. На уровне компиляции - да.
То-есть если у меня в программе 54 настройки и мне нужно сделать несколько версий программы на разных языках , с разным описанием дескрипшен и разными ссылками, не нужно для каждой версии делать перевод настроек и комбинировать ??
То-есть если у меня в программе 54 настройки и мне нужно сделать несколько версий программы на разных языках , с разным описанием дескрипшен и разными ссылками, не нужно для каждой версии делать перевод настроек и комбинировать ??
Нужно.
Всё, что выводится программой во время её работы, можно привязать к языку терминала, а настройки - лишь к самому коду. Для этого нужно в программе сделать несколько версий входных параметров и при компиляции дефайнами выбирать нужный язык настроек.
Всё, что выводится программой во время её работы, можно привязать к языку терминала, а настройки - лишь к самому коду. Для этого нужно в программе сделать несколько версий входных параметров и при компиляции дефайнами выбирать нужный язык настроек.
Даже не представляю как... Походу у меня пробел в знаниях, можно попросить небольшой пример ?
Ведь это работает так скомпилировал русскую версию ексешник вытащил, скомпилировал английскую, если что то забыл переделывай , если забыл вынуть ексешник то получил файл на том же языке..
Я сейчас делаю чуть по другому, я стараюсь исключить ошибки сделанные мною на автомате..
Меня немного пугает то с какой активностью разработчики стали делать все в проекты и сразу же сделали описание программы на главной странице проекта, которое стоит в приоритете перед тем описанием которое в коде...
Это грозит тем что для создания разных версий одной программы прийдется делать разные проекты и плодить кучу папок и файлов...
А зачем? Ну, в плюсах так сделано исторически, поскольку компы были слабые и использовали раздельную компиляцию. Вдобавок можно передавать заказчику в скомпилированном формате + заголовки в .h
Artyom Trishkin: Уже ведь был ответ. Через дефайн языка компиляции. То, что должно иметь несколько языков - настройки например - пишется для каждого языка.
Далее #ifdef в помощь.
Я давно настройки выношу в отдельный .mqh файл. Есть мультиплатформенное ядро .mq4/5, оно в идеале неизменно, за исключением подключаемых инклудов, большинство из которых определения классов, тоже мультиплатформенных.
При таком подходе сделать новый робот гораздо проще, надо только унаследоваться от класса сигналов и написать свой алгоритм открытия/закрытия. Ну и какая-то косметика + сахарок.
Сделал все свое, т.к. классы, касающиеся создания советника, это одна из немногих вещей, которые мне в СБ категорически не нравятся.
Ведь это работает так скомпилировал русскую версию ексешник вытащил, скомпилировал английскую, если что то забыл переделывай , если забыл вынуть ексешник то получил файл на том же языке..
Я сейчас делаю чуть по другому, я стараюсь исключить ошибки сделанные мною на автомате..
Я сделал свой шаблон-проект и выглядит он так
Проект Эксперт
папка кода
код программы
папка включений
настройки на русском
настройки на английском
папка русская версия программы
Русская версия программы
папка английская версия программы
Английская версия программы
Меня немного пугает то с какой активностью разработчики стали делать все в проекты и сразу же сделали описание программы на главной странице проекта, которое стоит в приоритете перед тем описанием которое в коде...
Это грозит тем что для создания разных версий одной программы прийдется делать разные проекты и плодить кучу папок и файлов...
согласен, я в этом поле ничего и не пищу, оно лишнее
Уже ведь был ответ. Через дефайн языка компиляции. То, что должно иметь несколько языков - настройки например - пишется для каждого языка.
Я немного не понимаю, есть ли возможность программно менять язык настроек советника в зависимости от языка терминала ???
Программно на уровне программы - нет. На уровне компиляции - да.
Программно на уровне программы - нет. На уровне компиляции - да.
То-есть если у меня в программе 54 настройки и мне нужно сделать несколько версий программы на разных языках , с разным описанием дескрипшен и разными ссылками, не нужно для каждой версии делать перевод настроек и комбинировать ??
То-есть если у меня в программе 54 настройки и мне нужно сделать несколько версий программы на разных языках , с разным описанием дескрипшен и разными ссылками, не нужно для каждой версии делать перевод настроек и комбинировать ??
Нужно.
Всё, что выводится программой во время её работы, можно привязать к языку терминала, а настройки - лишь к самому коду. Для этого нужно в программе сделать несколько версий входных параметров и при компиляции дефайнами выбирать нужный язык настроек.
Нужно.
Всё, что выводится программой во время её работы, можно привязать к языку терминала, а настройки - лишь к самому коду. Для этого нужно в программе сделать несколько версий входных параметров и при компиляции дефайнами выбирать нужный язык настроек.
Даже не представляю как... Походу у меня пробел в знаниях, можно попросить небольшой пример ?
Даже не представляю как... Походу у меня пробел в знаниях, можно попросить небольшой пример ?
Пример:
Пример:
Спасибо! Понял, я думал есть что то проще..
Ведь это работает так скомпилировал русскую версию ексешник вытащил, скомпилировал английскую, если что то забыл переделывай , если забыл вынуть ексешник то получил файл на том же языке..
Я сейчас делаю чуть по другому, я стараюсь исключить ошибки сделанные мною на автомате..
Я сделал свой шаблон-проект и выглядит он так
Проект Эксперт
Меня немного пугает то с какой активностью разработчики стали делать все в проекты и сразу же сделали описание программы на главной странице проекта, которое стоит в приоритете перед тем описанием которое в коде...
Это грозит тем что для создания разных версий одной программы прийдется делать разные проекты и плодить кучу папок и файлов...
А зачем? Ну, в плюсах так сделано исторически, поскольку компы были слабые и использовали раздельную компиляцию. Вдобавок можно передавать заказчику в скомпилированном формате + заголовки в .h
Просто, это удобно.
А в плюсах это актуально и сейчас.
Уже ведь был ответ. Через дефайн языка компиляции. То, что должно иметь несколько языков - настройки например - пишется для каждого языка.
Я давно настройки выношу в отдельный .mqh файл. Есть мультиплатформенное ядро .mq4/5, оно в идеале неизменно, за исключением подключаемых инклудов, большинство из которых определения классов, тоже мультиплатформенных.
При таком подходе сделать новый робот гораздо проще, надо только унаследоваться от класса сигналов и написать свой алгоритм открытия/закрытия. Ну и какая-то косметика + сахарок.
Сделал все свое, т.к. классы, касающиеся создания советника, это одна из немногих вещей, которые мне в СБ категорически не нравятся.
Спасибо! Понял, я думал есть что то проще..
Ведь это работает так скомпилировал русскую версию ексешник вытащил, скомпилировал английскую, если что то забыл переделывай , если забыл вынуть ексешник то получил файл на том же языке..
Я сейчас делаю чуть по другому, я стараюсь исключить ошибки сделанные мною на автомате..
Я сделал свой шаблон-проект и выглядит он так
Проект Эксперт
Меня немного пугает то с какой активностью разработчики стали делать все в проекты и сразу же сделали описание программы на главной странице проекта, которое стоит в приоритете перед тем описанием которое в коде...
Это грозит тем что для создания разных версий одной программы прийдется делать разные проекты и плодить кучу папок и файлов...
согласен, я в этом поле ничего и не пищу, оно лишнее