有点惊讶 :)我想我应该分享并提出一个非反问的问题。 - 页 7 1234567891011121314...25 新评论 Dmitry Fedoseev 2011.03.31 08:49 #61 AlexSTAL: 问题的关键不在于测试器，同样！不在于测试器，而是在真实的条件下下载历史记录和发生连接失败。如果在真实条件下，发生了指标的重置和重新计算，这没有什么问题。另一个问题出现了。大多数人在这里不是无事可做吗？他们正在为mql5重写终端标准功能。也许，很快就会有人写一个关于mql5的完整终端。 Aleksandr Chugunov 2011.03.31 08:51 #62 Integer:如果在真实条件下，发生了指标的重置和重新计算，这没有什么问题。另一个问题出现了。大多数人在这里不是无事可做吗？他们正在为mql5重写终端标准功能。也许，很快就会有人写一个关于mql5的完整终端。当然，这也不是那么糟糕。当你在一个终端有100个ZUP时（只是举例），这不是一个问题...同样的问题出现了。每个人都喜欢只从自己的角度说话，为什么？这里使用的指标不止一个。标准IndicatorCount函数的影响对它来说简直是致命的（我亲自检查过）。而当以类的形式实现时，通信不连续的情况甚至是紫色的P.S. 对于一个MA来说，这当然不是什么大问题 Dmitry Fedoseev 2011.03.31 09:05 #63 AlexSTAL:当然，这没什么大不了的。当你在一个终端有100个ZUP时（只是给你一个例子），这没什么大不了的...同样的问题也出现了。每个人都喜欢只在自己的钟楼上争论，为什么？有人总是想要超过他们所能处理的。但为什么这么多呢？ 重置指标的问题可以通过五行代码来解决。记住第一条的时间，如果它发生了变化，你需要全面重新计算。存储最后一个柱状图的数字，在重置的情况下，从这个柱状图继续重新计算，就是这样。我不怕从我自己的钟楼说起，不需要用论据证实什么，我的钟楼是正确的，句号。 Aleksandr Chugunov 2011.03.31 09:10 #64 Integer:有人总是想要超过他们所能处理的。但为什么这么多？你可以用五行代码来解决重设指标的问题。记住第一条的时间，如果它发生了变化，需要全面重新计算。存储最后一个柱状图的数字，在重置的情况下，从这个柱状图继续重新计算，就是这样。我不怕从我的钟楼上说，不需要用论据来证实什么，我的钟楼是正确的，就是这样。不要这么自以为是。不仅要学会倾听，而且要学会倾听别人。故事可以在中间改变，而你的方法也会变得破烂不堪。关于这一点，请问雷纳特。MT4中IndicatorCounted()的错误，直到现在才通过我的提示得到修复，即使是正确书写 的指标 也会被送去报废（特别是小TF上的ZigZag）。更不用说你对这个案子的处理方法了....甚至不打算和你争论，因为你在这种情况下完全错了。 Dmitry Fedoseev 2011.03.31 09:21 #65 AlexSTAL:不要对自己太过自信。不仅要学会倾听，还要学会倾听别人。故事可以在中间发生变化，而你的方法会变成破烂。关于这一点，请问雷纳特。MT4中IndicatorCounted()的错误，直到现在才通过我的提示得到纠正，即使是正确编写的指标 也会变成垃圾（特别是小TF的ZigZag）。我甚至不打算和你争论，因为在这种情况下你完全错了。在重置时增加几个检查，是否增加了条数，但条数时间没有改变，或增加了一个以上的条数。关于自信，恰恰相反，是你们太自信了，你们是第三个认为自己比MQ更酷的人。 Aleksandr Chugunov 2011.03.31 09:29 #66 Integer:在重置时增加几个检查，是否增加了条数，但条数时间没有改变，或增加了一个以上的条数。关于自信，是反过来的，你们都是这里的过度自信者，你是第三个认为自己比MQ更酷的人。什么样的支票？情况。一个新的勾出现在旧条上。没有任何变化--既没有总条数，也没有最后一个条数的开放时间。最后30个条形图已被改写（它们的开盘/收盘价格、最大、最小都有变化，尽管变化不大）。你将用你的算法做什么？什么都没有!在这种情况下，它根本不起作用。而该指标将完全不正确!在最后一次构建之前，MT4的情况是--在70%的情况下，它不会对这种情况做出反应。但在分析了这个问题后，他们已经解决了这个问题。 Stingo写到：https://www.mql5.com/ru/forum/132422我不认为我比别人更酷。相反，我积极帮助修复MT4和MT5的所有错误--请问任何MetaQuotes代表。而事实上，一些机制并没有按照你想要的方式实施--你不可能取悦所有人....。 Новая версия MetaTrader 4 Client Terminal 392 - MQL4 форум www.mql5.com Новая версия MetaTrader 4 Client Terminal 392 - MQL4 форум Dmitry Fedoseev 2011.03.31 09:38 #67 至于什么是正确的，是之前的还是历史修正之后的，这是一个有趣的问题。如果你不回到被纠正的条形图上，指标将继续工作，就像历史上没有被纠正一样。Hrenfx正是这种态度，他认为旧的历史是正确的，你的态度则相反。也有一种观点认为，你应该只使用常规的prev_calculated，没有任何变化。如果指标很重，就限制启动时计算的条数。剩下的就是手鼓舞了，其结果是值得怀疑的。 Aleksandr Chugunov 2011.03.31 09:45 #68 Integer:至于什么是正确的，是之前的还是历史修正之后的，这是一个有趣的问题。如果你不回到被纠正的条形图，指标将继续工作，就像历史没有被纠正一样。Hrenfx正是这种态度，他认为旧的历史是正确的，你的态度则相反。还有一种观点认为，你应该只使用常规的prev_calculated，不加变化。如果指标很重，就限制启动时计算的条数。其余的是用手鼓跳舞，其结果是值得怀疑的。 每个人都为自己决定什么是正确的，什么是不正确的。对于ZigZag来说，上述情况完全是杀手锏。对于MA来说，其数值会有0.0001的偏差...意见往往可以被强加（我不是说它是错的）。一般来说，我建议在这里结束讨论。理论推理不会让你得到任何好处。 Renat Fatkhullin 2011.03.31 10:04 #69 顺便说一下，mt5在rltime中对历史基数的完整性采用了非常有效的即时控制，这增加了将prev_counted重置为零的频率。如果你不正确考虑这个计数器，并处理自己的优化，你会在实际工作中抓到很多问题。分钟历史记录的更新由服务器本身即时传递给终端。 在测试器中，指标计算的 自定义优化将完美地工作，但在客户终端可能导致不愉快的历史转移和不正确的计算。 Документация по MQL5: Основы языка / Функции / Функции обработки событий www.mql5.com Основы языка / Функции / Функции обработки событий - Документация по MQL5 Aleksandr Chugunov 2011.03.31 10:06 #70 Renat: 顺便说一下，mt5在rltime中使用了非常有效和即时的历史基础完整性控制，这增加了将prev_counted重置为零的频率。如果你不正确考虑这个计数器，并处理自己的优化，你会在实际工作中抓到很多问题。分钟历史记录的更新由服务器本身即时传递给终端。 在测试器中，指标计算的 自定义优化将完美工作，但在客户终端，历史记录会出现转移和错误的计算。这也是我的意思。也许你会考虑如何重置prev_counted，而不是将其重置为零，而是重置为第一个未改变的值？ 1234567891011121314...25 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
问题的关键不在于测试器，同样！不在于测试器，而是在真实的条件下下载历史记录和发生连接失败。
如果在真实条件下，发生了指标的重置和重新计算，这没有什么问题。
另一个问题出现了。大多数人在这里不是无事可做吗？他们正在为mql5重写终端标准功能。也许，很快就会有人写一个关于mql5的完整终端。
如果在真实条件下，发生了指标的重置和重新计算，这没有什么问题。
另一个问题出现了。大多数人在这里不是无事可做吗？他们正在为mql5重写终端标准功能。也许，很快就会有人写一个关于mql5的完整终端。
当然，这也不是那么糟糕。当你在一个终端有100个ZUP时（只是举例），这不是一个问题...
同样的问题出现了。每个人都喜欢只从自己的角度说话，为什么？
这里使用的指标不止一个。
标准IndicatorCount函数的影响对它来说简直是致命的（我亲自检查过）。而当以类的形式实现时，通信不连续的情况甚至是紫色的
P.S. 对于一个MA来说，这当然不是什么大问题
当然，这没什么大不了的。当你在一个终端有100个ZUP时（只是给你一个例子），这没什么大不了的...
同样的问题也出现了。每个人都喜欢只在自己的钟楼上争论，为什么？
有人总是想要超过他们所能处理的。但为什么这么多呢？
重置指标的问题可以通过五行代码来解决。记住第一条的时间，如果它发生了变化，你需要全面重新计算。存储最后一个柱状图的数字，在重置的情况下，从这个柱状图继续重新计算，就是这样。
我不怕从我自己的钟楼说起，不需要用论据证实什么，我的钟楼是正确的，句号。
有人总是想要超过他们所能处理的。但为什么这么多？
你可以用五行代码来解决重设指标的问题。记住第一条的时间，如果它发生了变化，需要全面重新计算。存储最后一个柱状图的数字，在重置的情况下，从这个柱状图继续重新计算，就是这样。
我不怕从我的钟楼上说，不需要用论据来证实什么，我的钟楼是正确的，就是这样。
不要这么自以为是。不仅要学会倾听，而且要学会倾听别人。
故事可以在中间改变，而你的方法也会变得破烂不堪。关于这一点，请问雷纳特。
MT4中IndicatorCounted()的错误，直到现在才通过我的提示得到修复，即使是正确书写 的指标 也会被送去报废（特别是小TF上的ZigZag）。
更不用说你对这个案子的处理方法了....
甚至不打算和你争论，因为你在这种情况下完全错了。
不要对自己太过自信。不仅要学会倾听，还要学会倾听别人。
故事可以在中间发生变化，而你的方法会变成破烂。关于这一点，请问雷纳特。
MT4中IndicatorCounted()的错误，直到现在才通过我的提示得到纠正，即使是正确编写的指标 也会变成垃圾（特别是小TF的ZigZag）。
我甚至不打算和你争论，因为在这种情况下你完全错了。
在重置时增加几个检查，是否增加了条数，但条数时间没有改变，或增加了一个以上的条数。
关于自信，恰恰相反，是你们太自信了，你们是第三个认为自己比MQ更酷的人。
在重置时增加几个检查，是否增加了条数，但条数时间没有改变，或增加了一个以上的条数。
关于自信，是反过来的，你们都是这里的过度自信者，你是第三个认为自己比MQ更酷的人。
什么样的支票？情况。一个新的勾出现在旧条上。没有任何变化--既没有总条数，也没有最后一个条数的开放时间。
最后30个条形图已被改写（它们的开盘/收盘价格、最大、最小都有变化，尽管变化不大）。
你将用你的算法做什么？什么都没有!在这种情况下，它根本不起作用。而该指标将完全不正确!
在最后一次构建之前，MT4的情况是--在70%的情况下，它不会对这种情况做出反应。
但在分析了这个问题后，他们已经解决了这个问题。 Stingo写到：https://www.mql5.com/ru/forum/132422
我不认为我比别人更酷。相反，我积极帮助修复MT4和MT5的所有错误--请问任何MetaQuotes代表。
而事实上，一些机制并没有按照你想要的方式实施--你不可能取悦所有人....。
至于什么是正确的，是之前的还是历史修正之后的，这是一个有趣的问题。如果你不回到被纠正的条形图上，指标将继续工作，就像历史上没有被纠正一样。Hrenfx正是这种态度，他认为旧的历史是正确的，你的态度则相反。
也有一种观点认为，你应该只使用常规的prev_calculated，没有任何变化。如果指标很重，就限制启动时计算的条数。剩下的就是手鼓舞了，其结果是值得怀疑的。
至于什么是正确的，是之前的还是历史修正之后的，这是一个有趣的问题。如果你不回到被纠正的条形图，指标将继续工作，就像历史没有被纠正一样。Hrenfx正是这种态度，他认为旧的历史是正确的，你的态度则相反。
还有一种观点认为，你应该只使用常规的prev_calculated，不加变化。如果指标很重，就限制启动时计算的条数。其余的是用手鼓跳舞，其结果是值得怀疑的。
每个人都为自己决定什么是正确的，什么是不正确的。对于ZigZag来说，上述情况完全是杀手锏。对于MA来说，其数值会有0.0001的偏差...
意见往往可以被强加（我不是说它是错的）。
一般来说，我建议在这里结束讨论。理论推理不会让你得到任何好处。
在测试器中，指标计算的 自定义优化将完美地工作，但在客户终端可能导致不愉快的历史转移和不正确的计算。
顺便说一下，mt5在rltime中使用了非常有效和即时的历史基础完整性控制，这增加了将prev_counted重置为零的频率。如果你不正确考虑这个计数器，并处理自己的优化，你会在实际工作中抓到很多问题。分钟历史记录的更新由服务器本身即时传递给终端。
在测试器中，指标计算的 自定义优化将完美工作，但在客户终端，历史记录会出现转移和错误的计算。
这也是我的意思。
也许你会考虑如何重置prev_counted，而不是将其重置为零，而是重置为第一个未改变的值？