MQL5에서 함께 배우고 쓰기 - 페이지 18

[[삭제]]

Yedelkin :

글쎄, 당신은 의미를 이해합니다. 기억을 통해 자세히 말씀드리면 다음을 확인할 수 있습니다. OrderSend() 함수 는 부울 값을 반환합니다. 이 경우 요청이 성공적으로 확인되면 주문 티켓이 MqlResult 구조의 변수에 기록됩니다. 나 자신을 위해 "주문 티켓 반환 기능"이라고 부릅니다. 다음은 출처에 대한 링크입니다. " OrderSend() 함수로 구매 요청을 보낼 때 요청이 성공적으로 검증되었을 때 생성된 주문 티켓을 즉시 찾을 수 있습니다 ."

그리고 중재자의 주도로 주제에서 벗어나면 비슷한 대답을 유지하십시오. MQL5에 대한 자습서가 없고 예상되지 않으므로 어떤 자습서를 보고 있는지 명확하지 않습니다. ...장점을 논하기 위해서인가, 아니면 전혀 하지 않기 위해서인가? :)

"금지"에 대한 답변 - 감사합니다. 이해합니다.

서버에서 응답이 수신될 때 어떤 일이 발생하는지 완전히 올바르게 이해하지 못했습니다.

OrderSend()는 실제로 부울 값을 반환하지만 이것이 가장 중요한 것은 아니며 가장 중요한 것은 서버로부터 응답을 받을 때 채워지는 구조입니다.

예, 실제로 티켓이 구조에 기록되지만(주문뿐만 아니라 거래도) 구조의 나머지 정보보다 실제로 더 중요합니까?

응답의 구조를 고려하십시오. 제 생각에는 사진이 대략 이렇습니다

 struct MqlTradeResult
{
//Очень важная информация
uint      retcode;           // Код результата операции
//Важная информация (важна при успешном запросе)
ulong     deal;          // Тикет сделки, если она совершена
ulong     order;         // Тикет ордера, если он выставлен
//Малосущественная информация (важна при успешном запросе, а также в случае реквоты)
double    volume;        // Объем сделки, подтверждённый брокером
double    price;         // Цена в сделке, подтверждённая брокером
//Малосущественная информация (важна при реквоте)
double    bid;           // Текущая рыночная цена предложения (цены реквота)
double    ask;           // Текущая рыночная цена спроса (цены реквота)
//Не существенная информация
string    comment;       // Комментарий брокера к операции (по умолчанию заполняется расшифровкой)
};

추신

MqlResult가 아니라 MqlTradeResult 구조를 호출하는 것이 더 정확합니다(내 의견으로는 그다지 중요하지 않지만).

요청이 올바르고 실행되면 서버가 이러한 트랜잭션 매개변수를 차단할 "권한이" 있고 EA에서 서버의 조치에 대한 반응이 필요할 수 있는 경우 볼륨과 가격 이 중요합니다.

[Yedelkin]

sergeev :

불행히도, 나는 아직 그것을 얻지 못했습니다.

어떤 이유로 반환 구조에 "시간" 필드가 있어야 합니다. 나타난 순서대로 시간을 사용하세요. 이것은 작은 역사를 통제하기에 충분합니다.

" OrderSend() 함수로 구매 요청을 보내면 요청이 성공적으로 확인되었을 때 생성된 주문 티켓을 즉시 확인할 수 있습니다. 하지만 동시에 주문 자체가 아직 클라이언트 단말에 나타나지 않을 수 있으며, OrderSelect 기능을 사용하여 선택하려는 시도는 실패 합니다. ". 티켓이 알려진 경우에도 주문 속성(주문 시간)으로 작업하는 것이 항상 가능한 것은 아니라는 두 번째 문장이 나옵니다. 따라서 "시간을 표시한 순서대로 사용"하는 것은 이상적인 솔루션이 아닙니다. 또한 주문이 전혀 열리지 않을 수 있습니다. 내 접근 방식은 히스토리에 들어가기 전에 주문에 무슨 일이 일어났는지에 관계없이 "작은 히스토리 제어 문제"를 해결할 것입니다.

