Краудсорсовый GUI. Открытое бета-тестирование. - страница 30
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Зачем, это реализуемо также через функцию которая вызывается по факту заполнения поля и входное значение типа шаблонного... все. Даже пусть будет типа стринг.... все равно высокоскоростного заполнения поля не будет
Дело не только в поле ввода. Например, необходимо получить текущее значение чекбокса - проверить есть галочка или нет.
все это легко также через вызов функции по факту выставления. и дальше работа програмиста.
По поводу окружения хотелось бы видеть определенный набор стандартов вызова (не меняя названия функции - т.к. я не знаю в каком куске кода мне может понадобиться та или иная функция) на се виды закладок и окон. выбор окна желательно через Селект. Также как и выбор стиля по изменения цвета при наведении.
Т.е. надо чтобы удобно было создать один прототип меню - и на его основании в коде сделать другой. Если идти через окружения...
Тут у метаквотов иногда коны с концами не сходятся в на некоторых участках кода.
Сюда желательно добавить дополнительный динамичский интерфейс который возникает при нажатии/наведении.... И это еще сверх малая часть
Дело не только в поле ввода. Например, необходимо получить текущее значение чекбокса - проверить есть галочка или нет.
Ну кроме этого еще существует такое понятие как Callback-функции, которые генерят события при изменении чего-либо. К примеру на форме есть чекбокс и нам нужно знать когда изменится его состояние. Вариант 1: с определенной периодичностью выполнять запросы к GUI для получения значения этого чекбокса и если значение отличается от предыдущего - тогда чекбокс изменился. В этом случае часть ресурсов тратится на постоянный периодический опрос - это не рентабильно.
Чтобы не тратить ресурсы впустую придуманы так называемые колбэк-функции, которые выдают оповещение именно при изменении значения элемента управления. к примеру кликнули по чекбоксу, за этим последовало изменение его состояния, как только состояние изменилось генерируется событие с типом, именем и значением элемента управления. А в подписке на это событие уже произойдет отработка нужного кода, который ждал изменения значения чекбокса. Это и называется событийной моделью.
все это легко также через вызов функции по факту выставления. и дальше работа програмиста.
По поводу окружения хотелось бы видеть определенный набор стандартов вызова (не меняя названия функции - т.к. я не знаю в каком куске кода мне может понадобиться та или иная функция) на се виды закладок и окон. выбор окна желательно через Селект. Также как и выбор стиля по изменения цвета при наведении.
Т.е. надо чтобы удобно было создать один прототип меню - и на его основании в коде сделать другой. Если идти через окружения...
Тут у метаквотов иногда коны с концами не сходятся в на некоторых участках кода.
сюда желательно изменить дополнительный интерфейс который возникает при нажатии/наведении.... И это еще сверх малая часть
Ну кроме этого еще существует такое понятие как Callback-функции, которые генерят события при изменении чего-либо. К примеру на форме есть чекбокс и нам нужно знать когда изменится его состояние. Вариант 1: с определенной периодичностью выполнять запросы к GUI для получения значения этого чекбокса и если значение отличается от предыдущего - тогда чекбокс изменился. В этом случае часть ресурсов тратится на постоянный периодический опрос - это не рентабильно.
Чтобы не тратить ресурсы впустую придуманы так называемые колбэк-функции, которые выдают оповещение именно при изменении значения элемента управления. к примеру кликнули по чекбоксу, за этим последовало изменение его состояния, как только состояние изменилось генерируется событие с типом, именем и значением элемента управления. А в подписке на это событие уже произойдет отработка нужного кода, который ждал изменения значения чекбокса. Это и называется событийной моделью.
Ну, Алексей, ты по старой памяти говоришь о внешем GUI, опрашиваемом советником через таймер. Тогда, нужны были коллбэки. Сейчас, все происходит внутри одного советника и вместо внешнего GUI, внутренний. Его собственный.
Петр, вообще-то колбеки - это не "старая память", а общая практика работы любого взаимодействия, не обязательно это должно быть связано с GUI, не зависимо от того внешний он или внутренний. И совершенно не важно ГДЕ это происходит, главное КАК это происходит. Колбек - это не таймер!
Ждем видео...
Петр, вообще-то колбеки - это не "старая память", а общая практика работы любого взаимодействия, не обязательно это должно быть связано с GUI, не зависимо от того внешний он или внутренний. И совершенно не важно ГДЕ это происходит, главное КАК это происходит.
Ждем видео...
Ну, Алексей, ты по старой памяти говоришь о внешем GUI, опрашиваемом советником через таймер. Тогда, нужны были коллбэки. Сейчас, все происходит внутри одного советника и вместо внешнего GUI, внутренний. Его собственный.
ну свои-то переменные проще помнить чем учить чужие.
А в обще в коде должно быть минимум глобальных переменных все реализуется через передачу кусков памяти и обработкой сразу нескольких значений. Логично что ..... .... .... ЗЫ попытался вырезать слова связные с объектами напрямую.
В общем проще обычные коолбэки.
ну свои-то переменные проще помнить чем учить чужие.
А в обще в коде должно быть минимум глобальных переменных все реализуется через передачу кусков памяти и обработкой сразу нескольких значений. Логично что ..... .... .... ЗЫ попытался вырезать слова связные с объектами напрямую.
В общем проще обычные коолбэки.
PS у вас там еще целое море работы по дизайну
Согласен. Только внутри одного советника они нам не понадобятся.
Хм... тогда такой простой вопрос: как узнать что состояние чекбокса изменилось?