FileWriteArray() в CSV

 
а можно ли заставить FileWriteArray() писать массив в CSV-файл, а то утомительно писать каждый раз что-то вроде такого (и это хорошо, что данные по часам разбиты - а могло бы оказаться 365 дней):
 FileWrite(hFile,"Hours",0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23);


а потом 24 значения:

  FileWrite(hFile,
            Symbols[Sym],
            Value[0],
            Value[1],
            Value[2],
            Value[3],
            Value[4],
            Value[5],
            Value[6],
            Value[7],
            Value[8],
            Value[9],
            Value[10],
            Value[11],
            Value[12],
            Value[13],
            Value[14],
            Value[15],
            Value[16],
            Value[17],
            Value[18],
            Value[19],
            Value[20],
            Value[21],
            Value[22],
            Value[23]);
 
подумаем
 
Sfen, напиши свою функцию FileWriteArrayCSV() и все дела :)
Никто кроме тебя не знает какая функция тебе нужна.

Да и вообще, разработчикам лучше писать дополнения в виде библиотек на MQL.
Исключения только функции которые сейчас невозможно реализовать в MQL
или сложно реализуемые (тяжелые) в вычислительном плане.
 
Mak: писать свои функции придется в виде
FileWriteArrayCsv1(), FileWriteArrayCsv2(), и так до FileWriteArrayCsv365().
неохота.
Кроме того, библиотеки на текущей реализации писать не особенно здорово. Скажем, если есть вложенные функции, передающие и возвращающие строковые параметры, то где-то с третьего-четвертого уровня вложенности начинаются косяки типа uninitialized string. Так что я свои "библиотеки" между разными индикаторами таскал по copy/paste.
 
Mak: писать свои функции придется в виде
FileWriteArrayCsv1(), FileWriteArrayCsv2(), и так до FileWriteArrayCsv365().

Зачем?

В MQL циклы есть,
и преобразования числа в строку.
Больше ничего не нужно.

И будет 1 функция на все случаи.
 
Нужно еще, чтобы оно работало as advertised :)
сказать по правде, мне слишком часто встречается uninitialized string или что-то в таком духе, причем даже в MT3: в контексте типа Comment(x1," - ",x2); вылазит что-то типа 123.45STRING ERROR345.67. При попытке написать какой-нибудь аналог библиотеки для MT4 такие штуки начинают лезть изо всех щелей :)
Так что сшивать 100 DoubleToStr() в одну я просто не рискну :)
 
Нужно еще, чтобы оно работало as advertised :)
сказать по правде, мне слишком часто встречается uninitialized string или что-то в таком духе, причем даже в MT3: в контексте типа Comment(x1," - ",x2); вылазит что-то типа 123.45STRING ERROR345.67. При попытке написать какой-нибудь аналог библиотеки для MT4 такие штуки начинают лезть изо всех щелей :)
Так что сшивать 100 DoubleToStr() в одну я просто не рискну :)

А Вы пришлите пример глючного кода на stringo metaquotes ru - разберемся и исправим.
 
Renat, если фиксировать, что именно там заглючило, и писать правильные багрепорты - TCO вырастет так, что дешевле будет использовать омегу.
Я плохо себе представляю, зачем писать баг репорт в случае, если результат работы зависит от номера компиляции, или если скомпилировалось, скажем, такое:
 
 /*[[
	Name := FOpen Test
	Author := Copyright © 2005 Sfen
	Lots := 1.00
	Stop Loss := 0
	Take Profit := 0
	Trailing Stop := 0
]]*/

Variables: hFile(0);

hFile = FileOpen(,";");


У вас же должна там быть внутри какая-то группа тестирования? Или нет (судя по списку вакансий)? Она не должна подобные вещи через себя пропускать (по крайней мере, не в таких количествах, как реально есть), это их работа - искать такого рода явления. Если бы такие баги были редкие (как, скажем в процессорах, они относительно редкие), я бы поучаствовал с удовольствием, а пока рановато (еще лет через пять можно будет затеваться).

 
У вас же должна там быть внутри какая-то группа тестирования? Или нет (судя по списку вакансий)? Она не должна подобные вещи через себя пропускать (по крайней мере, не в таких количествах, как реально есть), это их работа - искать такого рода явления. Если бы такие баги были редкие (как, скажем в процессорах, они относительно редкие), я бы поучаствовал с удовольствием, а пока рановато (еще лет через пять можно будет затеваться).

При работе над проектом MetaTrader 4 мы полностью реорганизовали свою организационную структуру. И тестирование у нас идет постоянно, все креши автоматически ночью попадают к нам в базу групповой разработки через систему LiveUpdate, полные стресс-тесты для MQL4 уже много месяцев пишутся внутри компании. Публичное бета-тестирование уже идет с ноября - мы никого в реал не запускали. Я сам лично каждый день борюсь за качество кода, безопасность и простоту в системе MetaTrader 4 .

Нас много критиковали и делали предложения на улучшения. Многое было нами исправлено.

К сожалению, сейчас уже в MetaTrader 3 мы не вносим никаких изменений. На это уже не остается сил.
В любом случае посмотрите на прогресс разработок с MetaTrader 3 на MetaTrader 4 - это совершенно новый уровень (как по качеству результата, так и по затратам на разработку).
 
Смотреть на MT 4 просто рано. Я когда начал с ним работать, встречал больше одного глюка (в языке) в день. Причем речь идет о существенных глюках, вроде того, что компилятор выкидывает использующуюся функцию как nonreferenced и потом скрипт вешает терминал при попытке выполнения этой функции. Сейчас я их больше не встречаю в основном из-за того, что 1) стараюсь на MQL4 больше не писать и 2) большинство сомнительных ситуаций помню и обхожу.

Да шут с ним с языком - меня до сих пор изумляет, как трендлайны проводятся. Например, по виклям провожу два трендлайна, один синий, другой красный, причем синий везде (во всех точках) выше красного. Переключаюсь на daily и вижу синий снизу, красный сверху.

Креш - это еще не все, и на самом деле не так существенно. Гораздо интереснее (в языке), если функция не работает так как надо и при этом не возвращает кода ошибки. При тестировании языка централизованная база описаний ошибок большого выигрыша не дает. Нужны test cases, в виде (большого числа, не слишком большого размера) программ на языке, использующих все функции, которые есть. Для того, чтобы их написать, в свою очередь, нужны спецификации на язык и его (стандартные) функции, которые, если я правильно понимаю, отсутствуют (желающие могут покурить имеющуюся документацию на функцию SpeechText() или PlaySound() - особо желающие могут сравнить последнюю с Plaftorm SDK). Печаль, товарищи.
 
Да шут с ним с языком - меня до сих пор изумляет, как трендлайны проводятся. Например, по виклям провожу два трендлайна, один синий, другой красный, причем синий везде (во всех точках) выше красного. Переключаюсь на daily и вижу синий снизу, красный сверху.


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

С уважением, и т.д.
Причина обращения: