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;
}
哦,我的天啊!它在历史上有效吗?
papaklass可能是指OnTradeTransaction返回错误?
如果OnTradeTransaction 中的信息可能是无效的,我们必须从历史中提取,以确保它是有效的。
如果onTradeTransaction的信息并不总是可靠的,我们必须从历史中提取,以确保信息被处理。
问题是,如果我们无论如何都要从历史记录中获取信息,那么我们到底为什么需要OnTradeTransaction?- 它只需要它来检查错误。经纪人拒绝了订单,我们在OnTradeTransaction中收到了订单被拒绝的答案,并对其进行了分析。
但为什么要对9页的内容流口水呢?
请不要无理取闹!顺便说一下,现在已经是10点了!
而且你有权利完全不看这里写的东西!
C-4,将被处理,当然,但为什么需要OnRefresh()?
许多事件 -> 一个处理程序。
来自各个角落的错误都集中在一堆!:)
发送的不是错误,而是数据。错误可能出现在处理程序中,但它们很容易解决,因为只有一个处理程序。
这正是我的意思。你需要事件分离。
发送的不是错误,而是数据。错误可能出现在处理程序中,但它们很容易解决,因为只有一个处理程序。
你不需要分离事件,你需要分离处理程序。事件产生数据。每种类型的数据 都由一个不同的处理程序来处理。谁收到数据并不重要,重要的是每种数据类型都有一个独特的处理程序。这里有什么没有分开?
然后有
这里有什么没有分享?
你所建议的(数据类型的处理)是MK目前所拥有的。OnTradeTransaction处理程序处理某种MqlTradeTransaction数据类型。这是真的,他们把很多东西放到这个数据类型中,即对应于不同事件的数据类型。
我建议每个事件都有自己的数据和自己的处理程序。有多少个事件,就有多少个处理程序。事件的划分(开仓、平仓、下单、修改订单、修改仓位,等等)。并由开发人员决定为哪些事件分配什么数据类型。
我所说的 "处理程序",不是指接收某种事件的系统函数,而是指分析这个或那个事件的某个专家顾问模块。为了使功能的数量成倍增加,在...每个人都为自己的事件服务--是没有意义的,越是这样,以正确的数量创建用户处理程序就越是初级。在我的案例中,就是这样做的。
一个相同的事件类被传递给完全不同的处理程序,需要完全不同类型的数据,这看起来很奇怪。例如,OnMouseMove需要一个在鼠标上按下的键及其坐标的掩码,OnKeyDown()需要一个被按下的键的代码,OnOrderChange需要一个被改变的订单的票据,可能还有一个描述确切变化的枚举。你可能认为,事件类包含了所有可能的事件的字段。但事实并非如此。事实上,事件类的对象 甚至不能存在,因为它的构造函数被隐藏在保护区域内。但它的后代大量存在--每个后代只处理不同的事件。然而,对于任何事件,都有一个标识符,表明它属于什么类型。知道了这个标识符,你就可以安全地从一个较大的类型转换到一个较小的类型。这是当处理程序被传递时,被执行隐式转换的子的类型。让我们看看我们的处理程序究竟是如何看待这个事件的。
美丽的...。看起来只有一个事件,但实际上可能有几十个。除了其类型,事件似乎几乎不包含任何信息,但事实上,处理程序可以自由地引用只有它们自己知道的方法。没有 "外部 "和 "内部 "事件,只有事件。而这些事件的数量有可能是无限的。一个事件可以是任何东西。一个事件可以包含所有种类的数据。通过遵循这一理念,我们达到了一个新的、更高层次的数据抽象。为什么要在你的头脑中创造限制,为什么要强加一个分类限制的抽象概念!
内部和外部事件的本质区别是执行时间。内部事件的执行时间几乎为零,而外部事件的执行时间为数百毫秒至数秒。
事件没有执行时间。如果一个事件已经到来,它就已经被执行了。这就是异步模式的工作方式。因此,因为事件的执行速度而将其划分为内部和外部是错误的。完全不分类是正确的,而是从具体的实施中进行非常抽象的思考。