juriy5555 : Openbroker에 대한 데모와 실제 계정이 있습니다. 실제 생활에서 모든 Access 서버는 동일한 결과를 제공합니다. 음, 데모는 동일합니다. Si-6.16, RTS-6.16, SBRF-6.16을 살펴보았습니다. 모든 변경 사항은 1000의 배수입니다. 안 그래?
이제 실제로 SymbolInfoTick의 요청에 따라 실제 밀리초(1000의 배수) 대신 반환 된 MqlTick 구조 에 0이 제공됩니다.
실제 밀리초는 CopyTicks에서 제공됩니다. 2064, 3064, 4064라면 그랬다는 뜻입니다. 왜 그런 일이 일어났는지, 나는 모른다
귀하의 코드를 살펴보았습니다. 출력 지정자 %-4d는 무엇입니까? time_msc는 길기 때문에 d는 가지 않습니다. % I64d 여야 합니다.
네 죄송합니다. 코드는 내 것이 아닙니다. 작성자는 실제로 StringFormat에 잼이 있습니다. Print (tick.time_msc) 를 통해 루프의 각 반복에 표시됩니다. 결과는 마지막에 모두 0이므로 결과적으로 여전히 밀리초가 없습니다. CopyTicks 요청은 항상 계속됩니다.
네 죄송합니다. 코드는 내 것이 아닙니다. 작성자는 실제로 StringFormat에 잼이 있습니다. Print (tick.time_msc) 를 통해 루프의 각 반복에서 표시됩니다. 결과는 마지막에 모두 0이므로 결과적으로 여전히 밀리초가 없습니다. CopyTicks 요청은 항상 계속됩니다.
juriy5555 : Пока не знаю, что и у кому конкретно писать, я в этом несколько месяцев. Буду надеяться, что ОпенБрокер всё таки обновит сервер. ps мой билд клиента 1340
저도 계획이 조금 다르지만 궁금한게 있는데, 진드기에서 전달되는 정보가 맞는지 저도 궁금합니다.
실제 볼륨에 대한 질문입니다.
표시기에서 틱에 대한 정보를 요청하면 실제 볼륨이 volume[] 배열에 들어갑니다. 그리고 이론적으로 틱에서 정보를 얻으면 양초당 누적된 볼륨이 volume[] 배열의 값과 일치해야 합니다.
다음은 테스트 코드의 예입니다.
//+------------------------------------------------------------------+//| Custom indicator initialization function |//+------------------------------------------------------------------+intOnInit ()
{
//--- indicator buffers mapping//---return ( INIT_SUCCEEDED );
}
//+------------------------------------------------------------------+//| Custom indicator iteration function |//+------------------------------------------------------------------+intOnCalculate ( constint rates_total,
constint prev_calculated,
constdatetime &time[],
constdouble &open[],
constdouble &high[],
constdouble &low[],
constdouble &close[],
constlong &tick_volume[],
constlong &volume[],
constint &spread[])
{
//--- Получение данных по тикуMqlTick tick; // Структура хранения инфо по тикуSymbolInfoTick ( _Symbol ,tick ); // Получение данных по тикуPrint ( "ask: " + DoubleToString (tick.ask, _Digits )+ ", bid: " + DoubleToString (tick.bid, _Digits )+ ", last: " + DoubleToString (tick.last, _Digits )+
", vol: " ,tick.volume, ", flags: " ,tick.flags);
//--- Формирование объемаstaticulong sVol; // Суммарный объем из тиков на свечеif (prev_calculated<= 0 ) // Если первый запуск
sVol=tick.volume; // Запоминаем значение тикаelse
{
if (rates_total>prev_calculated) // Если образовалась новая свеча
{
sVol=tick.volume; // Запоминаем значение объема первого тика
}
else// Если новая свеча не образовалась
sVol+=tick.volume; // Суммируем объем тика с накопленным объемом
}
Print ( "Реальный объем: " ,volume[rates_total- 1 ], ", накопленный объем: " ,sVol);
//--- return (rates_total);
}
//+------------------------------------------------------------------+
지금은 플래그에 집착하지 않고 수신된 각 틱이 sVol의 총 볼륨을 변경한다고 가정합니다(내가 아는 한 그렇지 않음).
우리는 새로운 양초가 형성되기를 기다리고 있으며 저널의 항목을 살펴봅니다. 중개인 개설, 실제 계정, 빌드 1340, RTS-6.16:
틱 표시기의 요청으로 판단하면 time_msk 필드 데이터는 1000의 배수입니다. 밀리초에 대한 이야기가 없으며 해상도는 1초입니다.
질문: MqlTick 구조를 확장한 요점은 무엇이었습니까?
안 그래?
Openbroker에 대한 데모와 실제 계정이 있습니다. 실제 생활에서 모든 Access 서버는 동일한 결과를 제공합니다. 음, 데모는 동일합니다. Si-6.16, RTS-6.16, SBRF-6.16을 살펴보았습니다. 모든 변경 사항은 1000의 배수입니다.
안 그래?
이제 실제로 SymbolInfoTick의 요청에 따라 실제 밀리초(1000의 배수) 대신 반환 된 MqlTick 구조 에 0이 제공됩니다.
다음 빌드를 기다려주세요.
PS 요청 시 CopyTicks 밀리초는 있는 그대로 제공됩니다.
테스트 목적으로 이 스레드에서 이 표시기를 다운로드했습니다. 그는 CopyTicks를 통해 마지막 30틱을 얻습니다. 또는 다른 서버(오픈브로커가 아님)에서 시도해야 할 수도 있습니다.
>>" 실제 밀리초 대신 0이 반환됩니다. "
0이 반환되지는 않지만 항상 1000의 배수인 차이가 있는 동일한 숫자가 반환됩니다. (...2064, ...2064, ...3064, ..., ..., ..4064)
테스트 목적으로 이 스레드에서 이 표시기를 다운로드했습니다. 그는 CopyTicks를 통해 마지막 30틱을 얻습니다. 또는 다른 서버(오픈 브로커가 아님)에서 시도해야 할 수도 있습니다.
>>" 실제 밀리초 대신 0을 반환합니다 ."
0이 반환되지는 않지만 항상 1000의 배수인 차이가 있는 동일한 숫자가 반환됩니다. (...2064, ...2064, ...3064, ..., ..., ..4064)
SymbolInfoTick 함수는 0을 반환합니다 .
실제 밀리초는 CopyTicks에서 제공됩니다. 2064, 3064, 4064라면 그랬다는 뜻입니다. 왜 그런 일이 일어났는지, 나는 모른다
귀하의 코드를 살펴보았습니다. 출력 지정자 %-4d는 무엇입니까? time_msc는 길기 때문에 d는 가지 않습니다. % I64d 여야 합니다.
0은 SymbolInfoTick 함수에 의해 반환됩니다 .
실제 밀리초는 CopyTicks에서 제공됩니다. 2064, 3064, 4064라면 그랬다는 뜻입니다. 왜 그런 일이 일어났는지, 나는 모른다
귀하의 코드를 살펴보았습니다. 출력 지정자 %-4d는 무엇입니까? time_msc는 길기 때문에 d는 가지 않습니다. % I64d 여야 합니다.
네 죄송합니다. 코드는 내 것이 아닙니다. 작성자는 실제로 StringFormat에 잼이 있습니다. Print (tick.time_msc) 를 통해 루프의 각 반복에 표시됩니다. 결과는 마지막에 모두 0이므로 결과적으로 여전히 밀리초가 없습니다. CopyTicks 요청은 항상 계속됩니다.
SymbolInfoTick 함수는 0을 반환합니다 .
실제 밀리초는 CopyTicks에서 제공됩니다. 2064, 3064, 4064라면 그렇습니다. 왜 그런 일이 일어났는지, 나는 모른다
귀하의 코드를 살펴보았습니다. 출력 지정자 %-4d는 무엇입니까? time_msc는 길기 때문에 d는 가지 않습니다. % I64d 여야 합니다.
첫 번째 게시물에서 표시기를 변경했습니다. 모든 종류의 StringFormat으로 놀 수 있는 것이 없습니다. 이제 다음과 같이 됩니다.
네 죄송합니다. 코드는 내 것이 아닙니다. 작성자는 실제로 StringFormat에 잼이 있습니다. Print (tick.time_msc) 를 통해 루프의 각 반복에서 표시됩니다. 결과는 마지막에 모두 0이므로 결과적으로 여전히 밀리초가 없습니다. CopyTicks 요청은 항상 계속됩니다.
MetaQuotes 데모 데이터에 대한 지표입니다.
틱 단위의 밀리초 부족에 대해 브로커에게 문의하십시오.
MetaQuotes 데모 데이터에 대한 지표입니다.
틱 단위의 밀리초 부족에 대해 브로커에게 문의하십시오.
추신 내 클라이언트 빌드는 1340입니다
juriy5555 :
Пока не знаю, что и у кому конкретно писать, я в этом несколько месяцев. Буду надеяться, что ОпенБрокер всё таки обновит сервер.
ps мой билд клиента 1340
저도 계획이 조금 다르지만 궁금한게 있는데, 진드기에서 전달되는 정보가 맞는지 저도 궁금합니다.
실제 볼륨에 대한 질문입니다.
표시기에서 틱에 대한 정보를 요청하면 실제 볼륨이 volume[] 배열에 들어갑니다. 그리고 이론적으로 틱에서 정보를 얻으면 양초당 누적된 볼륨이 volume[] 배열의 값과 일치해야 합니다.
다음은 테스트 코드의 예입니다.
지금은 플래그에 집착하지 않고 수신된 각 틱이 sVol의 총 볼륨을 변경한다고 가정합니다(내가 아는 한 그렇지 않음).
우리는 새로운 양초가 형성되기를 기다리고 있으며 저널의 항목을 살펴봅니다. 중개인 개설, 실제 계정, 빌드 1340, RTS-6.16:
등등, 표시기의 실제 볼륨은 누적 볼륨보다 훨씬 큽니다. 이것은 개발자에게 몇 가지 질문을 제기합니다.
1. OnCalculate() 함수의 volume[] 배열에서 얻은 볼륨이 틱에서 얻은 누적 볼륨과 같아야 합니까? 내 의견은 물론이어야합니다. 그렇지 않으면 왜 진드기로 표시합니까?
2. OnCalculate() 함수를 사용하여 볼륨을 누적하는 것이 맞습니까, 아니면 OnBookEvent()를 통해 볼륨을 얻는 것이 더 낫습니까? 도움말은 다음과 같이 말합니다.
Calculate 이벤트 는 Init 이벤트가 전송된 직후 와 가격 데이터가 변경될 때 지표에 대해서만 생성됩니다. OnCalculate 함수에 의해 처리됩니다.
따라서 이론상 맞는 말이지만 이에 대한 의견을 듣고 싶습니다.
3. 테스트 결과는 플래그 분석 없이 표시됩니다. 플래그를 분석하면 내가 이해하는 한 플래그 24(마지막 및 볼륨의 동시 변경)가 있는 틱에서 볼륨을 가져와야 합니다.
그러나이 경우 누적 볼륨은 훨씬 적습니다. 지금 틱을 올바르게 분석하는 방법(모든 필드가 기록되기 때문에)에 대한 개발자의 의견을 듣고 싶습니다. 플래그가 올바르게 구현되어 있습니까? 구현의 정확성에 대한 질문은 플래그가 있는 틱을 눈치채지 못했기 때문에 발생했습니다.
표시기 파일도 응용 프로그램에 있습니다.