MarketInfo(symbol,MODE_TICKVALUE)는 귀하의 이익을 위한 브로커의 정보이며 실제로 서버 측 자체 계산에서 이 정보를 사용하지 않습니다. 귀하의 일일 명세서는 MarketInfo(symbol,MODE_SWAP) 값 및 MarketInfo(symbol,MODE_SPREAD)와 같습니다.
나는 MarketInfo(symbol,MODE_SWAP)가 브로커의 웹사이트에 게시되고 내 계정(라이브)의 위치에 입금/출금된 스왑 값과 비교할 수 없는 값을 반환하는 경우를 보았습니다.
나는 당신이 superbem에 대해 무엇을 걱정하고 있는지 잘 모르겠습니다. TICKVALUE 문제의 사실은 tickvalue의 값(올바르게 보고된 경우에도)이 가격에 의존한다는 것입니다. USDJPY의 가격이 81.00 또는 101.00인 경우 USDJPY의 tickvalue가 다릅니다.
MODE_TICKVALUE는 무슨 용도인가요? (좁게 유효한 용도가 하나 있으며 카운터 통화가 계정의 명칭이기도 한 통화 쌍 에 대해 일정합니다(예: USD 기반 계정의 경우 EURUSD).
내 생각에 더 나쁜 것은 tickvalue가 LONG 포지션에 대해서만 올바르게 계산된다는 것입니다... 그래서 tickvalue는 예를 들어 USDJPY(모든 교차 쌍 포함)의 숏 포지션에 대해 항상 잘못되었습니다.
여기서 교훈은 신뢰하되 검증하는 것입니다. 검증이 중개인별로 신뢰가 타당하지 않음을 증명하면 계산을 직접 하거나(내가 하는 일입니다) 다른 중개인을 찾을 때입니다. 시장 정보 값을 서버 측에서 실제로 수행하는 작업과 일치하도록 유지하는 데 더 주의를 기울입니다.
다른 점은 mt4가 forex에서만 작동할 때 통화 시세와 함께 정보가 필요하지 않았으며 항상 오른쪽에 3글자가 있었다는 것을 이해합니다. 그러나 이제 cfd에는 3개의 문자가 없으므로 이를 저장하는 변수가 있어야 합니다.
그리고 이것이 당신의 불만의 근원일 수도 있습니다... 당신이 중개인이 뭔가 를 해야 한다는 의견을 가지고 있다고 해서 중개인이 망가졌다는 의미는 아닙니다. 그것은 단지 당신이 특정한 방식으로 하는 것을 선호한다는 것을 의미합니다.
중개인은 아무 것도 시드할 필요가 없습니다. 물론 그렇게 하면 좋겠지만 그렇게 하고 방정식의 측면에서 거래 회계를 올바르게 운영할 필요는 없습니다(유일한 법적/기준적 의미에서 중요한 방정식의 측면).
그리고 카운터 통화가 항상 오른쪽에 있는 3글자는 아닙니다. 예를 들어 CMS의 경우 오른쪽에 있는 3개의 문자는 항상 "FXF"입니다. 그리고 IBFX mini 계정의 경우 오른쪽의 마지막 문자는 소문자 "m"입니다.
예, cfd 가격 평가에 사용되는 카운터 통화를 추출하는 방법이 있으면 좋을 것입니다. 3자이거나 정보를 저장하는 추가 변수일 수 있습니다. 그러나 다시 한 번 귀하의 기대 사이에 구별이 있어야 합니다(" ...") 및 브로커가 최소한의 작업으로 수행할 수 있는 작업과 여전히 문제 없이 작동하는 작업.
다른 예를 들겠습니다...서버 시간 동기화. 브로커와 모든 브로커가 실제로 서버 시간(TimeCurrent()을 사용하여 액세스하는 것)을 원자 시계 신호와 동기화된 어딘가로 유지한다면 좋지 않을까요? 브로커에서 브로커로, 심지어 여러 서버가 있는 경우 동일한 브로커 내에서도 양초의 실제 OHLC 값 에 관해서는 중요합니다. 그러나 그들은 그렇지 않습니다.
그들은 해야 하지만 그렇게 하지 않아도 분명히 기능할 수 있습니다. 나는 브로커가 실제로 하는 일의 현실을 설명하기 위해 브로커가 해야 할 일에 대한 기대치를 조정해야 하는 사람입니다.
superbem : 문제는 브로커가 아니라 소프트웨어라는 것입니다. 누가 개발했는지는 중요하지 않습니다.
아니요. 그들은 브로커 제품 을 판매합니다. 그것을 구성/유지하는 것은 그에게 달려 있습니다. 중개인이 마음에 들지 않으면 2가지 선택이 있습니다. 1. 그의 지원에 대해 이야기하고 그들이 당신을 위한 솔루션을 찾을 수 있는지 확인하십시오. 2. 다른 브로커로 전환합니다.
[...] 이제 명확합니까?
아니요.
이런
forex 이외의 다른 활동에 관해 mt4 및 서버 개발자에게 질문:
ticksize, lotsize, 견적 통화 및 물론 가격이 있는 브로커는 tickvalue를 가지고 있습니다.
내가 테스트한 여러 브로커에서 일어나는 일은 내가 위치를 열 때 서버에 올바른 tickvalue가 있는지 확인하지만 함수 marketinfo()의 tickvalue 모드에서 터미널이 불완전한 값을 반환한다는 것입니다...
브로커의 cf 견적 통화가 오지 않기 때문입니다.
따라서 marketinfo() 함수는 브로커에서 ticksize, lotsize 및 cfd 견적 통화가 있는 올바른 tickvalue를 반환하도록 수정될 수 있습니다. .
forex 이외의 다른 활동에 관해 mt4 및 서버 개발자에게 질문:
[...]
그들은 여기에 없습니다... MetaQuotes 에 문의하십시오.
한 번 더 시도해 보겠습니다.
...포지션을 열 때 서버에 올바른 tickvalue가 있는지 확인하지만 함수 marketinfo()의 터미널에서 tickvalue 모드는 불완전한 값을 반환합니다...
서버에 올바른 tickvalue가 있는지 어떻게 확인했습니까? MarketInfo(symbol,MODE_TICKVALUE)에 대해 불완전한 것은 무엇입니까 ?
견적 통화를 고려하지 않고 ticksize, lotsize 및 price만 사용하여 계산을 수행하고 활성 기본 통화 가 누락된 상태로 반환됩니다. 예금 통화와 일치하는 것이 잘 반환됩니다.
MarketInfo(symbol,MODE_TICKVALUE)는 귀하의 이익을 위한 브로커의 정보이며 실제로 서버 측 자체 계산에서 이 정보를 사용하지 않습니다. 귀하의 일일 명세서는 MarketInfo(symbol,MODE_SWAP) 값 및 MarketInfo(symbol,MODE_SPREAD)와 같습니다.
나는 MarketInfo(symbol,MODE_SWAP)가 브로커의 웹사이트에 게시되고 내 계정(라이브)의 위치에 입금/출금된 스왑 값과 비교할 수 없는 값을 반환하는 경우를 보았습니다.
나는 당신이 superbem에 대해 무엇을 걱정하고 있는지 잘 모르겠습니다. TICKVALUE 문제의 사실은 tickvalue의 값(올바르게 보고된 경우에도)이 가격에 의존한다는 것입니다. USDJPY의 가격이 81.00 또는 101.00인 경우 USDJPY의 tickvalue가 다릅니다.
MODE_TICKVALUE는 무슨 용도인가요? (좁게 유효한 용도가 하나 있으며 카운터 통화가 계정의 명칭이기도 한 통화 쌍 에 대해 일정합니다(예: USD 기반 계정의 경우 EURUSD).
내 생각에 더 나쁜 것은 tickvalue가 LONG 포지션에 대해서만 올바르게 계산된다는 것입니다... 그래서 tickvalue는 예를 들어 USDJPY(모든 교차 쌍 포함)의 숏 포지션에 대해 항상 잘못되었습니다.
여기서 교훈은 신뢰하되 검증하는 것입니다. 검증이 중개인별로 신뢰가 타당하지 않음을 증명하면 계산을 직접 하거나(내가 하는 일입니다) 다른 중개인을 찾을 때입니다. 시장 정보 값을 서버 측에서 실제로 수행하는 작업과 일치하도록 유지하는 데 더 주의를 기울입니다.
서버 측 계산은 MODE_TICKVALUE에 자동으로 시드되어야 합니다.
다른 점은 mt4가 forex에서만 작동할 때 통화 시세와 함께 정보가 필요하지 않았으며 항상 오른쪽에 3글자가 있었다는 것을 이해합니다. 그러나 이제 cfd에는 3개의 문자가 없으므로 이를 저장하는 변수가 있어야 합니다.
서버 측 계산은 MODE_TICKVALUE에 자동으로 시드되어야 합니다.
다른 점은 mt4가 forex에서만 작동할 때 통화 시세와 함께 정보가 필요하지 않았으며 항상 오른쪽에 3글자가 있었다는 것을 이해합니다. 그러나 이제 cfd에는 3개의 문자가 없으므로 이를 저장하는 변수가 있어야 합니다.
그리고 이것이 당신의 불만의 근원일 수도 있습니다... 당신이 중개인이 뭔가 를 해야 한다는 의견을 가지고 있다고 해서 중개인이 망가졌다는 의미는 아닙니다. 그것은 단지 당신이 특정한 방식으로 하는 것을 선호한다는 것을 의미합니다.
중개인은 아무 것도 시드할 필요가 없습니다. 물론 그렇게 하면 좋겠지만 그렇게 하고 방정식의 측면에서 거래 회계를 올바르게 운영할 필요는 없습니다(유일한 법적/기준적 의미에서 중요한 방정식의 측면).
그리고 카운터 통화가 항상 오른쪽에 있는 3글자는 아닙니다. 예를 들어 CMS의 경우 오른쪽에 있는 3개의 문자는 항상 "FXF"입니다. 그리고 IBFX mini 계정의 경우 오른쪽의 마지막 문자는 소문자 "m"입니다.
예, cfd 가격 평가에 사용되는 카운터 통화를 추출하는 방법이 있으면 좋을 것입니다. 3자이거나 정보를 저장하는 추가 변수일 수 있습니다. 그러나 다시 한 번 귀하의 기대 사이에 구별이 있어야 합니다(" ...") 및 브로커가 최소한의 작업으로 수행할 수 있는 작업과 여전히 문제 없이 작동하는 작업.
다른 예를 들겠습니다...서버 시간 동기화. 브로커와 모든 브로커가 실제로 서버 시간(TimeCurrent()을 사용하여 액세스하는 것)을 원자 시계 신호와 동기화된 어딘가로 유지한다면 좋지 않을까요? 브로커에서 브로커로, 심지어 여러 서버가 있는 경우 동일한 브로커 내에서도 양초의 실제 OHLC 값 에 관해서는 중요합니다. 그러나 그들은 그렇지 않습니다.
그들은 해야 하지만 그렇게 하지 않아도 분명히 기능할 수 있습니다. 나는 브로커가 실제로 하는 일의 현실을 설명하기 위해 브로커가 해야 할 일에 대한 기대치를 조정해야 하는 사람입니다.
문제는 브로커가 아니라 소프트웨어라는 것입니다. 누가 개발했는지는 중요하지 않습니다.
문제는 브로커가 모든 것을 구성할 수 없고 소프트웨어가 클라이언트에 일부 데이터를 표시하지 않는 옵션을 남겨 둡니다...
여기 있는 일부 사람들이 이 소프트웨어가 있는 그대로 완벽하다고 생각하는 이유를 모르겠습니다.
ㅋㅋㅋ...