Это радует, что решился стрелку на рельсах творчества на MQL5 перевести.
Я всегда собирался это сделать. Никогда не говорил о распостранении для МТ4. )
Пока никаких трудностей перехода не увидел, кроме двух:
1. Все объявленные переменные и массивы нужно специально обнулять. В масштабах моей программы, ушло несколько часов на это дело.
2. Постоянная ошибка выхода за пределы массива. На четверке этого не замечал. Оказалось, ошибка у меня частая.
В остальном никаких сложностей пока не заметил. Только чертовски долго компилирует проект. Даже не знаю... Работа с конструктором будет здорово тормозится из за этого. :(
Я всегда собирался это сделать. Никогда не говорил о распостранении для МТ4. )
Пока никаких трудностей перехода не увидел, кроме двух:
1. Все объявленные переменные и массивы нужно специально обнулять. В масштабах моей программы, ушло несколько часов на это дело.
2. Постоянная ошибка выхода за пределы массива. На четверке этого не замечал. Оказалось, ошибка у меня частая.
В остальном никаких сложностей пока не заметил. Только чертовски долго компилирует проект. Даже не знаю... Работа с конструктором будет здорово тормозится из за этого. :(
Эта "штукатурка" как раз сразу же избавляет от необходимости исправлять уже написанное.
C #property strict в четверке возникала масса ненужных предупреждений по поводу того, что числа завернутые дефайнами в ключевые слова и прописываемые в киб-коде (коде конструктора) в массиве string Сontent "незаконно" приведены к типу стринг. Из за этого, эту #property strict я отключил. То есть, с точки зрения правил программирования, мой конструктор существовать не должен.))
C #property strict в четверке возникала масса ненужных предупреждений по поводу того, что числа завернутые дефайнами в ключевые слова и прописываемые в киб-коде (коде конструктора) в массиве string Сontent "незаконно" приведены к типу стринг. Из за этого, эту #property strict я отключил. То есть, с точки зрения правил программирования, мой конструктор существовать не должен.))
Поясню: Работа с конструктором представляет из себя инициализацию массива string. В этом массиве чередуются записи числовых значений и строк. Числами могут быть координаты и ключевые слова (и названия типов элементов), а строки - наименования или текст. #property strict требует, чтобы все в этом массиве было приведено к типу string. Однако, в этом случае, киб-код теряет нормальную читабельность. Выход - работать без #property strict.
Пример кода:
//----------------------------------------------------------------------------------
GROUP, A,
__, V_LINE,"vL",H,61,_,N_COLOR,(int)C'255,223,199',
END_GROUP,
//------------------------------------
i, AT, _X2X, "R1", 1, _Y2Y, "R1", 1,
Для авторизации и пользования сайтом MQL5.com необходимо разрешить использование файлов Сookie.
Пожалуйста, включите в вашем браузере данную настройку, иначе вы не сможете авторизоваться.
Вы вошли в аккаунт. Двухфакторная аутентификация отключена. Настройте её заново и отсканируйте новый QR-код или продолжите с отключённой двухфакторной аутентификацией.
Это радует, что решился стрелку на рельсах творчества на MQL5 перевести.
Я всегда собирался это сделать. Никогда не говорил о распостранении для МТ4. )
Пока никаких трудностей перехода не увидел, кроме двух:
1. Все объявленные переменные и массивы нужно специально обнулять. В масштабах моей программы, ушло несколько часов на это дело.
2. Постоянная ошибка выхода за пределы массива. На четверке этого не замечал. Оказалось, ошибка у меня частая.
В остальном никаких сложностей пока не заметил. Только чертовски долго компилирует проект. Даже не знаю... Работа с конструктором будет здорово тормозится из за этого. :(
Я всегда собирался это сделать. Никогда не говорил о распостранении для МТ4. )
Пока никаких трудностей перехода не увидел, кроме двух:
1. Все объявленные переменные и массивы нужно специально обнулять. В масштабах моей программы, ушло несколько часов на это дело.
2. Постоянная ошибка выхода за пределы массива. На четверке этого не замечал. Оказалось, ошибка у меня частая.
В остальном никаких сложностей пока не заметил. Только чертовски долго компилирует проект. Даже не знаю... Работа с конструктором будет здорово тормозится из за этого. :(
Вы #property strict не использовали в четверке?
Нет.
Нет.
Попадалово конкретное.
Пока в одиночку строишь небоскреб, не думаешь о штукатурке. Когда закончил все этажи, можно отделкой заняться.
Эта "штукатурка" как раз сразу же избавляет от необходимости исправлять уже написанное.
Эта "штукатурка" как раз сразу же избавляет от необходимости исправлять уже написанное.
C #property strict в четверке возникала масса ненужных предупреждений по поводу того, что числа завернутые дефайнами в ключевые слова и прописываемые в киб-коде (коде конструктора) в массиве string Сontent "незаконно" приведены к типу стринг. Из за этого, эту #property strict я отключил. То есть, с точки зрения правил программирования, мой конструктор существовать не должен.))
C #property strict в четверке возникала масса ненужных предупреждений по поводу того, что числа завернутые дефайнами в ключевые слова и прописываемые в киб-коде (коде конструктора) в массиве string Сontent "незаконно" приведены к типу стринг. Из за этого, эту #property strict я отключил. То есть, с точки зрения правил программирования, мой конструктор существовать не должен.))
Что мешало "законно" их приводить к типу string?
Что мешало "законно" их приводить к типу string?
Поясню: Работа с конструктором представляет из себя инициализацию массива string. В этом массиве чередуются записи числовых значений и строк. Числами могут быть координаты и ключевые слова (и названия типов элементов), а строки - наименования или текст. #property strict требует, чтобы все в этом массиве было приведено к типу string. Однако, в этом случае, киб-код теряет нормальную читабельность. Выход - работать без #property strict.
Пример того, что требует #property strict.