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