Предложения по будущему MQL - страница 3

 
TedBeer:

вставлю и я свои 5 копеек:

- интерактивность:
хотя бы возможность создаваемым графическим объектам назначить вызов функции по клику;
тогда можно будет гибко управлять экспертом или менять параметры на лету;
я уж молчу :-) об интефейсных элементах - кнопках, листбоксах и пр. Хотя бы отрабатывать клики на граф. объектах

- несколько наложенных друг на друга плоскостей для вывода графики, чтобы можно было на лету включать/выключать определенные плоскости, менять их уровни

Поддерживаю двумя руками.

К сказанному можно добавить ещё такие пожелания свойств объектов:
- допускать/не допускать выделение объекта мышью;
- управлять выделением объекта программно;
- очень соблазнительно, конечно, иметь слои, если да, то хотелось бы иметь возможность настройки свойств слоёв.

Нужны также функции прямого пересчёта координат цены-времени в пиксельные и обратно (+ сопутствующие данные, например, размер окна в пикселях).

Хорошо бы ещё вертикальное окно, располагаемое произвольно справа или слева (для отображения пользовательской инфо), + возможность перетаскивать "пиксельные" объекты между окнами.

 

Еще в догонку категорически мало функций работы со строками, а именно:

- работа с регулярными выражениями:
RegExpReplace( str, /([0-9]+)/g, "\t\1")
RegExpMatch( str, /^[0-9]+$/i)
RegExpSplit( str, /\s|\t/)

- пара функций для конвертирования строку в массив и обратно:
int arr[] = explode("1,2,3,4,5,65,7,8", ",");
string z = implode(arr, ",")

ну или что-то подобное, в разных языках по-разному, но категорически восстребованные функции

- в догонку к заявке гибких структур(смотри мое предыдущее сообщение) - цикл по свойствам/методам:
for( name in Obj)
if( Obj[name] instanceof Function)
delete Obj[name];
else
str += name + ":" + Obj[name] + "\n";

- динамические массивы с легким добавлением новых элементов:
int arr[];
arr[] = 1; arr[] = 2; arr[] = 99;

 

- Сделайте нормальное вычисление логических выражений. Не надо брать пример с убогих языков типа Бейсика. Такая конструкция должна работать правильно - второе выражение не должно вычисляться вообще:

int a = 0;
if((a != 0) && (3/a > 0))
MessageBox( "OK");

- по интерфейсу редактора - code folding - возможность свернуть/развернуть конструкции (if, for, switch ...), т.е. спрятать код лежащий на более глубоком уровне. Ну думаю вы в курсе, что это есть такое :-)

- и наверно не надо вызывать автозаполнение при редактировании комментариев.

- на сладкое - добавлять в список автозаполнение доступные глобальные и локальные переменные и функции.

 

Чем больше пишу тем больше натыкаюсь на ограничения языка о которых давно и думать позабыл :-( Хотелось бы уже чтобы в новой версии язык соответсвовал современным реалиям.

- строки длиной всего 255 символов. Хочется много больше (только не делайте 64к, это давно уже ничем не обоснованный моветон)

- нету никаких ассоциативных массивов или хэш таблиц. Собственно запрошенные ранее гибкие структуры/классы - это и есть такой ассоциативный массив. Ну как приятно писать и использовать такой код:

Javascript:

obj = {};
obj[99] = true;
obj["down"] = { "price" : open_price, "lots" : requested_lots};
if( obj[name] )
....
if( name in obj)
....
for(var name in obj)
....

PHP:

$obj = array();
$obj[99] = true;
$obj["down"] = array( "price" => $open_price, "lots" => $requested_lots);
if( isset( $obj[$name]) )
....
foreach( $obj as $key => $value)
....

А попробуйте что-нибудь такое написать на MQL - голова пухнет, как обойти ограничения языка.

 

Я тоже перечислю немного:)

1,) Добавить поддержку разных типов .DLL, например .NET, ActiveX, по сути COM как вариант, позволить доступ к данным, путем передачи указателя на корневой класс или интерфейс, лучше конечно сделать так чтобы советник или индикатор, в виде класса помеченного атрибутами был доступен в качестве, того же советника/индикатора.

2.) Расширить реакцию советников/индикаторов, на приход котировок по всем инструментам вместо одного, централизовано обрабатывая все данные, для мультивалютки и сторонних зависимостей, либо добавить новые типы, например центральный советник/индикатор.

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

4.) Закрыть излишки настроек, на уровне, не показывать в следующий раз, например при запуске индикатора.

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

6.) Добавить такие события как, разрыв соединения, изменение состояния рынка и многие другие, возможно в виде виртальных методов класса советника/индикатора.

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

Надеюсь что советники/индикаторы, будут реализованы в виде класса или интерфейса для наследования.

Все, что я описал я реализую самостоятельно.

 

Ради всего того что я раньше делал с помощью стандартных функций MQL я делал такую уйму работы, загружая советник в каждое окно того инструмента который был нужен, а нужны были все, сейчас делаю минимум действий, которые многократно разгружают ресурсы, мало того практически могу использовать все данные, что есть в терминале, ну почему нельзя было сделать доступ из библиотеки таким образом? Все что было нужно библиотека класов в довесок к терминалу, а класы в памяти и так лежат, например для .NET такая библиотека есть, реализуя основу данных, но я даже выложить ее не имею права, получается, а она пригодилась бы всем, кто хочет использовать .NET ну и Presentation Framework например. В реале получается нужно написать все свое включая тестер и т.д. который работает на онлайновой истории тиков, по совершенно другим принципам, которые в прочем можно выбирать, а не упираться в те принципы, которые принимаются за основу компанией Meta Quotes, что я и делаю. Прорабатываю все подходы и т.д., но в виду опять же нынешних обстоятельств, я не вижу поля для деятельности, я вижу лишь поле для эксперементов и чем больше я узнаю и получаю, тем сложнее отказаться от того, чем эти возможности получены, не говоря о граблях, которые буквально разбросаны в пределах общего поля деятельности на языке MQL.

P.S.: Цель моего поста заключается в том, чтобы в будущем разработчики предоставляли инструментам данные в той форме, которой ими владеет терминал, ненужно сложностей, вернее извращения оставьте для MQL.Мы же хотим работать так как умеем и привыкли, но избегая сложных путей, не прибегая к "ковырянию". Тогда я думаю можно будет работать на публику и организовать рынок не только советников а еще и вспомогательного инструментария - библиотек, "ковыряния" ведь не продать, поверх терминала можно многое прикрепить, мало того пользователи ведь сами в состоянии этим заниматься, создавать все новые и новые инструменты, которых им нехватает. Многие пользователи, это разработчики/кодеры со стажем, которых при всех плюшках не заставить пользоваться MQL для реализации советников и индикаторов, однако при нынешних условиях, я больше чем уверен, 99% просто уходит в сторону и бросает это дело еще на подходе...

P.P.S.: Если кому-то интересно почему я не останавливаюсь и продолжаю давление на ситуацию, я скажу в ответ, - нельзя останавливаться на том, что затрагивает область твоей работы и влияет на качество достижения цели, которой могло бы и не быть, если бы не та же, дотошность и настырность:).

Файлы:
mtsclast.zip  127 kb
Причина обращения: