错误、漏洞、问题 - 页 3121 1...311431153116311731183119312031213122312331243125312631273128...3184 新评论 Alexey Viktorov 2021.12.18 06:10 #31201 x572intraday #: 如果你知道，请告诉我。如果你把现有代码的新版本上传到CodeBase，对以前的开发者来说，禁止再次投票的规定是否会被重置，他们将可以再次为新版本投票？我自己也非常怀疑，但如果有可能的话，重新设置以前的评级，以取代新的评级（假设应该不低于以前的评级）是公平的，因为代码在发展，新的版本可能会在更大程度上满足投票人的要求，而旧的代码的旧评级将变得无效。(的确，随着功能的增长，代码也在增长，所以可能会有新的错误和故障，甚至更麻烦。任何事情都可能发生...而新的分数可能会更低，但这对我来说很好）。 不要再为你的......代码的低评级而撕扯你的头发了。如果一个人给你的代码打了1分，并不意味着它就是这样的。好吧，至少重写100次......而且这100次的代码都会被这样评价。这有那么难理解吗？ x572intraday 2021.12.18 10:25 #31202 Alexey Viktorov #:不要再为你的......代码的低评级而撕扯你的头发了。如果一个人给你的代码打了1分，并不意味着它就是这样的。好吧，至少重做100次......而且这100次的代码都会被这样评价。这有那么难理解吗？ 也许你的简历反映了投票的现实，这很可悲。但我不是为自己难过--那些虚拟的星星不能用茶来喝，也不能放进我的钱包，我对产品呈现给新用户的方式的概念感到沮丧，特别担心他们。如果没有可靠的评级/评分，用户根本无法根据 "按评级排序 "的标准有效搜索他们想要的产品。事实证明，评级系统是一个空洞的系统，人们只能通过名称/描述来寻找合适的产品，而不是相信无用的星数。否则他们就会一直捞东西......漂浮在表面上的东西（不管是否应该），而他们真正需要的东西会被忽略掉。我只是建议，应该把这一点改得更周到。但如果没有人要与这个现实作斗争，我就洗手不干了。 Vitaly Muzichenko 2021.12.18 11:40 #31203 x572intraday #:你的总结可能反映了投票的现实，这让人失望。但我难过的不是我--那些虚拟的星星不能用茶来喝，也不能放在我的钱包里，我失望的是产品呈现给新用户的概念，担心的正是他们。如果没有可信的评级/评分，用户根本无法根据 "按评级排序 "的标准有效地搜索到他们想要的产品。事实证明，评级系统是一个空洞的系统，人们只能通过名称/描述来寻找合适的产品，而不是相信无用的星数。否则他们就会一直捞东西......漂浮在表面上的东西（不管是否应该），而他们真正需要的东西会被忽略掉。我只是建议，应该把这一点改得更周到。但如果没有人要与这个现实作斗争，我就洗手不干了。 让我们看一下你的代码。 int calculated=iBars(_Symbol,PArray[0]); if(calculated<=0) return(0); if(!GlobalVariableGet(_Symbol+": PSR_bars_calculated") || calculated!=GlobalVariableGet(_Symbol+": PSR_bars_calculated") || calculated>GlobalVariableGet(_Symbol+": PSR_bars_calculated")+1) { if(!GlobalVariableGet(_Symbol+": PSR_SingleActuation") || (GlobalVariableGet(_Symbol+": PSR_SingleActuation") && calculated!=GlobalVariableGet(_Symbol+": PSR_bars_calculated"))) { for(int p=0; p<ArraySize(PArray); p++) { 每次打勾都会触发对全局变量的访问，每次有4个请求。 由此可见，你不能在你的个人机器上使用这段代码，你可以在其他地方使用它，在那里你不会放过你的硬盘驱动器。 在一个循环中，在搜索过程中应该调用3次ArraySize，而其中有两个，这是对处理器的额外负载，这也是不可取的，代码性能下降。 DeInite删除对象的方式很奇怪，这里没有什么问题，但对初学者来说是个不好的例子，如果你正常操作，应该在创建对象时输入一个前缀，然后删除它们，不需要过多的重新 计算。 我给你的代码打2分。 对于指标的工作--我不知道，我没有运行它。 目标是什么？ x572intraday 2021.12.18 12:49 #31204 Vitaly Muzichenko #:好吧，让我们看一下你的代码。在每次打勾时都会触发对全局变量的访问，每次有4个请求由此可见，你不能在你的个人机器上使用这段代码，你可以在其他地方使用它，在那里你不会放过你的硬盘驱动器。在一个循环中，在搜索过程中应该调用3次ArraySize，而其中有两个，这是对处理器的额外负载，这也是不可取的，代码性能下降。DeInite删除对象的方式很奇怪，这里没有什么问题，但对初学者来说是个不好的例子，如果你正常操作，应该在创建对象时输入一个前缀，然后删除它们，不需要过多的重新 计算。 我给你的代码打2分。对于指标的工作--我不知道，我没有运行它。目标是什么？ 1.在每个tick上都有对GP的调用，因此在每个tick上，以及在每次重新初始化时（例如，通过TFs的过渡），OnCalculate() 中的主要和较重的代码不会被执行，指标工作得更快。新数据的计算--只有在出现新的低杠D1 的情况下，才会出现新的低杠，这要比在每个tick上都要稀少得多。 2.我对代码进行了深思熟虑的处理，但我在if() 中留下了一些不必要的比较操作，因为我确信这不会影响性能。 3.关于MUST的不是，它被大大地夸大了。你可以下载它，自己看看：指标飞起来了。 4.我不知道GP被下载到AF，然后在运行中的MT5 会话中每次访问它们时从同一位置读取。我仍然认为，当我启动终端并住在那里时，它们被从LCD中读到RAM中一次，而指示器在RAM中访问它们，而不是到LCD中。 5.我不认为ArraySize() 是一个昂贵的函数。而且，即使它很贵，在这个特定的代码中你也不会注意到它。我可能会在我的第一个指标中优化这个功能，因为它的使用频率很高，而指标本身则要复杂得多，资源也很密集。 6.在OnDeinit()中，我使用。 ObjectsDeleteAll(0,StringSubstr(EnumToString(PArray[p]),7)+" "+line_types[lt]+" l",0,-1); 其中只有 "l "的前缀被移除（创建对象时使用了 "标签"和 "线"的名称）。 7.你现在已经做了一个已经下载并理解了代码的用户应该做的事情。你已经发现了缺陷--这也是学习MQL 的一部分。 8.底线：1.) 我对这个指标的非理想代码的主要论点 - 简单、紧凑和速度...加上完美的工作；2.）我对不完美代码的第二个主要论点--在速度和通用性方面缺乏甚至不好的类似物（见对他人原作的讨论），以及与原作相比有无改进，顺便说一下，原作很窄，在大量类似的重复块方面没有被折叠成紧凑的循环。 9.尽管有第7点，你并没有真正理解别人的代码。你的分数是2分，太低了。我还不建议你通过代码来评估软件产品。我不会说什么客观性，因为不可能期待任何一个用户的客观性。一个客观的估计（评级）只有作为几个理智的用户的估计的总和才有可能，当然它不一定要高。 Errors, bugs, questions Signal sort request, trading [解决]当从不同工作时间段的指标中调用/创建指标时，指标不能正确实例化。 Vitaly Muzichenko 2021.12.18 13:26 #31205 x572intraday #:1.在每一个tick都有一个对GP的引用，这样在每一个tick，以及每一次重新初始化（例如，通过TFs的过渡），OnCalculate() 中的整个主代码和重代码都不会被执行，指标工作得更快。新数据的计算--只有在出现新的低杠D1 的情况下，才会出现新的低杠，这要比在每个tick上都要稀少得多。2.我对代码进行了深思熟虑的处理，但我在if() 中留下了一些多余的比较操作，因为我确信这不会影响性能。3.关于MUST--被大大夸大了。你可以下载并亲眼看到该指标的飞行。4.我不知道GP会被转储到HDD，然后在运行中的MT5 会话中每次访问时从那里读取。我仍然认为，当我启动终端时，它们被从HD读到RAM中一次，并住在那里，指标在RAM中访问它们，而不是到HD中。5.我不认为ArraySize() 是一个昂贵的函数。而且，即使它很贵，在这个特定的代码中你也不会注意到它。我可能会在我的第一个指标中优化这个功能，因为它的使用频率很高，而指标本身则要复杂得多，资源也很密集。6.在OnDeinit()中，我使用。其中只有 "l "的前缀被移除（创建对象时使用了 "标签"和 "线"的名称）。7.你现在已经做了一个已经下载并理解了代码的用户应该做的事情。你已经发现了缺陷--这也是学习MQL 的一部分。8.底线：1.) 我对这个指标的非理想代码的主要论点 - 简单、紧凑和速度...2.）我对不完美代码的第二个主要论点--在速度和通用性方面没有类似物（见对别人的原创的讨论），以及与原创相比有无改进，顺便说一下，它很窄，在大量类似重复的块方面没有折叠成紧凑的循环。9.尽管有第7点，你并没有真正理解别人的代码。你的分数是2分，太低了。我还不建议你通过代码来评估软件产品。我不会说什么客观性，因为不可能期待任何一个用户的客观性。一个客观的估计（评级）只可能是一些理智的用户的估计之和，它不一定要高。 按前缀删除的方法如下：ObjectsDeleteAll(0, "pref_"); //"pref_label" 和 "pref_line" 至少在OnCalculate中添加第一行，以便在一个新的条形图上寻址，而不是像现在这样在每个tick上寻址。 x572intraday 2021.12.18 13:35 #31206 Vitaly Muzichenko #:按前缀删除，就像这样：ObjectsDeleteAll(0, "pref_"); //"pref_label" 和 "pref_line" 至少在OnCalculate中增加第一行，以便在一个新的条形图上进行引用，而不是像现在这样在每个tick上进行引用 顺便说一下，关于第7点：我甚至在MQL5 文档中也遇到过错误，这些错误多年来都没有得到纠正。 x572intraday 2021.12.18 13:49 #31207 Vitaly Muzichenko #:按前缀删除是这样的：ObjectsDeleteAll(0, "pref_"); //"pref_label" 和 "pref_line" 按照你的建议删除它是不合理的，因为前缀的开头是动态的：要么是{D1}，要么 是{W1}，要么是{MN1}，然后是一个不可改变的前缀，如 "l..."。你可以根据你的版本互换动态和静态前缀，并安全地删除它们。 但这是不合理的，因为以 "R1{D1}"作为信息是不方便 的，而使用"{D1}R1 "则更方便。我很久以前就想清楚了，并且完全按照我的做法去做。 Vitaly Muzichenko 2021.12.18 14:01 #31208 x572intraday #:没有合理的方法可以按照你的建议删除它，因为前缀的开头是动态的：要么是{D1}， 要么是{W1}，要么是{MN1}，然后还有一个不可改变的前缀为 "l..."。你可以互换动态和静态前缀，并根据你的版本安全地删除它们。 但这是不合理的，因为将信息作为 "R1{D1}"很不方便，而使用"{D1}R1 "会更方便。我很久以前就想清楚了，并且完全按照我的做法去做。 DrawTheLine("pref"+line_types[lt], St x572intraday 2021.12.18 14:57 #31209 Vitaly Muzichenko #: 不过，是的，原则上你可以这么做。我在上面潇洒地解释了自己，当时想的是。ObjectSetString(0,tf+" "+LineType+" label",OBJPROP_TEXT,"{"+tf+"} "+LineType);不是关于对象的名称。图表完全读取用OBJPROP_TEXT 设置的标签，但对象名称可以用不太容易阅读的方式签名，因为它们是隐藏的，很少被读取。另一方面，在 "对象的清单 "中(Ctrl+b)可以更好地看到可读的对象名称，所以我的方法更可取。此外，在有些情况下，对象名称必须非常长，所以额外的"pref_"是完全不能接受的。 Vitaly Muzichenko 2021.12.18 15:40 #31210 x572intraday #:不过，是的，原则上你可以这么做。我在上面潇洒地解释了自己，当时想的是。不是关于对象的名称。图表中读取的正是用OBJPROP_TEXT 设置的标签，但对象名称的签名可能不太清晰，因为它们是隐藏的，很少被读取。另一方面，在 "对象的清单 "中(Ctrl+b)，最好能看到可读的对象名称，所以我的方法还是比较好的。除此之外，有些情况下，对象的名字必须非常长，所以额外的"pref_"将是完全不可接受 的。 如果有人将仍然有一个程序与图形对象，你的那种前缀 "l"<其中只是删除前缀 "l"（名称 "标签"和 "线"被使用时，对象被创建>。 将杀死第三方程序中 所有以"l " 开头的对象。这不是一个好的解决方案 1...311431153116311731183119312031213122312331243125312631273128...3184 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
如果你知道，请告诉我。如果你把现有代码的新版本上传到CodeBase，对以前的开发者来说，禁止再次投票的规定是否会被重置，他们将可以再次为新版本投票？我自己也非常怀疑，但如果有可能的话，重新设置以前的评级，以取代新的评级（假设应该不低于以前的评级）是公平的，因为代码在发展，新的版本可能会在更大程度上满足投票人的要求，而旧的代码的旧评级将变得无效。(的确，随着功能的增长，代码也在增长，所以可能会有新的错误和故障，甚至更麻烦。任何事情都可能发生...而新的分数可能会更低，但这对我来说很好）。
不要再为你的......代码的低评级而撕扯你的头发了。如果一个人给你的代码打了1分，并不意味着它就是这样的。好吧，至少重写100次......而且这100次的代码都会被这样评价。这有那么难理解吗？
不要再为你的......代码的低评级而撕扯你的头发了。如果一个人给你的代码打了1分，并不意味着它就是这样的。好吧，至少重做100次......而且这100次的代码都会被这样评价。这有那么难理解吗？
也许你的简历反映了投票的现实，这很可悲。但我不是为自己难过--那些虚拟的星星不能用茶来喝，也不能放进我的钱包，我对产品呈现给新用户的方式的概念感到沮丧，特别担心他们。如果没有可靠的评级/评分，用户根本无法根据 "按评级排序 "的标准有效搜索他们想要的产品。事实证明，评级系统是一个空洞的系统，人们只能通过名称/描述来寻找合适的产品，而不是相信无用的星数。否则他们就会一直捞东西......漂浮在表面上的东西（不管是否应该），而他们真正需要的东西会被忽略掉。我只是建议，应该把这一点改得更周到。但如果没有人要与这个现实作斗争，我就洗手不干了。
你的总结可能反映了投票的现实，这让人失望。但我难过的不是我--那些虚拟的星星不能用茶来喝，也不能放在我的钱包里，我失望的是产品呈现给新用户的概念，担心的正是他们。如果没有可信的评级/评分，用户根本无法根据 "按评级排序 "的标准有效地搜索到他们想要的产品。事实证明，评级系统是一个空洞的系统，人们只能通过名称/描述来寻找合适的产品，而不是相信无用的星数。否则他们就会一直捞东西......漂浮在表面上的东西（不管是否应该），而他们真正需要的东西会被忽略掉。我只是建议，应该把这一点改得更周到。但如果没有人要与这个现实作斗争，我就洗手不干了。
让我们看一下你的代码。
每次打勾都会触发对全局变量的访问，每次有4个请求。
由此可见，你不能在你的个人机器上使用这段代码，你可以在其他地方使用它，在那里你不会放过你的硬盘驱动器。
在一个循环中，在搜索过程中应该调用3次ArraySize，而其中有两个，这是对处理器的额外负载，这也是不可取的，代码性能下降。
DeInite删除对象的方式很奇怪，这里没有什么问题，但对初学者来说是个不好的例子，如果你正常操作，应该在创建对象时输入一个前缀，然后删除它们，不需要过多的重新 计算。
我给你的代码打2分。
对于指标的工作--我不知道，我没有运行它。
目标是什么？
好吧，让我们看一下你的代码。
在每次打勾时都会触发对全局变量的访问，每次有4个请求
由此可见，你不能在你的个人机器上使用这段代码，你可以在其他地方使用它，在那里你不会放过你的硬盘驱动器。
在一个循环中，在搜索过程中应该调用3次ArraySize，而其中有两个，这是对处理器的额外负载，这也是不可取的，代码性能下降。
DeInite删除对象的方式很奇怪，这里没有什么问题，但对初学者来说是个不好的例子，如果你正常操作，应该在创建对象时输入一个前缀，然后删除它们，不需要过多的重新 计算。
我给你的代码打2分。
对于指标的工作--我不知道，我没有运行它。
目标是什么？
1.在每个tick上都有对GP的调用，因此在每个tick上，以及在每次重新初始化时（例如，通过TFs的过渡），OnCalculate() 中的主要和较重的代码不会被执行，指标工作得更快。新数据的计算--只有在出现新的低杠D1 的情况下，才会出现新的低杠，这要比在每个tick上都要稀少得多。
2.我对代码进行了深思熟虑的处理，但我在if() 中留下了一些不必要的比较操作，因为我确信这不会影响性能。
3.关于MUST的不是，它被大大地夸大了。你可以下载它，自己看看：指标飞起来了。
4.我不知道GP被下载到AF，然后在运行中的MT5 会话中每次访问它们时从同一位置读取。我仍然认为，当我启动终端并住在那里时，它们被从LCD中读到RAM中一次，而指示器在RAM中访问它们，而不是到LCD中。
5.我不认为ArraySize() 是一个昂贵的函数。而且，即使它很贵，在这个特定的代码中你也不会注意到它。我可能会在我的第一个指标中优化这个功能，因为它的使用频率很高，而指标本身则要复杂得多，资源也很密集。
6.在OnDeinit()中，我使用。
其中只有 "l "的前缀被移除（创建对象时使用了 "标签"和 "线"的名称）。
7.你现在已经做了一个已经下载并理解了代码的用户应该做的事情。你已经发现了缺陷--这也是学习MQL 的一部分。
8.底线：1.) 我对这个指标的非理想代码的主要论点 - 简单、紧凑和速度...加上完美的工作；2.）我对不完美代码的第二个主要论点--在速度和通用性方面缺乏甚至不好的类似物（见对他人原作的讨论），以及与原作相比有无改进，顺便说一下，原作很窄，在大量类似的重复块方面没有被折叠成紧凑的循环。
9.尽管有第7点，你并没有真正理解别人的代码。你的分数是2分，太低了。我还不建议你通过代码来评估软件产品。我不会说什么客观性，因为不可能期待任何一个用户的客观性。一个客观的估计（评级）只有作为几个理智的用户的估计的总和才有可能，当然它不一定要高。
1.在每一个tick都有一个对GP的引用，这样在每一个tick，以及每一次重新初始化（例如，通过TFs的过渡），OnCalculate() 中的整个主代码和重代码都不会被执行，指标工作得更快。新数据的计算--只有在出现新的低杠D1 的情况下，才会出现新的低杠，这要比在每个tick上都要稀少得多。
2.我对代码进行了深思熟虑的处理，但我在if() 中留下了一些多余的比较操作，因为我确信这不会影响性能。
3.关于MUST--被大大夸大了。你可以下载并亲眼看到该指标的飞行。
4.我不知道GP会被转储到HDD，然后在运行中的MT5 会话中每次访问时从那里读取。我仍然认为，当我启动终端时，它们被从HD读到RAM中一次，并住在那里，指标在RAM中访问它们，而不是到HD中。
5.我不认为ArraySize() 是一个昂贵的函数。而且，即使它很贵，在这个特定的代码中你也不会注意到它。我可能会在我的第一个指标中优化这个功能，因为它的使用频率很高，而指标本身则要复杂得多，资源也很密集。
6.在OnDeinit()中，我使用。
其中只有 "l "的前缀被移除（创建对象时使用了 "标签"和 "线"的名称）。
7.你现在已经做了一个已经下载并理解了代码的用户应该做的事情。你已经发现了缺陷--这也是学习MQL 的一部分。
8.底线：1.) 我对这个指标的非理想代码的主要论点 - 简单、紧凑和速度...2.）我对不完美代码的第二个主要论点--在速度和通用性方面没有类似物（见对别人的原创的讨论），以及与原创相比有无改进，顺便说一下，它很窄，在大量类似重复的块方面没有折叠成紧凑的循环。
9.尽管有第7点，你并没有真正理解别人的代码。你的分数是2分，太低了。我还不建议你通过代码来评估软件产品。我不会说什么客观性，因为不可能期待任何一个用户的客观性。一个客观的估计（评级）只可能是一些理智的用户的估计之和，它不一定要高。
按前缀删除的方法如下：ObjectsDeleteAll(0, "pref_"); //"pref_label" 和 "pref_line"
至少在OnCalculate中添加第一行，以便在一个新的条形图上寻址，而不是像现在这样在每个tick上寻址。
按前缀删除，就像这样：ObjectsDeleteAll(0, "pref_"); //"pref_label" 和 "pref_line"
至少在OnCalculate中增加第一行，以便在一个新的条形图上进行引用，而不是像现在这样在每个tick上进行引用
顺便说一下，关于第7点：我甚至在MQL5 文档中也遇到过错误，这些错误多年来都没有得到纠正。
按前缀删除是这样的：ObjectsDeleteAll(0, "pref_"); //"pref_label" 和 "pref_line"
按照你的建议删除它是不合理的，因为前缀的开头是动态的：要么是{D1}，要么 是{W1}，要么是{MN1}，然后是一个不可改变的前缀，如 "l..."。你可以根据你的版本互换动态和静态前缀，并安全地删除它们。 但这是不合理的，因为以 "R1{D1}"作为信息是不方便 的，而使用"{D1}R1 "则更方便。我很久以前就想清楚了，并且完全按照我的做法去做。
没有合理的方法可以按照你的建议删除它，因为前缀的开头是动态的：要么是{D1}， 要么是{W1}，要么是{MN1}，然后还有一个不可改变的前缀为 "l..."。你可以互换动态和静态前缀，并根据你的版本安全地删除它们。 但这是不合理的，因为将信息作为 "R1{D1}"很不方便，而使用"{D1}R1 "会更方便。我很久以前就想清楚了，并且完全按照我的做法去做。
DrawTheLine("pref"+line_types[lt], St不过，是的，原则上你可以这么做。我在上面潇洒地解释了自己，当时想的是。
不是关于对象的名称。图表完全读取用OBJPROP_TEXT 设置的标签，但对象名称可以用不太容易阅读的方式签名，因为它们是隐藏的，很少被读取。
另一方面，在 "对象的清单 "中(Ctrl+b)可以更好地看到可读的对象名称，所以我的方法更可取。此外，在有些情况下，对象名称必须非常长，所以额外的"pref_"是完全不能接受的。不过，是的，原则上你可以这么做。我在上面潇洒地解释了自己，当时想的是。
不是关于对象的名称。图表中读取的正是用OBJPROP_TEXT 设置的标签，但对象名称的签名可能不太清晰，因为它们是隐藏的，很少被读取。
另一方面，在 "对象的清单 "中(Ctrl+b)，最好能看到可读的对象名称，所以我的方法还是比较好的。除此之外，有些情况下，对象的名字必须非常长，所以额外的"pref_"将是完全不可接受 的。如果有人将仍然有一个程序与图形对象，你的那种前缀 "l"<其中只是删除前缀 "l"（名称 "标签"和 "线"被使用时，对象被创建>。
将杀死第三方程序中 所有以"l " 开头的对象。这不是一个好的解决方案