OrderSend()问题 - 页 6

 
maryan.dirtyn:

我在绞尽脑汁......停止器就是不设置......还有很多错误。这是实验中剩下的东西,它不会再工作了

如果你这样做了,就不会有任何错误,但仍然没有设置止损。

在此 回答
 
Yedelkin:

显然,我没有把前面的问题解释得很清楚。让我再试一次。

在去年,ENUM_ORDER_TYPE_FILLING 枚举值列表的描述至少被改变了三次。 以前的描述看起来如下

enum_order_type_filling

识别器

描述

订单_灌装_福克

一笔交易只能以指定的数量和等于或优于订单中指定的价格执行。如果目前市场上没有足够的供应来满足该订单符号,那么该订单将不会被执行。这种填充类型用于SYMBOL_TRADE_EXECUTION_INSTANT 执行模式 SYMBOL_TRADE_EXECUTION_REQUEST

订单_填充_ioc

在订单规定的交易量范围内,以市场上可获得的最大交易量并以等于或优于订单规定的价格执行交易的协议。在这种情况下,将不会为缺失的那一卷下达额外的订单。这种填充类型只能在执行模式SYMBOL_TRADE_EXECUTION_MARKET SYMBOL_TRADE_EXECUTION_EXCHANGE 中使用,具体取决于交易服务器上的设置。

订单_填充_返回

同意在订单规定的交易量内,以市场上最大的交易量,以等于或优于订单规定的价格进行交易。在这种情况下,我们将以该订单中规定的价格为所缺的数量发出一个额外的订单。这种填充类型只用于挂单(TRADE_ACTION_PENDING

我们不难看出,ORDER_FILLING_RETURN和挂单之间 存在着一对一的对应关系,即 ORDER_FILLING_RETURN只能应用于挂单,所有 挂单的type_filling 字段只能用ORDER_FILLING_RETURN 的值填充。

对于市场订单(action==TRADE_ACTION_DEAL),根据服务器端设置的执行模式,type_filling 字段应该已经填写。

因此,我们有一定的范式:如果有一个挂单,ORDER_FILLING_RETURN;如果有一个市场订单,ORDER_FILLING_FOK或ORDER_FILLING_IOC(取决于模式)

现在,一切都被颠覆了一下,即。

enum_order_type_filling

识别器

描述

订单_灌装_福克

这种订单填充政策意味着订单只能被填充到指定的数量。如果目前市场上没有足够的金融工具的数量,订单将不会被执行。所需的数量可以从目前市场上的几个报价中编制出来。

订单_填充_ioc

表示同意在订单规定的数量内执行市场上的最大交易量。如果不可能完全执行,订单将被填充到可用的量,而未填充的量将被取消。

订单_填充_返回

这种模式只用于ORDER_TYPE_BUY_LIMIT和ORDER_TYPE_SELL_LIMIT订单。在部分执行的情况下,剩余数量的限价单不会被删除,而是仍然有效。

对于ORDER_TYPE_BUY_STOP_LIMIT和ORDER_TYPE_SELL_STOP_LIMIT订单,激活时将创建相应的ORDER_TYPE_BUY_LIMIT/ORDER_TYPE_SELL_LIMIT限价订单,其执行类型为ORDER_FILLING_RETURN。

只对市场订单 使用ORDER_FILLING_FOK和ORDER_FILLING_IOC的限制已经消失 同时, 根据服务器上设置的执行模式,对 市场订单 使用ORDER_FILLING_FOK和ORDER_FILLING_IOC 没有限制。 使用ORDER_FILLING_RETURN 有一个限制,即只能使用限价和止损订单

所以我的问题是:对所有订单(包括市场和挂单使用ORDER_FILLING_FOK和 ORDER_FILLING_IOC,包括限价和止损订单是否可以接受 有谁搞清楚了这些变化?

是的,在这个问题上有点模糊不清。

如果ENUM_SYMBOL_TRADE_EXECUTIONENUM_ORDER_TYPE_FILLING 之间完全对应,那么第二个显然是不必要的。

因此,不存在道德问题,很可能在一个 相同的ENUM_SYMBOL_TRADE_EXECUTION 值下, ENUM_ORDER_TYPE_FILLING不同值是可以接受的 。MQ会在这里描述一个可能性的表格,但很可能这个数据取决于交易服务器的设置。

因此,第二个道德,毕竟需要的是什么。

需要一个函数来返回一个有效的选项列表(ENUM_ORDER_TYPE_FILLING),用于请求的订单类型(即时或待定)

那里没有很多选择,所以你可以通过"|"把int塞进去。

如果我错了,请给我一个神奇的向导,在哪里找这个问题。



 

为了解决这个问题,我去看了一下标准库(作为一个习惯,如果不清楚就看别人怎么做)。

那里给出了方便继承的函数,而在 CTrade 类中没有使用 SetTypeFilling(),字段 type_filling 默认初始化为零,根据枚举,它对应于ORDER_FILLING_FOK

就这样,没有更多的工作。我想,既然这个字段没有出现在接口中,那就意味着在类中是自动填充的。

SZY一般来说,等待答案,如何修复它:)
 
目前,我看到一个出路:猛击服务器,直到它给出你需要的答案。
 
her.human:
到目前为止,我看到一个解决方案:猛击服务器,直到你得到你想要的答案。

一个良好的娱乐之夜,让我笑到肚子疼。

中国人黑进了五角大楼的主服务器。

每个中国人都尝试过一次输入密码。

其他每个人都输入了 "毛泽东"。

在5*10^7次尝试中,服务器说密码是 "毛泽东"。

 
her.human:
目前,我认为有一条出路:捣毁服务器,直到你得到正确的答案。

愚蠢的出路。

你应该先和你的DC谈谈,了解他们支持什么类型的执行,以及什么类型的metaquot列表对应于他们的执行类型。

因为仅仅因为metaquotes想出了--3种类型的填充和3种类型的时间--这并不意味着它们是在真实经纪商上填写订单时的现实反映。

 
sergeev:

愚蠢的出路。

你应该先和你的DC谈谈。了解他们支持哪些执行类型,哪些元报价表类型与他们的执行类型相对应。

因为仅仅因为metaquotes提出了--3种类型的填充和3种类型的时间--并不意味着它们是在真实经纪商上填充订单时的现实反映。

这就是我所说的,这完全取决于服务器的设置。

但敲打每个经纪公司也是一个问题。

例如,在一个经纪公司,你可能得到一个真正的经纪订单。

但绕过一切,在你的代码中写上开关莳萝,则是矫枉过正。

如果你觉得你已经在我们这里注册了,你可以从头开始。

PS你同意正常的代码是以统一的方式写的,对于任何处理,例外都是可能的,但首先例外确认了规则,其次如果有例外,你必须写出例外。

在这里,这样的同义词变成了。

 
Urain:

这就是我的观点,这完全取决于服务器的设置。

但要敲到每家经纪公司,就会有问题。

如果你不知道这两者之间的区别,你可能会认为订单会被复制到正确的位置。

但绕过一切,在你的代码中写上开关的莳萝,就显得有些矫枉过正了。

PS你应该同意,正常的代码是以统一的方式编写的,适用于任何种类的交易。

PS你同意正常的代码是以统一的方式来写的,对于任何处理,例外都是可能的,但首先例外只能证实规则,其次如果有例外,你必须写出例外。在这里,这样的同义词变成了。

事情是这样的。

元报价被执行类型和执行时间搞乱了。它们是非标准的,因为在现实中IOC和FOK订单是指执行时间。

订单的执行类型曾经被充分地命名为AON.但后来被删除。

看一下FC使用和执行订单的FIX规范

FIX 4.4 : TimeInForce <59> field

Type: char

Used In
Description

Specifies how long the order remains in effect. Absence of this field is interpreted as DAY. NOTE not applicable to CIV Orders.

Valid values:
0 = Day (or session)
1 = Good Till Cancel (GTC)
2 = At the Opening (OPG)
3 = Immediate or Cancel (IOC)
4 = Fill or Kill (FOK)
5 = Good Till Crossing (GTX)
6 = Good Till Date
7 = At the Close

我已经标记了给自己拿元配额的类型。 但你可以看到它们都在TimeInForce 标签<59>的一个组中。

现在请告诉我,在市场上出价的经纪人将如何处理MT订单中的认沽型IOC和时间GTD。因为这是一个 领域,而不是两个不同的领域。

因此,每个经纪人会自己考虑如何处理填充物,使用什么类型,如何撤回订单。


唯一值得庆幸的是市场订单和挂单 之间的区别,即有些订单执行类型只用于挂单,有些则用于市场订单。 一般来说,我们应该关注这一点并进行讨论。


All-Or-Nothing这个名字在完全不同的标签ExecInst<18>中,它没有以任何方式在MT顺序中传递。对于FOK类型来说,它是隐含的假设(可能)。

Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5
 
sergeev:
...

请Alex接管这个话题。不幸的是,在这些问题上,我是一个漂浮者。

向SD提出建议,与他们交谈。

我们需要把这个话题放在某种顺序上。

我们现在拥有的东西根本无法用于专业编程。

 
Urain:

亚历克斯,请接手这个话题。不幸的是,我在这些问题上游刃有余。
向卫生部提出建议,与他们交谈。
我们需要把这个话题安排好。
我不确定我们现在拥有的东西是否适合于专业编程。

哈,不是我傻,就是我的滑雪板没跑。

你自己看到,每个月methaquotes都会与一个新的交易所或市场建立联系。
由此我得出结论,在这种情况下,他们的程序员对接MT和FIX是没有问题的(或在其中一个人的限制下有一些压力)。
因此,他们可以结合FOK和GTC时间类型,这意味着在可预见的未来他们不太可能改变什么,因为工作正在进行中。
同时(我理解),对于来自MT的交换桥,他们只能设置两种类型 - AON或Partial。而在MT回归中发明的--可能是去了Partial。

一般来说,FIX经纪人和MT服务器的互动问题在于经纪人的技能和理解能力,他们从MT到他们的供应商之间建立了桥梁。 我不认为metaquotes会改变什么,因为他们长期以来积极向市场推广该平台,因此MT服务器的内部结构与现实情况相当一致。