C-4 : 아무도 테이프로 직접 작업하지 않습니다. 현재 날짜에 틱이 정말로 필요한 경우 MT5에서는 프로그래밍 방식으로 틱을 누적하는 것이 어렵지 않습니다. 틱 정보는 공개적으로 사용 가능하고 동일한 금융의 서버에 있기 때문에 Expert Advisor에 대한 연결을 구성할 수 있습니다. 당신이 당신의 두뇌로 생각한다면, 거래자의 0.001%의 행복은 전체 시스템이 상당히 무거워질 것이라는 사실만큼 가치가 없습니다.
왜 모든 거래에 대한 테이블이 필요한지 잘 이해가 되지 않습니다. 사실, 대부분의 경우 필요한 작업 기간을 구성하려면 모든 거래에 대한 테이블이 필요합니다. MT5에서는 생각할 수 있는 모든 시간 프레임이 기본적으로 내장되어 있습니다. 그렇다면 왜 질문이 남습니까?
OI의 경우 실제 볼륨과 마찬가지로 정말 유용한 정보입니다. 시간이 지남에 따라 MT5에 나타날 것이라고 확신합니다.
추신: 모든 트랜잭션 테이블은 매우 특정한 경우에 사용되며 리소스 집약적이며 데이터 전송 채널의 대역폭을 요구하므로 브로커는 기본적으로 이 정보의 전송을 비활성화합니다. 클라이언트의 명시적 요청 후에만 브로커가 이 테이블을 연결합니다.
나는 모든 거래 의 테이블 에 찬성 하는 인수 를 하나 더 추가 하고 싶었 습니다 . 틱과 볼륨을 받는 것 외에도 이 테이블은 본질적으로 이 특정 틱 뒤에 2명의 사람(구매자 및 판매자)이 있음을 공식적으로 확인하는 문서이며 분쟁이 발생할 경우 이 테이블을 참조할 수 있습니다.
Y_e_g_o_r : 이것은 Quick 서버와 MT5 서버의 정보 수신 속도가 다르기 때문에 가능한데, 어떤 것은 더 빠르고 어떤 것은 느립니다
글쎄, 이것이 어떻게 될 수 있습니까? 데이터가 더 느리게 도착하더라도 특정 시점의 ID를 가지지만 여전히 특정 시간 프레임 내에 있어야 합니다. 이것이 내가 클라이언트-서버 애플리케이션을 상상하는 방법입니다. 서버간 지연에 대한 보정이 없었다면 단말에서 시작하는 단일 서비스가 작동하지 않을 수 있었다. 이유는 따로 있다고 생각합니다.
그리고 지연이 존재한다면 세션이 끝나기 전에 이 데이터가 올 것입니다. 그러나 일일 거래량 결과에 따르면 여전히 불일치가 있습니다.
레나트 :
이것은 틱 흐름을 수집하고 비교하여 정렬해야 합니다.
오류는 적어도 세 면에 있을 수 있습니다.
이 문제에 대한 솔루션을 달성하는 방법은 무엇입니까? 공식 버그로 등록하시겠습니까? 브로커에게 요청하시겠습니까?
Renat, 같은 악기의 같은 TF에서 실제 볼륨이 빠른 볼륨과 MT 사이에 다른 이유를 알려주세요. 매일 나는 작은 편차를 발견합니다. 이유는 무엇입니까?
다음은 오늘의 예입니다 - 18:42, MT5 - 3267, QUIK - 3270.
하루가 지나면 편차가 더 많이 누적됩니다.
(중개사 개설, 실계좌)
이것은 틱 흐름을 수집하고 비교하여 정렬해야 합니다.
오류는 적어도 3면에서 발생할 수 있습니다.
만세, 사진과 비디오의 사진이 있습니다.
나는 회개를 기대하고, 내 말을 반박하는 담벼락과 게시물을 기대합니다.
Nasdakova 종이, 당신은 그것에 제로 스프레드를 보여줍니다. 나머지는 여전히 그곳에서 주문을 배달합니다.
기다릴게 아파스테나
거래가 이루어질 것이라는 단순한 이유 때문에 입찰가와 입찰가가 같을 수 없습니다.
입찰가와 요청가의 차이는 최소 1핍입니다. 그렇지 않으면 거래가 발생합니다.
한 잔의 틀 내에서 모든 것이 정확합니다. :)
NBBO(National Best Bid/Offer)와 같은 것이 있습니다. 0 또는 음의 NBBO 스프레드는 매우 일반적입니다.
음, 거래 테이프는 예를 들어 수평 볼륨을 이해하는 데 유용합니다.
아무도 테이프로 직접 작업하지 않습니다. 현재 날짜에 틱이 정말로 필요한 경우 MT5에서는 프로그래밍 방식으로 틱을 누적하는 것이 어렵지 않습니다. 틱 정보는 공개적으로 사용 가능하고 동일한 금융의 서버에 있기 때문에 Expert Advisor에 대한 연결을 구성할 수 있습니다. 당신이 당신의 두뇌로 생각한다면, 거래자의 0.001%의 행복은 전체 시스템이 상당히 무거워질 것이라는 사실만큼 가치가 없습니다.
이것은 틱 흐름을 수집하고 비교하여 정렬해야 합니다.
오류는 적어도 3면에서 발생할 수 있습니다.
왜 모든 거래에 대한 테이블이 필요한지 잘 이해가 되지 않습니다. 사실, 대부분의 경우 필요한 작업 기간을 구성하려면 모든 거래에 대한 테이블이 필요합니다. MT5에서는 생각할 수 있는 모든 시간 프레임이 기본적으로 내장되어 있습니다. 그렇다면 왜 질문이 남습니까?
OI의 경우 실제 볼륨과 마찬가지로 정말 유용한 정보입니다. 시간이 지남에 따라 MT5에 나타날 것이라고 확신합니다.
추신: 모든 트랜잭션 테이블은 매우 특정한 경우에 사용되며 리소스 집약적이며 데이터 전송 채널의 대역폭을 요구하므로 브로커는 기본적으로 이 정보의 전송을 비활성화합니다. 클라이언트의 명시적 요청 후에만 브로커가 이 테이블을 연결합니다.
나는 모든 거래 의 테이블 에 찬성 하는 인수 를 하나 더 추가 하고 싶었 습니다 . 틱과 볼륨을 받는 것 외에도 이 테이블은 본질적으로 이 특정 틱 뒤에 2명의 사람(구매자 및 판매자)이 있음을 공식적으로 확인하는 문서이며 분쟁이 발생할 경우 이 테이블을 참조할 수 있습니다.
Otkritie에서 MT5를 테스트했는데 정말 메가 편리한 플랫폼입니다.
파일에서 기록을 다운로드 하는 옵션을 활성화하면 바로 가겠습니다. 그 동안에는 콤바인을 사용해야 합니다)
또 다른 온라인 솔루션이 있습니다.
이것은 보편적이지 않지만("매달린" 주문에는 적합하지 않지만 이는 저유동 기구에 더 적합합니다) 거의 적합합니다.
(개인적으로 나는 "테이프"에서 아무 것도 짜내지 못했지만 이것이 모든 사람이 할 수 없다는 것을 의미하지는 않습니다)
이것은 Quick 서버와 MT5 서버의 정보 수신 속도가 다르기 때문에 가능한데, 어떤 것은 더 빠르고 어떤 것은 느립니다
글쎄, 이것이 어떻게 될 수 있습니까? 데이터가 더 느리게 도착하더라도 특정 시점의 ID를 가지지만 여전히 특정 시간 프레임 내에 있어야 합니다. 이것이 내가 클라이언트-서버 애플리케이션을 상상하는 방법입니다. 서버간 지연에 대한 보정이 없었다면 단말에서 시작하는 단일 서비스가 작동하지 않을 수 있었다. 이유는 따로 있다고 생각합니다.
그리고 지연이 존재한다면 세션이 끝나기 전에 이 데이터가 올 것입니다. 그러나 일일 거래량 결과에 따르면 여전히 불일치가 있습니다.
이것은 틱 흐름을 수집하고 비교하여 정렬해야 합니다.
오류는 적어도 세 면에 있을 수 있습니다.
이 문제에 대한 솔루션을 달성하는 방법은 무엇입니까? 공식 버그로 등록하시겠습니까? 브로커에게 요청하시겠습니까?
그러한 불일치가 플랫폼의 확산을 크게 방해하는 것 같습니다.
고맙습니다!