OI에 대한 정보, 현재 매수 및 매도 주문 수 등 FORTS 거래 플랫폼에만 해당되며 다른 플랫폼(FX 및 거래소)에서는 사용할 수 없습니다. 따라서 통합 MqlTick 인터페이스에 이 정보를 포함하는 것이 의심스러운 것 같습니다. 그러나 action 및 time_count 필드에 대해서는 - 실제로 존재가 유용할 것입니다.
Vasiliy Sokolov : OI에 대한 정보, 현재 매수 및 매도 주문 수 등 FORTS 거래 플랫폼에만 해당되며 다른 플랫폼(FX 및 거래소)에서는 사용할 수 없습니다. 따라서 통합 MqlTick 인터페이스에 이 정보를 포함하는 것이 의심스러운 것 같습니다. 그러나 action 및 time_count 필드에 대해서는 - 실제로 존재가 유용할 것입니다.
예, 포함된 구조는 중요하지 않습니다. 그것은 가능하고 별도의 것입니다. 분명히 앞으로 몇 년 동안은 일어나지 않을 것입니다.
나는 이미 예전 DDE 프로토콜을 회상하기 시작했습니다. 결국, 나는 거기에서 이 정보를 빨리 얻어야 할 것입니다.
좋아, 자르자.
거래소 또는 거래/날짜 게이트웨이에서 보고한 마지막 거래 가격.
일반적으로 입찰 요청이 올 COPY_TICKS_INFO 모드를 요청하는 것이 좋습니다.
어제 COPY_TICKS_INFO 모드를 사용하여 관심을 끌지 못한 것이 있었습니다. 입찰가와 매도호가가 확실히 합쳐질까요? 즉, 이것이 Forex의 모드입니까?
이제 동작은 COPY_TICKS_ALL 모드에서와 동일합니다(즉, 별도의 입찰(요청 = 0), 별도의 요청(bid = 0)은 <5000(대략) 틱을 요청한 후 올 수 있으며 더 많은 경우 두 가격 모두.
또한 요청된 것보다 더 적은 수의 틱이 반환됩니다(모드 COPY_TICKS_INFO, COPY_TICKS_ALL - 요청한 만큼 - 많이 반환됨).
뭔가 잘못된 것 같아요...
어제 COPY_TICKS_INFO 모드를 사용하여 관심을 끌지 못한 것이 있었습니다. 입찰가와 매도호가가 확실히 합쳐질까요? 즉, 이것이 Forex의 모드입니까?
자르지 않고 CopyTicks를 위한 별도의 확장 구조를 만드는 것도 가능합니다.
물론 별도의 구조는 없을 것입니다.
따라서 마지막에는 새로운 분야로 확장해 나갈 것입니다.
다음과 같이 잘라주세요.
우리는 이 데이터를 가지고 있습니다.
당분간 MqlTick 구조 를 확장할 수 있는 권한이 있는지 심각하게 고려하고 있습니다. 이 구조의 크기로 작업하는 사람들은 고통을 겪을 수 있습니다. 원칙적으로 미래를 위해 신속하게 절단하고 구조를 확장할 수 있습니다.
다음주 금요일 출시 전까지 결정하겠습니다.
MqlTick을 사용하는 사람들은 sizeof(MqlTick)를 사용했고 그렇지 않은 사람들은 이 상황이 올바른 프로그래밍에 대한 좋은 교훈이 될 것입니다.
일반적으로 : " 지옥으로 자르다 "
OI에 대한 정보, 현재 매수 및 매도 주문 수 등 FORTS 거래 플랫폼에만 해당되며 다른 플랫폼(FX 및 거래소)에서는 사용할 수 없습니다. 따라서 통합 MqlTick 인터페이스에 이 정보를 포함하는 것이 의심스러운 것 같습니다. 그러나 action 및 time_count 필드에 대해서는 - 실제로 존재가 유용할 것입니다.
예, 포함된 구조는 중요하지 않습니다. 그것은 가능하고 별도의 것입니다. 분명히 앞으로 몇 년 동안은 일어나지 않을 것입니다.
나는 이미 예전 DDE 프로토콜을 회상하기 시작했습니다. 결국, 나는 거기에서 이 정보를 빨리 얻어야 할 것입니다.
정확한 time_count(최대 ms)가 없으면 틱의 필요성이 일반적으로 의심됩니다.
예, 포함된 구조는 중요하지 않습니다. 그것은 가능하고 별도의 것입니다. 분명히 앞으로 몇 년 동안은 일어나지 않을 것입니다.
나는 이미 예전 DDE 프로토콜을 회상하기 시작했습니다. 결국, 나는 거기에서 이 정보를 빨리 얻어야 할 것입니다.
정확한 time_count(최대 ms)가 없으면 틱의 필요성이 일반적으로 의심됩니다.
일반적으로 이 infa는 MT5에서 어떻게 존재하며 오랫동안 방송되어 왔습니다. SymbolInfoGet* 함수를 통해 사용할 수 있습니다. 아무도 틱을 수신하고 데이터 유형 에서 결합할 때 이 정보를 요청하는 것을 금지하지 않습니다.
또 다른 질문은 중앙 집중식 서버 스토리지가 자체 스토리지보다 항상 더 안정적이라는 것입니다. 따옴표 저장에 대해 생각할 필요가 없습니다. 이 모든 것이 매우 편리합니다. 그러나 거듭 말씀드리지만 이는 치명적이지 않고 복구할 수 없습니다.
정확한 time_count(최대 ms)가 없으면 틱의 필요성이 일반적으로 의심됩니다.