[Yedelkin]

Interesting :

MqlResult 가 아니라 MqlTradeResult 구조를 호출하는 것이 더 정확합니다(내 의견으로는 그다지 중요하지 않지만).

나는 교과서를 공부하라는 조언에 대한 응답으로 "기억에서"를 썼습니다.

흥미로운 :

서버에서 응답이 수신될 때 어떤 일이 발생하는지 완전히 올바르게 이해하지 못했습니다.

OrderSend()는 실제로 부울 값을 반환하지만 그것이 가장 중요한 것은 아닙니다. 중요한 것은 서버로부터 응답을 받을 때 채워지는 구조입니다.

예, 실제로 티켓이 구조에 기록되지만(주문뿐만 아니라 거래도) 구조의 나머지 정보보다 실제로 더 중요합니까?

글쎄, 누가 더 나은 이해를 가지고 있는지 논쟁하지 말자 :) Sergeev에 대한 내 대답을보십시오. 그리고 여기서 반복합니다. 전략의 논리에 따르면 티켓과 주문이 생산을 위해 승인된 시간만 있으면 됩니다. 당신이 밑줄 친 것은 어느 쪽도 아니고 다른 쪽도 아닙니다. retcode와 같은 "매우 중요한 정보"는 내가 일반적으로 말하는 히스토리 다운로드를 최적화하는 데 전혀 도움이 되지 않습니다.

[[삭제]]

Yedelkin :
" OrderSend() 함수로 구매 요청을 보내면 요청이 성공적으로 확인되었을 때 생성된 주문 티켓을 즉시 확인할 수 있습니다. 하지만 동시에 주문 자체가 아직 클라이언트 단말에 나타나지 않을 수 있으며, OrderSelect 기능을 사용하여 선택하려는 시도는 실패 합니다. ". 티켓이 알려진 경우에도 주문 속성(주문 시간)으로 작업하는 것이 항상 가능한 것은 아니라는 두 번째 문장이 나옵니다. 따라서 "시간을 표시한 순서대로 사용"하는 것은 이상적인 솔루션이 아닙니다. 또한 주문이 전혀 열리지 않을 수 있습니다. 내 접근 방식은 역사에 들어가기 전에 주문에 무슨 일이 있었는지에 관계없이 작은 역사를 제어하는 문제를 해결할 것입니다.

글쎄, 나는 그것이 그렇게 중요하다면 개발자들에게 MqlTradeResult 구조에 추가하도록 요청하십시오(트랜잭션이 완료되거나 주문이 이루어진 시간의 형태로).

이것이 필요한 이유를 이해하지 못하지만 OnTrade()에 매개변수를 추가하는 것이 좋습니다.

[Yedelkin]

Interesting :

글쎄, 나는 그것이 그렇게 중요하다면 개발자들에게 MqlTradeResult 구조에 추가하도록 요청하십시오(트랜잭션이 완료되거나 주문이 이루어진 시간의 형태로).

그래서 처음부터 이것에 대해 물었습니다 :) 그런 선례가 있었나요? :)

덧셈. 6개월 전에 누군가가 그러한 질문을 제기했다면 여전히 비교적 빠른 시일 내에 기능이 등장하기를 희망할 수 있으며 다음 해를 기다리는 것이 날짜에 대한 변수를 직접 도입하는 것이 더 쉽습니다. 완전히 정확하지는 않지만 여전히 그렇습니다.

흥미로운 :

이것이 필요한 이유를 이해하지 못하지만 OnTrade()에 매개변수를 추가하는 것이 좋습니다.

나는 개인적으로 더 이상 거래 구조/매개변수가 나타날 때까지 기다릴 수 없습니다. 그래서 9개월을 기다렸습니다. 가지고 있는 것에서 벗어나야 합니다.

[[삭제]]

