Передача данных через общую область или стандартный буффер из одного пользовательского индикатора в другой. - страница 2

 
Поддерживаю идею Serebro!

О похожей проблематике я писал здесь:
https://championship.mql5.com/2012/ru/news
 
Я опытный "старый конь", вспахавший на программистской ниве не одно поле, поэтому решение проблемы я нашел, и довольно изящное, хотя и по принципу "правой ногой через левое ухо", но не моя в этом вина, а беда, поскольку ничего лучшего MQL4 пока не предоставляет. Но мне искренне жаль молодых и начинающих, потому что своим интеллектуальным усилиям они могли бы найти более достойное применение, чем решать проблему передачи данных между пользовательскими индикаторами.
Болагодарю за участие в обсуждении. Думаю, на этом тема исчерпана.
 
а для молодых и начинающих, опытом не поделишься? а еще лучше статейку (тем более что гонорар можно заработать)
 
В деталях без согласия авторов платформы я ничего расписывать не буду - это не в моих правилах, но "на пальцах" идею подкину (реализовано на практике в системе MVSpyTrendPro).
Допустим надо передать параметры из пользовательского индикатора А в аналогичный программный субъект - В. В источнике- А описывается фиктивный буфер (фиктивный потому что рисовка его выполняться не будет, для него устанавливается параметр DRAW_NONE), для определенности BF[]. В конце функционального блока этой программы в зоне неиспользуемых баров (такие всегда можно найти) пишется что-то вроде BF[300]= f1, BF[299]=f2...С учетом того, что в принимающем индикаторе (я рассматриваю случай, когда он загружен в локальном окне) есть ограничение по MAX, обычно 100, поэтому значения f1 - масштабированы, т.е. если надо передать F1, то передается его масштабируемое значение f1=100/F1 и т.д. В принимающем модуле B пишем обращение к А: f1=iCustom( NULL,0,"инд А", , 300) и потом делаем масштабирование наоборот F1=100/f1 и т.д. Таким образом можно передавать и небольшие массивы. Думаю идея понятна.
Одно предостережение. В MQL4 в качестве буферов используются индексные массивы, которыми управляет сама система, поэтому индикатор А должен отработать полностью и без сбоев. При сбоях данные вряд ли передадутся.
В заключение: конечно это "изголение" в чистом виде, но хорошо, что можно хоть так.
 
Не совсем понял, чем это принципиально отличается от моего подхода ( "Metatrader платформа 5" ). Номера баров не в счёт. Судя по всему, основные усилия связаны с тем, чтобы не испортить картинку отрисовывающихся буферов. Я для облегчения стараюсь вообще без них, но кажется содержимое "фиктивного" буфера не влияет на масштаб картинки если его вводить через IndicatorBuffers. Если я подзабыл и путаю, то это просьба к разработчикам - чтобы не влияло. Ну а на специальные "обменные" буферы уж точно раньше МТ5 рассчитывать нечего. Да и там непонятно, разработчики то молчат.
 
А у меня механизм передачи данных совсем другой, нежели у Serebro, но без ограничения по барам, довольно таки быстрый (практически почти "прямое" обращение к данным других индикаторов). Однако это тоже "левой ногой чесать правое ухо", т.е. НЕ СИСТЕМНО. В общем, идея COMMON очень даже хорошая. На мой взгляд, реализовать ее даже в каком-то из очередных релизов MT4 не так уж сложно. Было бы на то желание разработчиков. Относительно аспектов безопасности - их можно обсудить и выявить все риски. Не думаю, что они какие-то критические.
 
volt:
А у меня механизм передачи данных совсем другой

Похоже речь идёт о передаче через файл? В принципе, с учётом буферизации, это должен быть действительно довольно быстрый и экономный механизм. Правда могут быть нюансы с синхронизацией, но если передаваемые значения меняются не слишком часто и резко это не так существенно.
Кстати, по дискуссии в https://championship.mql5.com/2012/ru/news - для того, чтобы рассчитались все буферы индикатора его достаточно вызвать из эксперта один раз, по идее. Последующие обращения, я думаю, просто берут данные из памяти. Но накладные расходы при этом видимо достаточно серьёзные (каждый раз требуется определить, рассчитывался ли уже вариант индикатора с данными параметрами) - отсюда и замедление. В этом возможно и состоит разница с индикатором, наброшенным на чарт - для него такие проверки и поиски вроде ни к чему.
 
Да Candid, Вы мыслите в верном направлении.
Разница с индикаторами, наброшенными на чарт многократная.
А метод мой работает и на M1.
Проблема синхронизации решается довольно просто.