开发人员!你甚至会测试你所创造的东西吗? - 页 5

 
Mikalas:

请回答2个简单的问题。

1.如果交易完成,我是否应该得到TRADE_TRANSACTION_DEAL_ADD -->ORDER_STATE_STARTED

2.在订单被修改的信息之后,TRADE_TRANSACTION_ORDER_UPDATE --> ORDER_STATE_REQUEST_MODIFY

我是否应该得到TRADE_TRANSACTION_ORDER_UPDATE --> ORDER_STATE_PLACED消息?


虽然这个问题不是给我的,但我会试着回答它:)

与事件一起工作意味着预期的事件可能不会发生,例如,你可能在运输过程中迷路,或者你可能没有排队等候,很少有事情会发生(包括终端的错误)。所以你需要对你的事件模型进行备份,以便可靠地工作。例如,我为特别重要的事件建立一个等待名单,不仅通过相关事件来控制它,还通过间接确认预期的事件已经发生。

 
Mikalas:

Artem,我不想相信你的话,但这并不是一个

是你故意为之的。事实是,目前的虫子不会

根据我的TOR,将不允许你写一个EA

现在我的专家顾问正在工作,每天带来1%的利润。

我想彻底升级它,但由于在的bug

MT-5错误不起作用。

第二,如果我们用5000欧元的存款在你的账户上进行测试,前期费用是多少?

我总是把我的初步条款。在同意我的初步条件后,我阅读了ToR,然后我说--会少花钱/会多花钱/不现实。达成协议后,我们讨论职权范围,直到最小的细节。而只有在完全相互理解之后,我们才确认我们的工作意愿。在工作中与客户紧密合作。始终保持联系。我们继续讨论和澄清算法中的每个 "齿轮"。在下一个 "齿轮 "得到磨练和测试之前,我们不会进行下一个齿轮。在通过最终解决方案之前,我自己测试算法的错误,但只在测试器中测试,而且只测试算法的正确性。在账户上进行测试--只对错误进行测试,而且只由客户进行测试,费用由他承担。

我明白,这是一场无关紧要的对话。让我们把事情做完。

 
Mikalas:

P/S 你讲什么高级语言?

我们已经开始了一场 "撒尿比赛 "吗?

我告诉你,这是个脏话。

 

下午好,尤里!

是的,当然你是对的,一个事件可能不会来一次,好比两次甚至三次。

但是,他们来了,但是其他的!

你能告诉我,你如何控制订单被修改(没有服务器的响应)?

 
artmedia70:

我们已经开始了一场 "撒尿比赛 "吗?

我的回答是--用一个脏话。

Artyom,你对问题的理解是扭曲的!

我只是想,有可能为你提供写作(而不是顾问)。

我只是想我可以提供你为广场二号写(而不是顾问)一个小终端,这将是困难的......


 
Mikalas:

Artyom,你对问题的理解是扭曲的!

我只是想,有可能提供给你写(而不是顾问)。

我只是想我可以提供给你为广场二号写一个小终端(而不是顾问),单独做会很难......


我表示歉意。我对你的理解是错误的。疲劳对我有影响--我正在处理一个复杂的订单,我不怎么睡觉....。

谢谢你的提议。我的计划有点不同。我想我还是算了吧。

 
Yurich:

虽然这个问题不是给我的,但我会试着回答它:)

与事件一起工作意味着预期的事件可能不会发生,例如,在路上迷路了,或者队列没有等待,很少有事情会发生(包括终端错误)。所以你需要对你的事件模型进行备份,以便可靠地工作。例如,我为非常重要的事件创建了等待列表,不仅通过相关的事件来控制它,而且还通过间接确认预期的事件已经发生。

不,它不起作用。事件模型 必须是绝对可靠的。如果事件没有到达那里,它就没有发生。在FORTS上,事件应该被特别清楚地执行,因为订单变化可能产生几十个交易。

Mikalas:

也谢谢你,但我想我要

"到广场二号。


我不建议这样做。用MQ修复这个错误比自己为Plaza建立一个新的终端要容易得多。陷入无休止的错误修复和编写 "标准功能 "的困境。我说的是我自己的经验。我在Stock#的基础上部分开发了这样一个自制的综合体--其结果是为特定任务提供了另一辆 "自行车"。你最好和支持服务部门打交道,这样会更容易、更便宜。
 
Mikalas:

下午好,尤里!

是的,当然你是对的,一个事件可能不会来一次,好比两次甚至三次。

但是,他们来了,但却是其他时间!

尽管如此,那一、二、三次可能发生在最不合适的时刻,这正是发生在你身上的情况。顺便说一下,《帮助》详细介绍了这一点。开发人员不建议将你的交易算法建立在等待某些交易在其他交易之后到达

一个从终端手动发送或通过OrderSend()/OrderSendAsync() 函数发送的交易请求可以在交易服务器上产生几个连续交易。这些交易到达终端的顺序是不保证的,所以我们不能把我们的交易算法建立在等待一些交易在其他交易之后的到来。此外,交易从服务器传递到终端时可能会丢失。

//---

你能告诉我,你如何控制一个订单是否被修改(没有服务器的响应)?

例如,将以前的数值与当前的数值进行比较。

 
C-4:

不,它不起作用。事件模型必须是绝对可靠的。如果事件没有到达那里,那么它就没有发生。在FORTS上,事件的执行必须特别准确,因为订单变化可能产生几十个交易。

根据定义,事件驱动模型 不可能是绝对可靠的,如果事件没有到达那里,并不意味着它没有发生。

 

tol64!

是的,它们是如何来的并不重要(尽管,"下单 "事件在先,"订单修改状态 "在后,这不符合逻辑)。

不对吗?

如果你仔细看我的图片,你会发现 "订单部分执行 "的信息来了(有两行),而不是 "订单已下达"!这是什么意思?


P/S 也不需要 "撕掉文本 "和这样开头的整句话。

知道了交易类型,你可以决定分析交易账户中订单、头寸和交易的当前状态