papaklass는 아마도 OnTradeTransaction이 오류를 반환한다는 의미일까요?
OnTradeTransaction 의 정보가 신뢰할 수 없는 경우 정보가 신뢰할 수 있는지 확인하기 위해 기록에서 가져와야 합니다.
정보가 항상 OnTradeTransaction에 제공되지 않는 경우 모든 정보가 처리되었는지 확인하기 위해 기록에서 정보를 가져와야 합니다.
문제는 도대체 왜 OnTradeTransaction이 문제가 되지 않는다면, 어떤 경우에도 정보를 역사에서 가져와야 한다는 것입니다. - 오류 제어를 위한 경우에만. 주문이 접수된 것처럼 중개인이 거부한 것처럼 OnTradeTransaction에서 주문이 거부된 이유를 파악하고 분석했습니다.
오류가 아니라 데이터가 전송됩니다. 핸들러에 오류가 있을 수 있지만 핸들러가 하나만 있기 때문에 쉽게 수정할 수 있습니다.
이벤트의 분리가 아니라 핸들러의 분리가 필요합니다. 이벤트는 데이터를 생성합니다. 각 데이터 유형 에는 고유한 핸들러가 있습니다. 누가 데이터를 정확히 수신했는지는 중요하지 않습니다. 각 데이터 유형에는 고유한 핸들러가 있어야 합니다.
여기에서 공유되지 않는 것은 무엇입니까?
voidOnTradeTransaction ( constMqlTradeTransaction &trans, constMqlTradeRequest &request, constMqlTradeResult &result )
{
// Print( "Ticket = ", string( trans.order ), " --> ", EnumToString( trans.type ), " --> ", EnumToString(trans.order_state) );switch ( trans.type )
{
TRADE_TRANSACTION_ORDER_DELETE : switch ( trans.order_state )
{
Удаление ордера из списка открытых.
Ордер может быть удален из открытых в результате выставления
соответствующего запроса либо в результате исполнения (заливки) и переноса в историю.
}
break ;
TRADE_TRANSACTION_ORDER_ADD : switch ( trans.order_state )
{
Добавление нового открытого ордера.
}
break ;
TRADE_TRANSACTION_DEAL_ADD : switch ( trans.order_state )
{
Добавление сделки в историю. Осуществляется в результате исполнения ордера или проведения операций с балансом счета.
}
break ;
caseTRADE_TRANSACTION_HISTORY_ADD : switch ( trans.order_state )
{
Добавление ордера в историю в результате исполнения или отмены.
}
break ;
caseTRADE_TRANSACTION_ORDER_DELETE : switch ( trans.order_state )
{
Удаление ордера из списка открытых.
Ордер может быть удален из открытых в результате выставления
соответствующего запроса либо в результате исполнения (заливки) и переноса в историю.
}
break ;
caseTRADE_TRANSACTION_ORDER_UPDATE : switch ( trans.order_state )
{
Изменение открытого ордера.
К данным изменениям относятся не только явные изменения
со стороны клиентского терминала или торгового сервера,
но также и изменение его состояния при выставлении
(например, переход из состояния ORDER_STATE_STARTED в ORDER_STATE_PLACED или
из ORDER_STATE_PLACED в ORDER_STATE_PARTIAL и т.д.).
}
break ;
caseTRADE_TRANSACTION_DEAL_UPDATE : switch ( trans.order_state )
{
Изменение сделки в истории. Возможны ситуации,
когда ранее исполненная сделка изменяется на сервере.
Например, сделка была изменена во внешней торговой системе (бирже),
куда она была выведена брокером.
}
break ;
caseTRADE_TRANSACTION_DEAL_DELETE : switch ( trans.order_state )
{
Удаление сделки из истории.
Возможны ситуации, когда ранее исполненная сделка удаляется на сервере.
Например, сделка была удалена во внешней торговой системе (бирже), куда она была выведена брокером.
}
break ;
caseTRADE_TRANSACTION_HISTORY_UPDATE : switch ( trans.order_state )
{
Изменение ордера, находящегося в истории ордеров.
Данный тип предусмотрен для расширения функциональности на стороне торгового сервера.
}
break ;
caseTRADE_TRANSACTION_HISTORY_DELETE : switch ( trans.order_state )
{
Удаление ордера из истории ордеров.
Данный тип предусмотрен для расширения функциональности на стороне торгового сервера.
}
break ;
caseTRADE_TRANSACTION_POSITION : switch ( trans.order_state )
{
Изменение позиции, не связанное с исполнением сделки.
Данный тип транзакции свидетельствует именно о том,
что позиция была изменена на стороне торгового сервера.
У позиции может быть изменен объем, цена открытия,
а также уровни Stop Loss и Take Profit.
Информация об изменениях передается в структуре MqlTradeTransaction
через обработчик OnTradeTransaction .
Изменение позиции (добавление, изменение или ликвидация) в результате совершения
сделки не влечет за собой появление транзакции TRADE_TRANSACTION_POSITION .
}
break ;
caseTRADE_TRANSACTION_REQUEST : Уведомление о том, что торговый запрос обработан сервером,
и результат его обработки получен.
Для транзакций данного типа в структуре MqlTradeTransaction
необходимо анализировать только одно поле - type (тип транзакции).
Для получения дополнительной информации необходимо анализировать второй
и третий параметры функции OnTradeTransaction (request и result).
break ;
}
귀하가 제공하는 것(데이터 유형 처리)도 현재 MK에 있습니다. OnTradeTransaction 핸들러는 특정 MqlTradeTransaction 데이터 유형을 처리합니다. 사실, 이 데이터 유형에는 많은 것들이 채워져 있습니다. 다른 이벤트에 해당하는 데이터 유형.
각 이벤트에는 자체 데이터와 자체 핸들러가 있는 것이 좋습니다. 얼마나 많은 이벤트, 너무 많은 핸들러. EXACTLY 이벤트의 분리(포지션 열기, 포지션 닫기, 주문하기, 주문 수정, 포지션 수정 등). 그리고 어떤 데이터 유형이 어떤 이벤트에 귀속될지는 개발자가 결정할 수 있습니다.
"처리자"라는 단어는 이 또는 저 이벤트가 발생하는 시스템 기능이 아니라 이 이벤트를 분석하는 특정 EA 모듈을 의미합니다. 각각 고유한 이벤트에 대해 많은 On... 함수를 생성하는 것은 무의미합니다. 특히 필요한 양으로 사용자 정의 핸들러를 생성하는 것이 기본이기 때문입니다. 다음은 나를 위해 수행된 방법입니다.
////// Принимаем событие.///void OnEvent(Event* event)
{
switch (event.EventId())
{
case EVENT_MOUSE_MOVE:
OnMouseMove(event);
break ;
case EVENT_KEY_DOWN:
OnKeyDown(event);
break ;
case EVENT_ORDER_CHANGE:
OnOrderChange(event);
break ;
//etc...
}
}
완전히 다른 데이터 유형이 필요한 완전히 다른 핸들러에 동일한 Event 클래스가 전달되는 것이 이상하게 보일 수 있습니다. 예를 들어, OnMouseMove는 마우스의 누른 키와 해당 좌표의 마스크가 필요하고, OnKeyDown()은 누른 키의 코드가 필요하고, OnOrderChange는 변경된 주문 티켓과 발생한 변경을 설명하는 열거가 필요합니다. 이벤트 클래스에 가능한 모든 이벤트에 대한 필드가 포함되어 있다고 생각할 수 있습니다. 그러나 그렇지 않습니다. 사실 이벤트 클래스의 객체는 존재조차 할 수 없습니다. 생성자는 보호 범위에 숨겨져 있습니다. 그러나 그 후손은 풍부하게 존재합니다. 각 후손은 고유한 이벤트만 처리합니다. 그러나 모든 이벤트에는 해당 이벤트가 속한 유형을 나타내는 식별자가 있습니다. 이 식별자를 알면 더 큰 것에서 더 작은 것으로 안전한 유형 변환을 수행할 수 있습니다. 핸들러가 전달되는 순간 암시적 변환이 발생하는 것은 이 유형의 자식입니다. 이벤트 핸들러가 실제로 어떻게 보이는지 봅시다.
////// Реагируем на перемещение мыши.///
OnMouseMove(EventMouseMove* event)
{
int yCoord = event.YCoord();
int xCoord = event.XCoord();
printf ( "X координата: " + xCoord + "; Y координата: " + yCoord);
}
////// Реагируем на перемещение мыши.///
OnOrderChange(EventOrderChange* event)
{
int ticket = event.Ticket();
ENUM_ORDER_STATE state = event.OrderState();
printf ( "Ордер с тикетом " + ticket + " изменил свое состояние на " + EnumToString(state));
}
//etc...
아름다움 ... 이벤트는 하나뿐인 것 같지만 실제로는 수십 가지가 있을 수 있습니다. 이벤트는 그 유형을 제외하고는 실질적으로 어떤 정보도 포함하지 않는 것 같지만, 실제로 핸들러는 그들만이 알고 있는 메소드를 자유롭게 참조합니다.
"외부" 및 "내부" 이벤트는 없고 이벤트만 있습니다. 그리고 이러한 이벤트의 수는 잠재적으로 무한할 수 있습니다. 무엇이든 이벤트가 될 수 있습니다. 이벤트에는 모든 데이터가 포함될 수 있습니다. 이 철학을 따름으로써 우리는 새롭고 더 높은 수준의 데이터 추상화를 달성합니다. 왜 머리에 한계를 만들고, 왜 제한 추상화에 분류를 부과합니까!?
papaklass :
내부 이벤트와 외부 이벤트의 근본적인 차이점은 실행 시간입니다. 내부 항목의 경우 실제로 0과 같고 외부 항목의 경우 수백 밀리초에서 초까지 측정됩니다.
이벤트에는 실행 시간 이 없습니다. 이벤트가 왔다면 이미 완료된 것입니다. 이것이 비동기 모드가 작동하는 방식입니다. 따라서 이벤트를 내부와 외부로 분류하는 것은 얼마나 빨리 잘못 실행되는지에 따라 잘못된 것입니다. 전혀 분류하지 않고 특정 구현에서 극단적으로 추상화한다고 생각하는 것이 옳습니다.
여기 그 시간들이 있습니다! 역사에 사실입니까?
papaklass는 아마도 OnTradeTransaction이 오류를 반환한다는 의미일까요?
OnTradeTransaction 의 정보가 신뢰할 수 없는 경우 정보가 신뢰할 수 있는지 확인하기 위해 기록에서 가져와야 합니다.
정보가 항상 OnTradeTransaction에 제공되지 않는 경우 모든 정보가 처리되었는지 확인하기 위해 기록에서 정보를 가져와야 합니다.
문제는 도대체 왜 OnTradeTransaction이 문제가 되지 않는다면, 어떤 경우에도 정보를 역사에서 가져와야 한다는 것입니다. - 오류 제어를 위한 경우에만. 주문이 접수된 것처럼 중개인이 거부한 것처럼 OnTradeTransaction에서 주문이 거부된 이유를 파악하고 분석했습니다.
왜 9페이지에 침을 흘리지?
무례하지 마십시오! 그건 그렇고, 이미 10!
그리고 당신은 여기에 쓰여진 것을 읽지 않을 권리가 있습니다!
C-4는 물론 처리되지만 OnRefresh()가 필요한 이유는 무엇입니까?
많은 이벤트 -> 하나의 핸들러.
하나의 힙에서 모든 각도의 실수! :)
오류가 아니라 데이터가 전송됩니다. 핸들러에 오류가 있을 수 있지만 핸들러가 하나만 있기 때문에 쉽게 수정할 수 있습니다.
나는 정확히 이것에 대해. 이벤트 분리가 필요합니다.
오류가 아니라 데이터가 전송됩니다. 핸들러에 오류가 있을 수 있지만 핸들러가 하나만 있기 때문에 쉽게 수정할 수 있습니다.
이벤트의 분리가 아니라 핸들러의 분리가 필요합니다. 이벤트는 데이터를 생성합니다. 각 데이터 유형 에는 고유한 핸들러가 있습니다. 누가 데이터를 정확히 수신했는지는 중요하지 않습니다. 각 데이터 유형에는 고유한 핸들러가 있어야 합니다.여기에서 공유되지 않는 것은 무엇입니까?
하지만 더 있다
여기에서 공유되지 않는 것은 무엇입니까?
귀하가 제공하는 것(데이터 유형 처리)도 현재 MK에 있습니다. OnTradeTransaction 핸들러는 특정 MqlTradeTransaction 데이터 유형을 처리합니다. 사실, 이 데이터 유형에는 많은 것들이 채워져 있습니다. 다른 이벤트에 해당하는 데이터 유형.
각 이벤트에는 자체 데이터와 자체 핸들러가 있는 것이 좋습니다. 얼마나 많은 이벤트, 너무 많은 핸들러. EXACTLY 이벤트의 분리(포지션 열기, 포지션 닫기, 주문하기, 주문 수정, 포지션 수정 등). 그리고 어떤 데이터 유형이 어떤 이벤트에 귀속될지는 개발자가 결정할 수 있습니다.
"처리자"라는 단어는 이 또는 저 이벤트가 발생하는 시스템 기능이 아니라 이 이벤트를 분석하는 특정 EA 모듈을 의미합니다. 각각 고유한 이벤트에 대해 많은 On... 함수를 생성하는 것은 무의미합니다. 특히 필요한 양으로 사용자 정의 핸들러를 생성하는 것이 기본이기 때문입니다. 다음은 나를 위해 수행된 방법입니다.
완전히 다른 데이터 유형이 필요한 완전히 다른 핸들러에 동일한 Event 클래스가 전달되는 것이 이상하게 보일 수 있습니다. 예를 들어, OnMouseMove는 마우스의 누른 키와 해당 좌표의 마스크가 필요하고, OnKeyDown()은 누른 키의 코드가 필요하고, OnOrderChange는 변경된 주문 티켓과 발생한 변경을 설명하는 열거가 필요합니다. 이벤트 클래스에 가능한 모든 이벤트에 대한 필드가 포함되어 있다고 생각할 수 있습니다. 그러나 그렇지 않습니다. 사실 이벤트 클래스의 객체는 존재조차 할 수 없습니다. 생성자는 보호 범위에 숨겨져 있습니다. 그러나 그 후손은 풍부하게 존재합니다. 각 후손은 고유한 이벤트만 처리합니다. 그러나 모든 이벤트에는 해당 이벤트가 속한 유형을 나타내는 식별자가 있습니다. 이 식별자를 알면 더 큰 것에서 더 작은 것으로 안전한 유형 변환을 수행할 수 있습니다. 핸들러가 전달되는 순간 암시적 변환이 발생하는 것은 이 유형의 자식입니다. 이벤트 핸들러가 실제로 어떻게 보이는지 봅시다.
아름다움 ... 이벤트는 하나뿐인 것 같지만 실제로는 수십 가지가 있을 수 있습니다. 이벤트는 그 유형을 제외하고는 실질적으로 어떤 정보도 포함하지 않는 것 같지만, 실제로 핸들러는 그들만이 알고 있는 메소드를 자유롭게 참조합니다."외부" 및 "내부" 이벤트는 없고 이벤트만 있습니다. 그리고 이러한 이벤트의 수는 잠재적으로 무한할 수 있습니다. 무엇이든 이벤트가 될 수 있습니다. 이벤트에는 모든 데이터가 포함될 수 있습니다. 이 철학을 따름으로써 우리는 새롭고 더 높은 수준의 데이터 추상화를 달성합니다. 왜 머리에 한계를 만들고, 왜 제한 추상화에 분류를 부과합니까!?
내부 이벤트와 외부 이벤트의 근본적인 차이점은 실행 시간입니다. 내부 항목의 경우 실제로 0과 같고 외부 항목의 경우 수백 밀리초에서 초까지 측정됩니다.
이벤트에는 실행 시간 이 없습니다. 이벤트가 왔다면 이미 완료된 것입니다. 이것이 비동기 모드가 작동하는 방식입니다. 따라서 이벤트를 내부와 외부로 분류하는 것은 얼마나 빨리 잘못 실행되는지에 따라 잘못된 것입니다. 전혀 분류하지 않고 특정 구현에서 극단적으로 추상화한다고 생각하는 것이 옳습니다.