Метод проверки вводимого input параметра - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Поступил оперативный ответ от техподдержки: обещают поправить проверку ввода по типам данных.
Честно говоря, проблема на пустом месте )) слон искусственно инкапсулирован в муху.
Я всегда делаю валидацию параметров при инициализации (дело 15-30 минут) и не жду помощи от техподдержки (2-5дней).
Цените свое время ))
Честно говоря, проблема на пустом месте )) слон искусственно инкапсулирован в муху.
Я всегда делаю валидацию параметров при инициализации (дело 15-30 минут) и не жду помощи от техподдержки (2-5дней).
Цените свое время ))
Давайте, сделайте валидацию:
Пользователь вводит 999, вы в коде получаете 12, допустимые алгоритмом границы: 0 - 255.
Что будете валидировать?
К слову при вводе 999, должны получить 231, а не 12.
Введите тип int для параметра , затем валидацию, а уж потом если необходимо присвойте uchar.
Назначение типа uchar - хранение кода символа, а не любого числа, за сим производится автокоррекция, то бишь обрезание старших бит.
Давайте в один байт записывать 32-битные числа и выяснять причину наших бед.
К слову при вводе 999, должны получить 231, а не 12.
Введите тип int для параметра , затем валидацию, а уж потом если необходимо присвойте uchar.
Назначение типа uchar - хранение кода символа, а не любого числа, за сим производится автокоррекция, то бишь обрезание старших бит.
Давайте в один байт записывать 32-битные числа и выяснять причину наших бед.
А теперь посмотрите, как это будет: input - это статическая переменная и ее в последствии никакими валидациями не изменить. Input переменную можно будет только проверить на соответствие ограничениям - а что потом? Если это input переменная выходит за пределы - придется выводить сообщение (внимание - если сообщение вывести в журнал, пользователь вообще может его не увидеть и не понять, что произошло) и самое главное - после того, как пользователю укажем на его ошибку, нужно будет или по-новому вводить input или прикреплять индикатор и опять-таки по-новой вводить input.
Зачем такие танцы с бубном, если вскоре будет введена проверка ввода по типам данных?
Предложение:
Использовать клавишу F1 для всплывающей подсказки, если курсор стоит в поле ввода значения input-параметра.
В этой подсказке разработчик сообщит диапазон ввода значений и назначение данного input-параметра.
А кто будет подсказывать пользователю нажать на F1 для показа подсказки?
Если уж на то пошло, то подсказку о диапазоне можно оформить как комментарий к input-переменной. И он будет виден сразу в окне входных параметров программы mql5.
А теперь посмотрите, как это будет: input - это статическая переменная и ее в последствии никакими валидациями не изменить. Input переменную можно будет только проверить на соответствие ограничениям - а что потом? Если это input переменная выходит за пределы - придется выводить сообщение (внимание - если сообщение вывести в журнал, пользователь вообще может его не увидеть и не понять, что произошло) и самое главное - после того, как пользователю укажем на его ошибку, нужно будет или по-новому вводить input или прикреплять индикатор и опять-таки по-новой вводить input.
Зачем такие танцы с бубном, если вскоре будет введена проверка ввода по типам данных?
Интересно вы рассуждаете. Ну введите:
получите предупреждение (которое сами же можете не заметить), а потом в коде из 5000-6000 строк будете искать проблему.
Есть выражение такое... "не впихуй невпихуемое". Используйте типы данных по их назначению.
Кстати, а кто отменил-то INIT_PARAMETERS_INCORRECT? Чем не устраивает? Да и кто говорил за то чтобы менять input переменную (точнее уж "константу")?
Да и помимо Alert и Print есть еще MessageBox...
Возьмите стандартный MovingAverage задайте период больше 2147483647, получите хоть какое-то предупреждение? А индикатор запустится )))
В общем кто хочет - ищет возможность...
Интересно вы рассуждаете. Ну введите:
получите предупреждение (которое сами же можете не заметить), а потом в коде из 5000-6000 строк будете искать проблему.
Есть выражение такое... "не впихуй невпихуемое". Используйте типы данных по их назначению.
Кстати, а кто отменил-то INIT_PARAMETERS_INCORRECT? Чем не устраивает? Да и кто говорил за то чтобы менять input переменную (точнее уж "константу")?
Да и помимо Alert и Print есть еще MessageBox...
Возьмите стандартный MovingAverage задайте период больше 2147483647, получите хоть какое-то предупреждение? А индикатор запустится )))
В общем кто хочет - ищет возможность...
Даже в Visual Basic при вводе данных в поле ввода есть возможность проверять и изменять вводимые значения. В MQL5 и в MQL4 возможности корректировать вводимые параметры нет. Как замена отсутствующей возможности корректировать введенное значение и приходится прибегать к ограничению максимального введенного числа с помощью типа данных input-параметра.
И вот здесь как раз выяснилась маленькая недоработка в языке MQL - на корректность ввода введенного параметра проверяется только левое (минимальное) значение типа данных, а правое значение (максимальное) введенного параметра не проверяется на корректность.
И я придерживаюсь мысли, что все действия для пользователя должны быть как более прозрачны, с минимальным появлением предупреждающих окон.
P.S. Кстати, MessageBox из индикатора не вызывается.