Yedelkin :
나는 교과서를 공부하라는 조언에 대한 응답으로 "기억에서"라고 썼습니다. 글쎄, 누가 정확한 이해를 가지고 있는지 논쟁하지 맙시다 :) Sergeyev에 대한 내 대답을보십시오. 그리고 여기서 반복합니다. 전략의 논리에 따르면 티켓과 주문이 생산을 위해 승인된 시간만 있으면 됩니다. 당신이 밑줄 친 것은 어느 쪽도 아니고 다른 쪽도 아닙니다. retcode와 같은 "매우 중요한 정보"는 내가 일반적으로 말하는 히스토리 다운로드를 최적화하는 데 전혀 도움이 되지 않습니다.

1. OrderSend() 및 업로드 히스토리, 그러나 여기에서 더 자세히 설명합니다(그렇지 않으면 내가 말하는 내용을 따라잡지 못하고 풀이 다 떨어진 것 같습니다).

2. 논리적으로 OrderSend()의 결과 로만 분석을 한다면 절차는 다음과 같다.

a) retcode를 확인하면 실제로 무슨 일이 일어났는지 알아야 합니다.

b) 결과가 성공적이면 티켓, 볼륨 및 가격을 얻습니다. 재 견적이 있으면 새로운 가격을 얻습니다 (우리는 그들이 우리에게 어떻게 맞는지 확인합니다)

c) 답변이 적절하고 오류가 없으면 티켓과 시간을 받습니다. 서버 시간을 가져오거나 기록에서 빼낼 수 있습니다(현재 대략적인 계산을 위해 서버 시간을 찾는 것이 더 편리함).

d) 답변에 만족하지 않거나 부분적으로만 만족하는 경우 - 볼륨이 일치하지 않거나 재견적을 받은 경우 다음 조치를 결정합니다.

추신

요컨대, 뭐라 말할 수 있지만 retcode는 살펴보는 것이 좋습니다.

[Yedelkin]

Interesting :

나는 그것이 무엇에 관한 것인지 이해하지 못하고 풀이 끝난 것처럼 보입니다).

토론을 처음부터 보십시오. ... retcode의 중요성을 부정하는 사람은 없지만 간단한 솔루션으로 retcode 없이도 가능합니다.

[---]

Yedelkin :
토론을 처음부터 보십시오. ... retcode의 중요성을 부정하는 사람은 없지만 간단한 솔루션으로 retcode 없이도 가능합니다.

제안된 옵션이 귀하에게 얼마나 중요합니까?

c) 답변이 적절하고 오류가 없으면 티켓을 받습니다. 시간은 현재로 간주할 수 있습니다.

[Yedelkin]

sergeev :

제안된 옵션이 귀하에게 얼마나 중요합니까?

이것은 표준 옵션( 위에서 언급한 단점이 있음) + 자체 절약 시간입니다. retcode를 확인할 필요가 없기 때문에 남은 유일한 질문은 시간 절약에 관한 것입니다. 혼자 또는 MqlTradeResult의 도움으로 미학적으로. 사실, 그것이 질문에 대한 것입니다 :)

[[삭제]]

Yedelkin :
이것은 표준 옵션( 위에서 언급한 단점이 있음) + 자체 절약 시간입니다. retcode를 확인할 필요가 없기 때문에 남은 유일한 질문은 시간 절약에 관한 것입니다. 혼자 또는 MqlTradeResult의 도움으로 미학적으로. 사실, 그것이 질문에 대한 것입니다 :)

요청이 성공적으로 완료되면 조만간 거래 내역이 기록되고 주문이 목록에 표시됩니다. 따라서 거기에서 정확히 무엇과 방법을 찾을 수 있습니다.

그리고 제안 된 옵션은 필요한 거의 모든 데이터를 즉시 얻고 불필요한 작업으로 고통받지 않는 사람들을 위해 말하자면 "서두르게"입니다.

물론 서버의 응답에 다른 것을 추가할 가치가 있지만 개발자가 이 옵션에 동의하지 않는 여러 가지 기능과 이유가 있습니다.

추신

그러나 내가 놓친 것이 있을 수 있으며 개발자는 그것이 매우 적절하다고 결정합니다.