对MQL5的祝愿 - 页 28

 

也许这已经说过了....

1)增加加密时的编译能力,并具有生成与计算机ID相联系的序列号的能力(类似于armandillo packer)。

所有这些都应该在翻译器内部完成,而不是从源头开始。

2) 增加与外部程序互动的可能性,允许从其他程序管理终端,连接/断开服务器,检查与服务器的连接,要求报价存档,下订单。等。

3) 可以下单,而不考虑进入的点位

4) 支持与几个DT/账户同时工作

5) 恢复DLL调试

6) 至少增加对结构的支持,一般来说,最好是扩大可能性,使其变得与C++更相似。

 

你需要为程序提供的帮助(例如,用所需的文本打开一个窗口)和网页添加一个可执行的链接。

如果用户做了一些不可理解的事情,程序会告诉他:这里有一份关于情况的咨询,请好好阅读,不要再做傻事。

[删除]  

SK。

例如,你应该设置一次TP=2和SL=10,然后只买入或卖出,也就是说,pipsing会很方便。 由于这种不便,我最近特别做了一个专家顾问,在我点击买入或卖出后,用指定的值设置TP和SL。

 

这么多的祝愿都在这里! 已经28页了!

我想听听开发商的意见,哪些愿望已经在开发中,哪些永远不会实现,哪些可能会实现。

否则就不清楚我们是否应该希望得到其他东西,没有反馈是可见的。

当然,我们也想知道时机。我明白,预测软件推出的条件有时并不比预测货币汇率的 变动容易。

至少是以这种形式。"MT5的测试版将在不早于............."。 有可能写出这样的句子吗?

 
Better:

否则,不清楚是否有其他愿望,看不到任何反馈。


好吧,该主题被修复的事实表明,开发人员认为它是有用的:)
 
是否有关于重新分配 "魔术师 "的主动命令的讨论?这个想法很简单:在多周期交易中,当出现长趋势 时,将有可能把订单传递到更高的时间框架。
 
Cronex:
是否有关于重新分配 "魔术师 "的主动命令的讨论?这个想法很简单:在多周期交易中,当出现长线趋势时,可以将订单传递到更高的时间框架
你能不能说得更具体一点?你是什么意思?
 
SK. писал (а):
Cronex:
是否有讨论过将魔术师重新分配到一个活跃的秩序中?这个想法很简单:在多周期交易中,当出现长趋势时,将有可能把订单传递到更高的时间框架
你能不能说得更具体一点?你是什么意思?

简而言之:我在4个时期使用相同的交易策略,即使用一个算法(一套指标和信号类型)的进入/退出/追踪原则,但每个时期的指标参数是不同的(实际上它们是一个图表上的4个EA),以Magic划分。结果如下:在较低的时间段,所有的迹象都表明 比市场形势真正需要的时间早得多地平仓(即任何向错误一方的摆动都会导致获利),尽管在较高的时间段,情况非常稳定。影响到指标上的相对波动性。我认为这个想法很清楚--如果在高级时间段出现稳定的情况,初级时间段的未结头寸不应关闭,但通过改变魔术,它们应该被传递到高级时间段的逻辑。该应用程序实际上不仅用于时间框架,而且用于转移到其他处理逻辑。在我看来,对经纪公司来说不会有任何问题,因为票子还在,利润也能找到。
 
Cronex:
简而言之:我在4个时期使用一个交易策略,即使用相同的算法(一套指标和信号类型)的进入/退出/追踪原则,但每个时期的指标参数是不同的(实际上它们是一个图表上的4个专家顾问),以Magic划分。结果如下:在较低的时间段,所有的迹象都表明要比市场形势真正需要的时间更早地平仓(即任何向错误方向的摆动都会导致获利),尽管在较高的时间段,情况是非常稳定。影响到指标上的相对波动性。我认为这个想法很清楚--如果在高级时间段出现稳定的情况,初级时间段的未结头寸不应关闭,但通过改变魔术,它们应该被传递到高级时间段的逻辑。该应用程序实际上不仅用于时间框架,而且用于转移到其他处理逻辑。在我看来,对特区来说不会有什么问题,因为门票留下来了,我们可能会得到一些利润。


意思很清楚。

但我不认为有必要为了这个想法而改变终端和服务器之间的语言和通信技术。毕竟,你所需要的一切都可以在终端侧的程序中得到说明。此外,改变马吉克的想法本身就雄辩地证明了战略的不完善,其标准。魔术(正如你的例子清楚地表明)没有也不可能承受一个固定的标准来关闭或打开一个订单。只是因为马吉克与市场没有任何关系。

在我看来,这是交易的关键点之一。我们手中正好有一个魔法,我们就把它绑在了一起。事实上,我们应该把每一个新的tick上的情况看作是一个新的,没有任何前史(游戏账户上的事件历史,包括开市 指令 时间和价格)。

而魔法虽然部分有用,但在我看来,并不是一个非常方便的机制来追踪......谁知道是什么。我相信,如果一个订单可以被唯一地识别(在重开和部分关闭时),神奇的标记将变得毫无意义。

 
SK. писал (а):


这一点很清楚.....

我试着做一些论证,我将从最后开始...

在我看来,如果我们接受订单是一个对象,那么从编程的角度来看,此刻的魔力是这个对象的一个完全可变的属性,也是SL或TP水平。我可能是错的,但目前在MQL中不可能清楚地识别与终端中执行的代码有关的订单,在其生命的所有可能阶段(重开和部分关闭期间),魔术在很大程度上弥补了这种情况。魔术不应依附于市场--它只是有了另一种应用,除了它的意义,没有任何意义。

我不同意你关于将市场情况视为无历史的立场......但这是我自己的看法。如果订单是有利可图的,我们应该看更高的时间框架来做决定,要么等待一个小的回撤,在更高的时间框架上继续处理这个订单,要么直接关闭它,因为它不会得到回报。

我不打算争论该战略的合理性和贫困性--我完全同意...但我正在努力工作 :-)

改变服务器和终端之间的交流语言和协议,嗯,我不知道......目前,majic值已经存在,并在下订单时被服务器接受。我不知道交换协议的格式,但我怀疑它是通过传输批量传输一些数据结构,随后进行一致性验证。我认为在OrderModify 传送的数据结构中增加一个可选参数并不难。我非常怀疑,开发者走了一条原子交换协议的道路,从而使自己陷入了沉重的版本支持过程。

但总的来说,我只是问了一下计划 :-)没有,所以没有。