Ошибки, баги, вопросы - страница 300

 
Yedelkin:
Так попробуйте работать с коротким именем индикатора, вставляя в него по необходимости при инициализации имена его параметров и/или значения параметров.

1. смысл был не в том.

Вот берется скажем определенный набор индикаторов, при этом какие-то из них могут присутствовать на графике а какие-то нет.

При этом пользователь может указывать в параметрах для этих индюков собственные параметры. как вот цель определить какие параметры и какие индюки юзаются.

2. Цель по сложгнй (реализация сложной торговой системы).

Берем несколько графиков, на которых пользователь при помощи шаблонов выставляет индикаторы и сопутствующее оформление.

Из эксперта мы получаем индикаторы на определенном графике, узнсаем их хендл (как минимум) и параметры.

после этого спокойно в советнике зная хендл индикатора работаем с ним как с обычным индюком (т.е. можем обратиться к буферам каждого индикатора и так далее).


Такой подход позволит советнику и трейдеру контролировать один набор индикаторов (что весьма удобно, поскольку визуализация тут очень полезна), при этом советник получает определенную гибкость.

Не менее важным будет то что в советнике не придеся указывать лишнии парамерты для индикаторов (чтобы трейдер их мог настроить). В данном случае трейдеру останется только настроить и сохранить шаблон/несколько шаблонов.

PS

Подобные идеи я встречал на форумах, там рекомендовалось через ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ вопрос решить (что не очень удобно и эффективно).

Как минимум не хвотает функуии позволяющей получить хендл индюка на графике, скажем ChartIndicatorID (с теми же параметрами что и для ChartIndicatorName).

А если к тому же появятся еще и ChartIndicatorSetXXX и ChartIndicatorGetXXX...

 
Interesting:

1. смысл был не в том.

Вот берется скажем определенный набор индикаторов, при этом какие-то из них могут присутствовать на графике а какие-то нет.

При этом пользователь может указывать в параметрах для этих индюков собственные параметры. как вот цель определить какие параметры и какие индюки юзаются.

2. Цель по сложгнй (реализация сложной торговой системы).

Берем несколько графиков, на которых пользователь при помощи шаблонов выставляет индикаторы и сопутствующее оформление.

Из эксперта мы получаем индикаторы на определенном графике, узнсаем их хендл (как минимум) и параметры.

после этого спокойно в советнике зная хендл индикатора работаем с ним как с обычным индюком (т.е. можем обратиться к буферам каждого индикатора и так далее).


Такой подход позволит советнику и трейдеру контролировать один набор индикаторов (что весьма удобно, поскольку визуализация тут очень полезна), при этом советник получает определенную гибкость.

Не менее важным будет то что в советнике не придеся указывать лишнии парамерты для индикаторов (чтобы трейдер их мог настроить). В данном случае трейдеру останется только настроить и сохранить шаблон/несколько шаблонов.

PS

Подобные идеи я встречал на форумах, там рекомендовалось через ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ вопрос решить (что не очень удобно и эффективно).

Как минимум не хвотает функуии позволяющей получить хендл индюка на графике, скажем ChartIndicatorID (с теми же параметрами что и для ChartIndicatorName).

А если к тому же появятся еще и ChartIndicatorSetXXX и ChartIndicatorGetXXX...

Поддерживаю данное предложение!
 
Interesting:

Как минимум не хвотает функуии позволяющей получить хендл индюка на графике, скажем ChartIndicatorID (с теми же параметрами что и для ChartIndicatorName).

А если к тому же появятся еще и ChartIndicatorSetXXX и ChartIndicatorGetXXX...

Для меня тоже это актуально. Поддерживаю.
 
Lizar:
Для меня тоже это актуально. Поддерживаю.
Если все за, то пусть инициатор пишет а СервисДеск.
 
-Alexey-:
Если все за, то пусть инициатор пишет а СервисДеск.

Да проблем то нет туда написать, просто есть подводные камни определенные (в основном связанные с инициализацией индикаторов и механизмом получения "хендлов"/идентификаторов индикаторами которые пользователь на график бросил).

Я думаю, можно сначала отдельную ветку создать, посвященную данному вопросу. А уж по итогам обсуждения и решения принимать о СервисДеске.

Поэтому в общее обсуждение и поместил (хотя сразу ветку было лень создавать).

 
Interesting:
проще на мой взгляд разбить на два индюка, хотя кому как.
можно. но вот что делать если расчеты очень тяжолые. комп дымиться. запускать одно и тоже для расчета 2 раза. (( не есть хорошо. Такое предложение (указывать буферу в какое окно его выводить) было в качестве предложенй к 5-ке или что то подобное.Жаль разработчики не сделали. я подумал что с помощью этого фокуса возможно
 
Trolls:
можно. но вот что делать если расчеты очень тяжолые. комп дымиться. запускать одно и тоже для расчета 2 раза. (( не есть хорошо. Такое предложение (указывать буферу в какое окно его выводить) было в качестве предложенй к 5-ке или что то подобное.Жаль разработчики не сделали. я подумал что с помощью этого фокуса возможно
скорей всего логику индюка можно усовершенствовать или ограничить определенными рамками. По крайней мере в 70% случаев можно.
 

Можно ли вернуть отображение баланса/средств на каждой сделке в тестере?

 Вариант который сейчас, очень неудобен при отладке и написании эксперта.

 
Jager:

Можно ли вернуть отображение баланса/средств на каждой сделке в тестере?

 Вариант который сейчас, очень неудобен при отладке и написании эксперта.

+1
 
mql5:
Спасибо за сообщение, исправлено.

Скажите, по какому принципу принимается решение о выпуске нового билда?

Я нашел ошибку, которая мне мешает вести разработку, сообщил о ней в доходчивой форме и очень надеялся на вашу оперативность в выпуске нового билда. Но вот прошло несколько дней, а нового билда все нет.

С таким подходом с вашей стороны у меня пропадает желание сообщать об ошибках и тем самым улучшать вашу платформу. Гораздо проще найти обходной путь, чем ждать новый билд, а баг в платформе так останется.

Когда я работал в софтверной конторе, там было правило: по факту обнаружения бага внешним разработчиком или пользователем немедленно собирался новый билд, чтобы у последних не пропадало желание улучшать качество продукта.

Думаю вам стоит подумать о политике компании в этом вопросе.

Причина обращения: