来自一个 "傻瓜 "的问题 - 页 12

[[删除]]

garanyan1985:

请告知移动电话终端的情况。

何时才能实现对mql4或mql5上的用户指示器（非标准）或顾问的支持?????????????????????????????

在哪些平台上（例如安卓）将实施?????????????????。以及多长时间?????????????

等待答复，谢谢你的提醒。

我不认为会有任何EA，至于非标准指数，请在相应的主题下查询。

[Yedelkin]

Interesting:

耶德尔金。
嗯，我不同意这个结论。OCO =="一个取消另一个"。嗯，在MT5中没有这样的事情，一个订单会取消另一个 订单。我已经后悔了一年了。SL和TP等功能确实可以关闭一个未结头寸，但 "取消 "挂单的 问题与此无关。

他们这样做，但这些命令是在服务器上实施的。而且它们是迄今为止唯一真正集成到OCO计划中的（我们不会梦想直接在终端和服务器上实现 "如果完成 "的命令）。

在MT5中开仓并设置TP和SL时，我们基本上使用相同的形式（但这里的结果是一个头寸+2个取消订单）。

在你的信息 之后，我已经对这种情况进行了评论，并考虑到SL和TP交替取消的细节。然而，在此我想补充如下。

如果OCO指令的作者被告知，在21世纪他们的发明将只适用于SL和TP水平，他们会非常惊讶地看到他们的聪明才智的应用领域受到如此大的限制:) 。事实上，一切都颠倒了：你读到的所有材料都是指同一件事：CCA订单是可交换的订单，其类型现在在MQL5 ENUM_ORDER_TYPE枚举中指定。我从未遇到过任何关于CCA订单和SL-TP水平之间的联系的说法。因此，执行机制可能是相同的，但客户执行的是ENUM_ORDER_TYPE订单，而不是SL-TP级别（根据MQ）。

所以当我写到挂单时，我指的是ENUM_ORDER_TYPE列表中的订单，而不是基于SL-TP水平的 "衍生 "订单。

______________

* "衍生物"，因为每个OCO订单可以有不同的SL-TP水平。

[Renat Fatkhullin]

先生们，理解的根源在于平台的简单性。对99%的用户来说是简单的，而对剩余比例的用户能够理解的复杂问题则是有意识的拒绝。

问自己一个问题："要怎样才能吸引X百万用户进入金融市场？有了足够的经验，答案将接近于 "做一个简单的系统，消除复杂性，将交易者团结在一个生态系统中"。

我们没有堆砌OCO订单设置（该面板确实不适合普通人的思维），而是提供了一个非常简单明了的订单管理 方案，并集成了SL/TP。绝大多数OCO订单只是当前头寸的SL/TP。通过把SL/TP放在里面，我们最大限度地减少了额外订单的数量，大大简化了交易管理。

ps：订单系统的问题已经结束

[Yedelkin]

Renat:

ps：订单系统的问题已经结束

复制品。数以百万计的人来到这里--数百万人离开。在很长一段时间内，从传统意义上讲，极少数人仍然是1%。也就是说，那些不认为CCA和If-Done是一些需要特殊心理发展的奇妙工具的人。由于这1%的人将由数以万计的 "高级 "用户组成，让我们看看 "OCO-order only forcurrent positions(SL-TP) "对他们来说是否足够，或者是否会有数百个关于这个问题的问题。现在，尽管没有大规模使用MT5，但人们已经对这个话题产生了兴趣，即使到目前为止只有少数人。

[Andrey Khatimlianskii]

Renat:

ps：订单系统的问题已经结束。

令人遗憾的是，将无法为个人交易（而不是总头寸）制定正常（可靠）的SLs/TPs。

这立即切断了在同一工具/账户上（可靠地）交易多种策略的能力。

Hali-vor不应该恢复，我记得开发人员的意见（一个工具=一个位置=一个SL和一个TP）...

[Yedelkin]

ORDER_MAGIC 实际上属于哪种类型（long或ulong）？

enum_order_property_integer

ORDER_MAGIC

下订单的专家顾问的标识符（打算让每个专家下自己的唯一编号）。

长

struct MqlTradeRequest
  {

   ...
   ulong                         magic;            // Штамп эксперта (идентификатор magic number)

   ...
  };

[[删除]]

Yedelkin:

ORDER_MAGIC 实际上属于哪种类型（long或ulong）？

enum_order_property_integer

ORDER_MAGIC

下订单的专家顾问的标识符（打算让每个专家下自己的唯一编号）。

长

我认为，结果应该转换为代码中声明的类型（文档中可能有错字）。

如果我们说的是MqlTradeRequest，在这种情况下它很可能是（ulong）。

[Yedelkin]

Interesting:

在我看来，结果应该被转换为代码中声明的类型（文档中可能有错字）。

至于MqlTradeRequest，在这种情况下，它最有可能是（ulong），但可能long也没有问题。

一般来说，答案不是最重要的。问题正是："ORDER_MAGIC 实际上 属于哪种类型（long或ulong）？

[[删除]]

Yedelkin:
一般来说，答案不在案情上。问题非常明确："ORDER_MAGIC 实际上 属于什么类型（long或ulong）？"

让我们试着做一些实质性的工作。

1.这两种类型的声明都可以不经过转换。

2.如果你只使用magik的正值，把它的值指定为ulong 更有利（因为有一个从0 到18 446 744 073 709 551 615 的可能值范围）。

3.另一方面，标准库 的CExpert 类在初始化中应用了长值（允许你指定负值，但转移了可能的值的范围）。因此，在初始化这个类时，magik的值已经可以从 -9 223 372 036 854 775 808 到9 223 372 036 854 775 808。

应检查这一声明。

4.但在CTALT 类（同一标准库）中，魔术师已经有一个值ulong，因为它应该是基于查询结构的。

让我们做一些初步的结论。

a) 在CExpert 和CTrade 类中使用magik的工作是不一致的，因为在第一种情况下指定了long，而在另一种情况下指定了ulong。

b) 有关的类是由不同的人开发的，或者CExpert 中某些函数的参数集和结构是在考虑到CTrade 的情况下编写的（过去可能存在也可能不存在）。

c) 与标准库的开发和记录有关的专家的工作并不完全连贯（尽管大多看到了对关键问题相当好的研究）。

d) 如果我理解正确的话，这两个等级的互动将魔术师的价值限制在0 到9 的范围内223 372 036 854 775 808。应检查这一声明。

5.MqlTradeRequest 结构具有ulong 类型，可以与magik一起工作。一切都与CTrade 类完全一致，这就是为什么如果我们只使用这个类，指定魔术师的可能值范围从0 到18 446 744 073 709 551 615 更符合逻辑。应检查 这一声明。

PS

我认为开发者有意将魔术师的可能数值 "钳制 "在0 到9 的范围内223 372 036 854 775 808。

[Slava]

Interesting:

开发者似乎故意将一个魔法的可能值 "塞进 "从0 到9 的范围223 372 036 854 775 808。

实际上，有多达8个字节的信息给了魔术，可以以任何方式解释。它可以是日期时间、双倍数、4个短数、8个字符或64位的逐位数。

对于四字节，4个字节的魔法足以编码任何东西，但现在我们有8个。所需要的只是意志。