从MT4转移到MT5的问题。或者，更确切地说，在MT5中无法执行某些算法而不出现错误。 - 页 7 123456789101112 新评论 Eugeni Neumoin 2019.07.30 14:42 #61 Andrey Khatimlianskii:胡说八道的是在组织你自己的数据副本，这些数据在终端已经有了。 有很多这样的胡言乱语。2005年8月MT4发布时，出现了ZigZag指标。那里有很多的错误。在一个例子中，它可以把终端挂在当时的快速市场上。而且它经常在空中显示极值，与酒吧的最低/最高值无关。 在一个帖子中，这个之字形的开发者说，这--（请不要再带着情绪）是模糊逻辑的一种表现........ 但直到现在，自MT4推出以来已经过去了14年，在之字形的指标 中，有一个参数--偏差--没有产生任何作用。也就是说，无论你设置这个参数的哪个值，图表上的人字形的绘制都不会改变。 很多项目都是基于这个指标。大多数开发人员在他们的程序中包括这个参数。这是一个无用的参数。开发商对此表现出一种奇妙的冷漠。顺便说一下，这个参数会吞噬计算机资源。 在其他各种场合也有许多这样的时刻。 Eugeni Neumoin 2019.07.30 14:52 #62 我将继续。 那些悬挂在空中的之字形极端值与我们在访问时间序列时的性质完全相同。 只是，在MT4中没有拒绝对时间序列的访问。有些功能在那里不能正常工作（也许现在仍然如此）。我有一个解释，供我自己内部使用。我自己也做了一个强迫性的。一切都开始工作，没有错误，没有CPU负载。即使在图表上输出几十个之字，也没有导致终端挂起。 Artyom Trishkin 2019.07.30 15:15 #63 Andrey Khatimlianskii: 如果一切正常，就不会有一百万个话题专门讨论这个问题。 这个逻辑只是变成了比终端用户愿意处理的更复杂。 而且肯定有错误，但开发人员没有时间去寻找它们，也没有人愿意在用户中重现和证明它们。 安德烈，我建议我们从我们拥有的东西开始。既然我们有了你所说的东西，那么是谈论它好呢，还是回避它好呢？ 我认为有足够的问题，但与其从一个分支到另一个分支地谈论它们（这也是有用的--有时它们会被修复），不如做解决的办法。 我提出了一个很好的选择--在必要的时间序列完全可用时进行缓存。然后--从准备好的、始终可用的时间序列中获取所有必要的数据。而且只用新的数据来补充。当它们可用时--慢慢地，不一定在你需要它们的时刻。 至少这样一来，事情会向前发展。而谈话可以留到以后--当没有事情可做的时候。 Artyom Trishkin 2019.07.30 15:18 #64 Eugeni Neumoin: 我将继续。 那些悬挂在空中的之字形极端值与我们在访问时间序列时的性质完全相同。 只是，在MT4中没有拒绝对时间序列的访问。有些功能在那里不能正常工作（也许现在仍然如此）。我有一个解释，供我自己内部使用。我自己也做了一个强迫性的。一切都开始工作，没有错误，没有CPU负载。即使向图表输出几十条之字形也不会导致终端挂起...。 如果对时间序列的访问被拒绝，这意味着它处于同步阶段。你需要等到下一次打勾。 在你的情况下--最好是缓存时间序列--它们总是无需等待，并且在第一次请求时就能得到。 在指标启动时进行缓存--当有时间 "等待同步 "和等待为下一个时间序列请求数据时。 Andrey Khatimlianskii 2019.07.30 15:43 #65 Artyom Trishkin: 安德烈，我的建议是，我们应该用我们所拥有的东西去做。既然我们有了你所说的东西，那么是谈论它好呢，还是绕开它好呢？ 我认为有足够的问题，但与其从一个分支到另一个分支地谈论它们（这也是有用的--有时它们会被修复），不如做解决的办法。 我提出了一个很好的选择--在需要的时间序列完全可用时进行缓存。更进一步--从准备好的、始终可用的时间序列中接收所有需要的数据。而且只用新的数据来补充。同时，当他们可以使用时--不是匆忙的，也不一定是在需要他们的时刻。 至少这样一来，事情会向前发展。而谈话可以留待以后--当没有事情可做时。 那么做一个可复制的例子让开发者来修复，已经是更有效了。 Eugeni Neumoin 2019.07.30 16:09 #66 Artyom Trishkin: 安德烈，我建议我们应该用我们拥有的东西去做。既然我们有了你所说的东西，那么是谈论它好呢，还是绕开它好呢？ 我认为有足够的问题，但与其从一个分支到另一个分支地谈论它们（这也很有用--有时它们会被修复），不如去做解决的办法。 我提出了一个很好的选择--在必要的时间序列完全可用时进行缓存。然后从准备好的、始终可用的时间序列中接收所有需要的数据。而且只用新的数据来补充。同时，当他们可以使用时--不是匆忙的，也不一定是在需要他们的时刻。 至少这样一来，事情会向前发展。而谈话可以留待以后--当没有事情可做时。 而终端的开发者为什么不能这样做呢？反正在更新的时候，也没有机会接触到时间序列。让每个人都能访问这个，比方说，缓存的历史。这有什么区别呢？也就是说，这样就不会出现访问中断的情况。好吧，也许在零点酒吧会有一些延迟。其余的历史将始终可用。 Igor Makanu 2019.07.30 16:12 #67 Artyom Trishkin: 我提出了一个很好的选择--在需要的时间序列完全可用的时候进行缓存。然后--从准备好的、始终可用的时间序列中获取所有必要的数据。而且只用新的数据来补充。 这是一个糟糕的变体，你必须完全重复在终端建立和同步时间序列的逻辑--一个新的刻度出现了，同步没有完成......然后是连接失败。 ZS：是的，为什么要这样做？- 我不知道生活中有多少，我有一部手机，一辆车，甚至钱包也只有一个，但生活中却有很多情况？- 需要保险吗？.... "三台录音机，三台外国胶片相机，三个烟盒国内，夹克......麂皮......三个。外套" )) 阿尔乔姆-特里什金。 如果对时间序列的访问被拒绝，这意味着它是同步的。你必须等到下一次打勾。 你是对的！但有必要在任何地方停止MQL程序，并退出终端，直到下一个刻度......我定期建议像Delphi中的 "Abort()或Halt()"--得到一次时间序列访问错误--这是一个关键错误，多次处理没有意义--反正，直到终端不能调整与MQL程序的互动，"它没有用"））。 SZZ：这个错误（时序访问错误）不是我创造的--它是由终端创造的，但所有的MQL程序员都应该准备好调试终端产生的错误......（当代码由几百行组成时），这很容易玩，但当代码很大，而且从不同的程序部分使用时序访问很方便时--它需要999种方法从任何部分退出，并且不丢失以前的计算结果？- 是的，这是可能的，但它需要一个明确的计划（算法），通过它来编写源代码......。如果通过添加现成的函数（类）来完善源代码呢？- 也就是说，每次你都要弄清楚里面的东西...对于大型项目来说，提供所有的东西通常是一项耗时的任务，我认为 Eugeni Neumoin 2019.07.30 17:07 #68 Igor Makanu:...对于大型项目来说，这是一项耗时的工作，我认为 如果一个程序已经创建了14年，用新的设计方法来翻译它，比自寻死路要容易。而且调试多个链接也很困难。检查时间框架的可及性，如果没有可及性，就会出现严重的延误。如果能启用自动图形构造 就好了。自动模式下的重建是一种不常见的现象。你甚至可能不会注意到这里的延迟。但在这种情况下，当对时间序列的访问被中断时，图形结构有时会以截断的形式输出。有些元素有时间建立，有些则没有。或者说，分形过滤将图形截断于某个tf。 *** Igor Makanu 2019.07.30 17:21 #69 Eugeni Neumoin: 如果一个程序已经创建了14年，用新的设计方法来翻译它，比自寻死路要容易。而且调试多个链接也很困难。检查时间框架的可及性，如果没有可及性，就会出现严重的延误。如果能启用自动图形构造 就好了。自动模式下的重建是一种不常见的现象。你甚至可能不会注意到这里的延迟。 但问题是当调整是通过图形界面进行的。用户按下按钮，...必须等待下一次打勾。或者用户多次按动按钮，直到出现所需的反应。用户的反应是什么...？-*** 而在MT4中不存在这样的问题。 我非常理解你，所以我决定支持讨论 iClose()...iXXX()函数来访问时间序列--很好! 或者U.V.开发人员应该添加预编译器指令，只有当终端准备好访问历史数据（OHLC）时，才会给MQL-程序打勾，否则就不打勾。 .... 但唯一的目的是摆脱无休止的OHLC图表准备情况检查，自从MT5出现以来，这个问题只在MQL程序内部的检查层面得到了解决，这是一个耗时的过程，在我看来，用户希望终端在任何时候，在任何代码部分都能毫无问题地接收时间序列数据，并得到保证。 Artyom Trishkin 2019.07.30 17:30 #70 Igor Makanu: 这是一个糟糕的选择，你需要完全重复在终端建立和同步时间序列的逻辑--然后一个新的刻度出现，然后同步没有结束......然后连接失败 ZS：是的，为什么要这样做？- 我不知道生活中有多少，我有一部手机，一辆车，甚至钱包也只有一个，但生活中却有很多情况？- 需要保险吗？.... "三台录音机，三台外国胶片相机，三个烟盒国内，夹克......麂皮......三个。外套" )) 好吧！但MQL程序必须在任何地方停止计算，并退出终端，直到下一个刻度......我偶尔会建议像Delphi中的 "Abort()或Halt()"--你有一个访问时间序列的错误--这是一个关键错误，多次处理都没有意义--反正，直到终端与MQL程序建立互动，都没有用）））。 SZZ：这个错误（时序访问错误）不是我创造的--它是由终端创造的，但所有的MQL程序员都应该准备好调试终端产生的错误......（当代码由几百行组成时），这很容易玩，但当代码很大，而且从不同的程序部分使用时序访问很方便时--它需要999种方法从任何部分退出，并且不丢失以前的计算结果？- 是的，这是可能的，但它需要一个明确的计划（算法），通过它来编写源代码......。如果通过添加现成的函数（类）来完善源代码呢？- 也就是说，每次你都要弄清楚里面的东西......大项目的耗时任务，我认为 如果程序是由鼠标点击执行的，那么是否有访问权限并不重要，你必须做出反应。你可以写很多关于一切都做得很糟糕的东西，但在这种情况下，最好是有自己的缓存，你可以随时从那里按需访问。 试想一下，这个程序不是通过鼠标点击给出长期计算的历史数据，而是说--去抽根烟--我得到当前的数据，你现在不需要，并重建时间序列。 无论怎样，如果你必须用你所拥有的东西来做，最好是把缓存中的东西发出去，然后在解锁时间序列访问后再重建它。 123456789101112 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
胡说八道的是在组织你自己的数据副本，这些数据在终端已经有了。
有很多这样的胡言乱语。2005年8月MT4发布时，出现了ZigZag指标。那里有很多的错误。在一个例子中，它可以把终端挂在当时的快速市场上。而且它经常在空中显示极值，与酒吧的最低/最高值无关。
在一个帖子中，这个之字形的开发者说，这--（请不要再带着情绪）是模糊逻辑的一种表现........
但直到现在，自MT4推出以来已经过去了14年，在之字形的指标 中，有一个参数--偏差--没有产生任何作用。也就是说，无论你设置这个参数的哪个值，图表上的人字形的绘制都不会改变。
很多项目都是基于这个指标。大多数开发人员在他们的程序中包括这个参数。这是一个无用的参数。开发商对此表现出一种奇妙的冷漠。顺便说一下，这个参数会吞噬计算机资源。
在其他各种场合也有许多这样的时刻。
我将继续。
那些悬挂在空中的之字形极端值与我们在访问时间序列时的性质完全相同。
只是，在MT4中没有拒绝对时间序列的访问。有些功能在那里不能正常工作（也许现在仍然如此）。我有一个解释，供我自己内部使用。我自己也做了一个强迫性的。一切都开始工作，没有错误，没有CPU负载。即使在图表上输出几十个之字，也没有导致终端挂起。
如果一切正常，就不会有一百万个话题专门讨论这个问题。
这个逻辑只是变成了比终端用户愿意处理的更复杂。
而且肯定有错误，但开发人员没有时间去寻找它们，也没有人愿意在用户中重现和证明它们。
安德烈，我建议我们从我们拥有的东西开始。既然我们有了你所说的东西，那么是谈论它好呢，还是回避它好呢？
我认为有足够的问题，但与其从一个分支到另一个分支地谈论它们（这也是有用的--有时它们会被修复），不如做解决的办法。
我提出了一个很好的选择--在必要的时间序列完全可用时进行缓存。然后--从准备好的、始终可用的时间序列中获取所有必要的数据。而且只用新的数据来补充。当它们可用时--慢慢地，不一定在你需要它们的时刻。
至少这样一来，事情会向前发展。而谈话可以留到以后--当没有事情可做的时候。
我将继续。
那些悬挂在空中的之字形极端值与我们在访问时间序列时的性质完全相同。
只是，在MT4中没有拒绝对时间序列的访问。有些功能在那里不能正常工作（也许现在仍然如此）。我有一个解释，供我自己内部使用。我自己也做了一个强迫性的。一切都开始工作，没有错误，没有CPU负载。即使向图表输出几十条之字形也不会导致终端挂起...。
如果对时间序列的访问被拒绝，这意味着它处于同步阶段。你需要等到下一次打勾。
在你的情况下--最好是缓存时间序列--它们总是无需等待，并且在第一次请求时就能得到。
在指标启动时进行缓存--当有时间 "等待同步 "和等待为下一个时间序列请求数据时。
安德烈，我的建议是，我们应该用我们所拥有的东西去做。既然我们有了你所说的东西，那么是谈论它好呢，还是绕开它好呢？
我认为有足够的问题，但与其从一个分支到另一个分支地谈论它们（这也是有用的--有时它们会被修复），不如做解决的办法。
我提出了一个很好的选择--在需要的时间序列完全可用时进行缓存。更进一步--从准备好的、始终可用的时间序列中接收所有需要的数据。而且只用新的数据来补充。同时，当他们可以使用时--不是匆忙的，也不一定是在需要他们的时刻。
至少这样一来，事情会向前发展。而谈话可以留待以后--当没有事情可做时。
那么做一个可复制的例子让开发者来修复，已经是更有效了。
安德烈，我建议我们应该用我们拥有的东西去做。既然我们有了你所说的东西，那么是谈论它好呢，还是绕开它好呢？
我认为有足够的问题，但与其从一个分支到另一个分支地谈论它们（这也很有用--有时它们会被修复），不如去做解决的办法。
我提出了一个很好的选择--在必要的时间序列完全可用时进行缓存。然后从准备好的、始终可用的时间序列中接收所有需要的数据。而且只用新的数据来补充。同时，当他们可以使用时--不是匆忙的，也不一定是在需要他们的时刻。
至少这样一来，事情会向前发展。而谈话可以留待以后--当没有事情可做时。
而终端的开发者为什么不能这样做呢？反正在更新的时候，也没有机会接触到时间序列。让每个人都能访问这个，比方说，缓存的历史。这有什么区别呢？也就是说，这样就不会出现访问中断的情况。好吧，也许在零点酒吧会有一些延迟。其余的历史将始终可用。
我提出了一个很好的选择--在需要的时间序列完全可用的时候进行缓存。然后--从准备好的、始终可用的时间序列中获取所有必要的数据。而且只用新的数据来补充。
这是一个糟糕的变体，你必须完全重复在终端建立和同步时间序列的逻辑--一个新的刻度出现了，同步没有完成......然后是连接失败。
ZS：是的，为什么要这样做？- 我不知道生活中有多少，我有一部手机，一辆车，甚至钱包也只有一个，但生活中却有很多情况？- 需要保险吗？.... "三台录音机，三台外国胶片相机，三个烟盒国内，夹克......麂皮......三个。外套" ))
如果对时间序列的访问被拒绝，这意味着它是同步的。你必须等到下一次打勾。
你是对的！但有必要在任何地方停止MQL程序，并退出终端，直到下一个刻度......我定期建议像Delphi中的 "Abort()或Halt()"--得到一次时间序列访问错误--这是一个关键错误，多次处理没有意义--反正，直到终端不能调整与MQL程序的互动，"它没有用"））。
SZZ：这个错误（时序访问错误）不是我创造的--它是由终端创造的，但所有的MQL程序员都应该准备好调试终端产生的错误......（当代码由几百行组成时），这很容易玩，但当代码很大，而且从不同的程序部分使用时序访问很方便时--它需要999种方法从任何部分退出，并且不丢失以前的计算结果？- 是的，这是可能的，但它需要一个明确的计划（算法），通过它来编写源代码......。如果通过添加现成的函数（类）来完善源代码呢？- 也就是说，每次你都要弄清楚里面的东西...对于大型项目来说，提供所有的东西通常是一项耗时的任务，我认为
如果一个程序已经创建了14年，用新的设计方法来翻译它，比自寻死路要容易。而且调试多个链接也很困难。检查时间框架的可及性，如果没有可及性，就会出现严重的延误。如果能启用自动图形构造 就好了。自动模式下的重建是一种不常见的现象。你甚至可能不会注意到这里的延迟。但在这种情况下，当对时间序列的访问被中断时，图形结构有时会以截断的形式输出。有些元素有时间建立，有些则没有。或者说，分形过滤将图形截断于某个tf。
***
如果一个程序已经创建了14年，用新的设计方法来翻译它，比自寻死路要容易。而且调试多个链接也很困难。检查时间框架的可及性，如果没有可及性，就会出现严重的延误。如果能启用自动图形构造 就好了。自动模式下的重建是一种不常见的现象。你甚至可能不会注意到这里的延迟。
但问题是当调整是通过图形界面进行的。用户按下按钮，...必须等待下一次打勾。或者用户多次按动按钮，直到出现所需的反应。用户的反应是什么...？-***
而在MT4中不存在这样的问题。
我非常理解你，所以我决定支持讨论
iClose()...iXXX()函数来访问时间序列--很好!
或者U.V.开发人员应该添加预编译器指令，只有当终端准备好访问历史数据（OHLC）时，才会给MQL-程序打勾，否则就不打勾。
....
但唯一的目的是摆脱无休止的OHLC图表准备情况检查，自从MT5出现以来，这个问题只在MQL程序内部的检查层面得到了解决，这是一个耗时的过程，在我看来，用户希望终端在任何时候，在任何代码部分都能毫无问题地接收时间序列数据，并得到保证。
这是一个糟糕的选择，你需要完全重复在终端建立和同步时间序列的逻辑--然后一个新的刻度出现，然后同步没有结束......然后连接失败
ZS：是的，为什么要这样做？- 我不知道生活中有多少，我有一部手机，一辆车，甚至钱包也只有一个，但生活中却有很多情况？- 需要保险吗？.... "三台录音机，三台外国胶片相机，三个烟盒国内，夹克......麂皮......三个。外套" ))
好吧！但MQL程序必须在任何地方停止计算，并退出终端，直到下一个刻度......我偶尔会建议像Delphi中的 "Abort()或Halt()"--你有一个访问时间序列的错误--这是一个关键错误，多次处理都没有意义--反正，直到终端与MQL程序建立互动，都没有用）））。
SZZ：这个错误（时序访问错误）不是我创造的--它是由终端创造的，但所有的MQL程序员都应该准备好调试终端产生的错误......（当代码由几百行组成时），这很容易玩，但当代码很大，而且从不同的程序部分使用时序访问很方便时--它需要999种方法从任何部分退出，并且不丢失以前的计算结果？- 是的，这是可能的，但它需要一个明确的计划（算法），通过它来编写源代码......。如果通过添加现成的函数（类）来完善源代码呢？- 也就是说，每次你都要弄清楚里面的东西......大项目的耗时任务，我认为
如果程序是由鼠标点击执行的，那么是否有访问权限并不重要，你必须做出反应。你可以写很多关于一切都做得很糟糕的东西，但在这种情况下，最好是有自己的缓存，你可以随时从那里按需访问。
试想一下，这个程序不是通过鼠标点击给出长期计算的历史数据，而是说--去抽根烟--我得到当前的数据，你现在不需要，并重建时间序列。
无论怎样，如果你必须用你所拥有的东西来做，最好是把缓存中的东西发出去，然后在解锁时间序列访问后再重建它。