堡垒。执法问题 - 页 10 1...34567891011121314151617...156 新评论 Mikhail Filimonov 2015.02.10 19:09 #91 Renat:开始和结束日期的设定都应意识到错误，并有一个强制性的余地。这至少是负N秒和正N秒。TimeTradeServer()不是一个精确的时间，而是完全由进入市场概览的价格刻度来更新。 如果你在历史样本中突然没有数据，这意味着99%的错误是在查询边界。很奇怪，但在帮助中说，TimeTradeServer-返回贸易服务器的估计当前时间。but TimeCurrent() - 返回最后已知的服务器时间，在Market Watch中选择的一个符号的最后报价到达的时间。 Mikhail Filimonov 2015.02.11 16:58 #92 最后Discovery公司推出了一个演示（服务器部分1060）。雷纳特，我想祝贺你和你的团队做了一件好事。如果真的能像演示版那样工作，那就是很大的进步了！"。你是否设法解决了难以理解的单一延迟？很抱歉 "折磨 "你，但最主要的是结果! Renat Fatkhullin 2015.02.11 18:23 #93 是的，在很大程度上成功了，新的构建将在本周五发布。优化工作仍在进行中。现在我们在为微秒而战。 Mikhail Filimonov 2015.02.11 19:04 #94 Renat:是的，在很大程度上成功了，新的构建将在本周五发布。优化工作仍在进行中。现在我们在为微秒而战。很高兴听到这个消息（mks）--"灵魂的香膏" :)好运! Mikhail Filimonov 2015.02.12 17:48 #95 下午好，Renat!在servicedex中，已经有很长一段时间了（已经发布了2个新版本），我的抱怨是 "撒谎"。关于删除全局 终端变量。这个错误还没有解决。服务台没有回应。你能告诉我这个错误计划什么时候被修复吗？ Mikhail Filimonov 2015.02.17 12:43 #96 下午好，Renat!你说，在1085版本中，你修复了 "单一 "延迟的问题。但你可以从截图上看到，它不是。P/S 也许你会考虑引入一个ServerInfoInteger( SERVER_BUILD ) 函数？毕竟，这又不是什么秘密信息。 Vladimir Karputov 2015.02.17 12:50 #97 Mikalas:下午好，Renat!你说，在1085版本中，你修复了 "单一 "延迟的问题。但你可以从截图上看到，它不是。 Build 1085在你的电脑上。而服务器部分在贸易组织的什么版本，你发现了吗？还是在没有弄清楚的情况下就匆忙上阵？ Mikhail Filimonov 2015.02.17 12:51 #98 barabashkakvn: Build 1085在你的电脑上。还有，零售机构运行的服务器端是什么版本，你查到了吗？还是在没有弄清楚的情况下就匆忙上阵？亲爱的，我不是要把自己扔进战场，只是问问....。P/S 如果你不问，我们都会坐在300毫秒的延迟下--而目前是8毫秒。 Renat Fatkhullin 2015.02.17 12:55 #99 Mikalas:亲爱的，我不是要把自己扔进战场，只是问问....。P/S 如果你不问，我们都会坐在300毫秒的延迟下--而目前是8毫秒。问题是，他们的真实服务器在当日仍是1035，而演示版已移至1060。所有延迟的改善都取决于服务器基础设施，而不是客户终端。等到真正的1085版本时--你会看到惊人的改进。 Mikhail Filimonov 2015.02.17 13:00 #100 Renat:问题是，他们真正的服务器到今天为止仍然是1035，但演示已经转移到1060。所有延迟的改善都取决于服务器基础设施，而不是客户终端。等到真正的1085版本时--你会看到惊人的改进。 非常感谢您! 1...34567891011121314151617...156 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
开始和结束日期的设定都应意识到错误，并有一个强制性的余地。这至少是负N秒和正N秒。
TimeTradeServer()不是一个精确的时间，而是完全由进入市场概览的价格刻度来更新。
如果你在历史样本中突然没有数据，这意味着99%的错误是在查询边界。
很奇怪，但在帮助中说，TimeTradeServer-返回贸易服务器的估计当前时间。
but TimeCurrent() - 返回最后已知的服务器时间，在Market Watch中选择的一个符号的最后报价到达的时间。
最后Discovery公司推出了一个演示（服务器部分1060）。
雷纳特，我想祝贺你和你的团队做了一件好事。
如果真的能像演示版那样工作，那就是很大的进步了！"。
你是否设法解决了难以理解的单一延迟？
很抱歉 "折磨 "你，但最主要的是结果!
是的，在很大程度上成功了，新的构建将在本周五发布。
优化工作仍在进行中。现在我们在为微秒而战。
是的，在很大程度上成功了，新的构建将在本周五发布。
优化工作仍在进行中。现在我们在为微秒而战。
很高兴听到这个消息（mks）--"灵魂的香膏" :)
好运!
下午好，Renat!
在servicedex中，已经有很长一段时间了（已经发布了2个新版本），我的抱怨是 "撒谎"。
关于删除全局 终端变量。
这个错误还没有解决。
服务台没有回应。
你能告诉我这个错误计划什么时候被修复吗？
下午好，Renat!
你说，在1085版本中，你修复了 "单一 "延迟的问题。
但你可以从截图上看到，它不是。
P/S 也许你会考虑引入一个ServerInfoInteger( SERVER_BUILD ) 函数？
毕竟，这又不是什么秘密信息。
下午好，Renat!
你说，在1085版本中，你修复了 "单一 "延迟的问题。
但你可以从截图上看到，它不是。
Build 1085在你的电脑上。还有，零售机构运行的服务器端是什么版本，你查到了吗？还是在没有弄清楚的情况下就匆忙上阵？
亲爱的，我不是要把自己扔进战场，只是问问....。
P/S 如果你不问，我们都会坐在300毫秒的延迟下--而目前是8毫秒。
亲爱的，我不是要把自己扔进战场，只是问问....。
P/S 如果你不问，我们都会坐在300毫秒的延迟下--而目前是8毫秒。
问题是，他们的真实服务器在当日仍是1035，而演示版已移至1060。所有延迟的改善都取决于服务器基础设施，而不是客户终端。
等到真正的1085版本时--你会看到惊人的改进。
问题是，他们真正的服务器到今天为止仍然是1035，但演示已经转移到1060。所有延迟的改善都取决于服务器基础设施，而不是客户终端。
等到真正的1085版本时--你会看到惊人的改进。