文章 "图形界面 XI: 重构函数库代码 (集成编译 14.1)" - 页 3 1234 新评论 Реter Konow 2017.07.03 15:19 #21 Anatoli Kazharski:你除了胡言乱语，就没别的了。) 所做的一切当然不是你说的。所有这一切从一开始就计划好了，并严格按照一定的顺序发表。但你当然可以不这么想，继续如你所说，"在混乱中拼命寻找新的自己"。我不介意。)我还说过，技术发展的条件不仅是扩展和增加功能，而且是压缩和普及代码。将不同的功能组合成块。这正是你在文章中所展示的。 您多次将多个类合并为一个类，并压缩了代码。与此同时，这些类也变得更加通用，因为一个类包含多个类似的元素，并通过模式进行选择。这就是压缩和通用化。我又一次说对了。那我错在哪里呢？当然，你并不是因为我的话才做了所有的事情。这我知道。但我说的是对的。 Andrey Khatimlianskii 2017.07.03 16:14 #22 Anatoli Kazharski:还记得摆脱巨怪的唯一方法吗？没错，就是别喂它。 Anatoli Kazharski 2017.07.03 16:32 #23 Andrey Khatimlianskii:还记得摆脱巨怪的唯一方法吗？没错，就是别喂它。我会给你一些解释作为甜点)Retag Konow: ...当然，你并不是因为我说的话才做所有的事。我知道这一点。只是我说的话是对的....谁在乎你是对还是错？) 不管别人怎么说，你就是你自己。)你说的话不言自明，从一开始就有人指出来了。但除此之外，你还发表了许多无稽之谈。例如，在 OOP 的帮助下不可能有效地实现这样的方案。如果你连 OOP 都不懂，又怎么能得出这样的结论呢？你有没有注意到，总体方案与重构前没有任何区别？这样的过渡并不困难。主要的时间都花在处理几十个文件和测试上了。在目前的实现中，过渡到第三阶段将更加容易。困难恰恰不在于此。如果是我来实现，我会把所有东西从头到尾都画在一个对象上，而不是像一些论坛成员演示的那样，有时（在使用时）一些对象会出现在主图形用户界面的顶部。从程序员个人发展的角度来看，我不再对这种半途而废的做法感兴趣。这与文章中介绍的版本相差无几。而且 MQL 应用程序的用户也不会发现有什么不同。在我目前的版本中，所有元素都绘制在单独的对象上，只有一个例外-- 对象图形(OBJ_CHART)。如果能以这样的质量和功能实现绘制形式的元素，那将是一件非常有趣的事情，但目前这并不合理。我对本网站 MQ 开发人员提供的 MQ 服务更感兴趣。从字面上看，在不久的将来还会有两三篇关于 "图形用户界面 "的文章，然后即使有更新，也会非常罕见。主要是对库进行深度优化，尽可能减少资源消耗。 Реter Konow 2017.07.03 17:01 #24 Anatoli Kazharski:我会给你一些解释。甜点)1.谁在乎你是对还是错？) 不管别人怎么说，对你自己来说，你还是你自己。)2.你说了一些不言自明的话，而且从一开始就有人指出来了。但除此之外，你还胡说八道。 3.例如，借助 OOP 不可能有效地实现这样的方案。如果你连 OOP 都不懂，怎么能得出这样的结论呢？4.你有没有注意到，总体方案与重构前没有任何变化？这样的过渡并不困难。主要的时间都花在处理几十个文件和测试上了。5.在目前的实现中，过渡到第三阶段会更加容易。困难恰恰不在于此。如果我这样实现，我将在一个对象上从头到尾绘制所有内容，而不是像一些论坛成员演示的那样，某些对象有时（在使用时）会出现在主图形用户界面的顶部。从程序员个人发展的角度来看，我不再对这种半途而废的做法感兴趣。这与文章中介绍的版本相差无几。而且 MQL 应用程序的用户也不会发现有什么不同。在我目前的版本中，所有元素都绘制在单独的对象上，只有一个例外-- 对象图形(OBJ_CHART)。如果能以这样的质量和功能实现绘制形式的元素，那将是一件非常有趣的事情，但目前这并不合理。我对本网站 MQ 开发人员提供的 MQ 服务更感兴趣。从字面上看，在不久的将来还会有两三篇关于 "图形用户界面 "的文章，然后即使有更新，也会非常少。主要是对库进行深度优化，将资源消耗降到最低。1.不一定。如果我错了，而且有令人信服的证据证明我错了，那么我就会承认并改变我的观点。2.这些显而易见的事情往往并不显而易见。开发人员的抽象思维能力和对大规模开发过程的理解能力是一个优势。我并没有从你那里找到这种理解，这就是我谈论它的原因。我感兴趣的是行动的哲学背景，而不仅仅是挖掘细节和套路。抓住核心，看到本质。对某些人来说，了解剧本和过程的逻辑是很有价值的。)3. 现在很难说已实施的计划效果如何。这是相对的。但是，可以通过一些参数来确定实施的有效性。我认为可以找到这些参数。在这种情况下，我们可以比较采用不同技术的相同机制的实施效率。然后我们就可以得出有效性的结论。如果你愿意，我们可以试着找出答案。 我仍然认为这种执行方式不够有效。唉，这是有原因的。 4.方案不完全相同。你修改了基类。在库的 "核心 "部分。你在文章中所说的。从外观上看，方案是相似的，但你采用了不同的元素创建技术。5.顺便说一句，我从没说过我想在一张位图上制作一个完全绘制的图形用户界面。我认为这是个坏主意。从很多角度来看，这显然不是最好的解决方案。因此，对我来说，这不是 "半途而废"，而是朝着更实用的方向做出的选择。我还要补充一点：您可以在一个位图上完成以下所有工作：所有绘制的元素都是包含图像像素的数组。绘制完成后，创建一个位图和一个大型图像数组，然后按顺序将每个元素的内容塞入其中。这样，你就得到了一个包含整个窗口内容的完整图像的位图。我离这个目标只有一步之遥。我想你也能做到。 Anatoli Kazharski 2017.07.03 17:49 #25 Реter Konow:... 那时候我们就可以得出结论了。如果你愿意，我们可以试试看。 我还是认为这种实施方法不够有效。唉，这是有原因的。 ... 你应该首先有效地发表文章。除了你，没有人掌握过你的 "效率 "课题。可能是因为它太有效了，以至于让人害怕展示它。)...我应该补充一点：您可以在一个位图上完成以下所有工作：所有绘制的元素都是包含图像像素的数组。绘制完成后，创建一个位图和一个大型图像数组，然后按顺序将每个元素的内容塞入其中。这样，就有了一个包含整个窗口内容的完整图像的位图。...无可奉告，显而易见的船长。) Реter Konow 2017.07.03 18:12 #26 Anatoli Kazharski: 你应该首先有效地出版。因为除了你自己，从来没有人把你 "有效 "的东西拿在手里过。可能是因为它太有效了，以至于展示出来会让人害怕。)无可奉告，显而易见的船长。) 那我们来比较一下效率，好吗？我直接提出来的。 Anatoli Kazharski 2017.07.03 18:15 #27 Реter Konow: 那么，让我们来比较一下效率，好吗？我提出了一个直接的建议。 我不介意比较。) Реter Konow 2017.07.03 18:22 #28 Anatoli Kazharski: 我不介意。比较一下。)好吧。 1.首先，我们将确定评估所使用技术有效性的标准。2.然后，我们将确定评估所实施机制有效性的标准。3.3. 我们将选择由我和你制定的相同机制，并用它们进行测试。之后，我们将得出一个明确的结论。您同意这个计划吗？ Anatoli Kazharski 2017.07.03 18:25 #29 Реter Konow:...首先我们... 不是我们，是你我有事情要做（仔细读）。我不想浪费时间。) Реter Konow 2017.07.03 18:31 #30 Anatoli Kazharski: 不是我们，是你。我有事要做（读仔细点）。我不想浪费时间。)真遗憾 可惜斗志现在不知在哪里休息了......）。 1234 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
你除了胡言乱语，就没别的了。)
所做的一切当然不是你说的。所有这一切从一开始就计划好了，并严格按照一定的顺序发表。但你当然可以不这么想，继续如你所说，"在混乱中拼命寻找新的自己"。我不介意。)
我还说过，技术发展的条件不仅是扩展和增加功能，而且是压缩和普及代码。将不同的功能组合成块。这正是你在文章中所展示的。
您多次将多个类合并为一个类，并压缩了代码。与此同时，这些类也变得更加通用，因为一个类包含多个类似的元素，并通过模式进行选择。这就是压缩和通用化。
我又一次说对了。
那我错在哪里呢？
当然，你并不是因为我的话才做了所有的事情。这我知道。但我说的是对的。
还记得摆脱巨怪的唯一方法吗？没错，就是别喂它。
还记得摆脱巨怪的唯一方法吗？没错，就是别喂它。
我会给你一些解释作为甜点)
...
当然，你并不是因为我说的话才做所有的事。我知道这一点。只是我说的话是对的....
谁在乎你是对还是错？) 不管别人怎么说，你就是你自己。)
你说的话不言自明，从一开始就有人指出来了。但除此之外，你还发表了许多无稽之谈。例如，在 OOP 的帮助下不可能有效地实现这样的方案。如果你连 OOP 都不懂，又怎么能得出这样的结论呢？
你有没有注意到，总体方案与重构前没有任何区别？这样的过渡并不困难。主要的时间都花在处理几十个文件和测试上了。
在目前的实现中，过渡到第三阶段将更加容易。困难恰恰不在于此。如果是我来实现，我会把所有东西从头到尾都画在一个对象上，而不是像一些论坛成员演示的那样，有时（在使用时）一些对象会出现在主图形用户界面的顶部。从程序员个人发展的角度来看，我不再对这种半途而废的做法感兴趣。这与文章中介绍的版本相差无几。而且 MQL 应用程序的用户也不会发现有什么不同。
在我目前的版本中，所有元素都绘制在单独的对象上，只有一个例外-- 对象图形(OBJ_CHART)。如果能以这样的质量和功能实现绘制形式的元素，那将是一件非常有趣的事情，但目前这并不合理。我对本网站 MQ 开发人员提供的 MQ 服务更感兴趣。从字面上看，在不久的将来还会有两三篇关于 "图形用户界面 "的文章，然后即使有更新，也会非常罕见。主要是对库进行深度优化，尽可能减少资源消耗。
我会给你一些解释。甜点)
1.谁在乎你是对还是错？) 不管别人怎么说，对你自己来说，你还是你自己。)
2.你说了一些不言自明的话，而且从一开始就有人指出来了。但除此之外，你还胡说八道。
3.例如，借助 OOP 不可能有效地实现这样的方案。如果你连 OOP 都不懂，怎么能得出这样的结论呢？
4.你有没有注意到，总体方案与重构前没有任何变化？这样的过渡并不困难。主要的时间都花在处理几十个文件和测试上了。
5.在目前的实现中，过渡到第三阶段会更加容易。困难恰恰不在于此。如果我这样实现，我将在一个对象上从头到尾绘制所有内容，而不是像一些论坛成员演示的那样，某些对象有时（在使用时）会出现在主图形用户界面的顶部。从程序员个人发展的角度来看，我不再对这种半途而废的做法感兴趣。这与文章中介绍的版本相差无几。而且 MQL 应用程序的用户也不会发现有什么不同。
在我目前的版本中，所有元素都绘制在单独的对象上，只有一个例外-- 对象图形(OBJ_CHART)。如果能以这样的质量和功能实现绘制形式的元素，那将是一件非常有趣的事情，但目前这并不合理。我对本网站 MQ 开发人员提供的 MQ 服务更感兴趣。从字面上看，在不久的将来还会有两三篇关于 "图形用户界面 "的文章，然后即使有更新，也会非常少。主要是对库进行深度优化，将资源消耗降到最低。
1.不一定。如果我错了，而且有令人信服的证据证明我错了，那么我就会承认并改变我的观点。
2.这些显而易见的事情往往并不显而易见。开发人员的抽象思维能力和对大规模开发过程的理解能力是一个优势。我并没有从你那里找到这种理解，这就是我谈论它的原因。我感兴趣的是行动的哲学背景，而不仅仅是挖掘细节和套路。抓住核心，看到本质。对某些人来说，了解剧本和过程的逻辑是很有价值的。)
3. 现在很难说已实施的计划效果如何。这是相对的。但是，可以通过一些参数来确定实施的有效性。我认为可以找到这些参数。在这种情况下，我们可以比较采用不同技术的相同机制的实施效率。然后我们就可以得出有效性的结论。如果你愿意，我们可以试着找出答案。 我仍然认为这种执行方式不够有效。唉，这是有原因的。
4.方案不完全相同。你修改了基类。在库的 "核心 "部分。你在文章中所说的。从外观上看，方案是相似的，但你采用了不同的元素创建技术。
5.顺便说一句，我从没说过我想在一张位图上制作一个完全绘制的图形用户界面。我认为这是个坏主意。从很多角度来看，这显然不是最好的解决方案。因此，对我来说，这不是 "半途而废"，而是朝着更实用的方向做出的选择。
我还要补充一点：您可以在一个位图上完成以下所有工作：所有绘制的元素都是包含图像像素的数组。绘制完成后，创建一个位图和一个大型图像数组，然后按顺序将每个元素的内容塞入其中。这样，你就得到了一个包含整个窗口内容的完整图像的位图。我离这个目标只有一步之遥。我想你也能做到。
...
那时候我们就可以得出结论了。如果你愿意，我们可以试试看。 我还是认为这种实施方法不够有效。唉，这是有原因的。
...
...
我应该补充一点：您可以在一个位图上完成以下所有工作：所有绘制的元素都是包含图像像素的数组。绘制完成后，创建一个位图和一个大型图像数组，然后按顺序将每个元素的内容塞入其中。这样，就有了一个包含整个窗口内容的完整图像的位图。
...
无可奉告，显而易见的船长。)
你应该首先有效地出版。因为除了你自己，从来没有人把你 "有效 "的东西拿在手里过。可能是因为它太有效了，以至于展示出来会让人害怕。)
无可奉告，显而易见的船长。)
那么，让我们来比较一下效率，好吗？我提出了一个直接的建议。
我不介意。比较一下。)
好吧。
1.首先，我们将确定评估所使用技术有效性的标准。
2.然后，我们将确定评估所实施机制有效性的标准。
3.3. 我们将选择由我和你制定的相同机制，并用它们进行测试。
之后，我们将得出一个明确的结论。
您同意这个计划吗？
...
首先我们
...
不是我们，是你。我有事要做（读仔细点）。我不想浪费时间。)
真遗憾
可惜斗志现在不知在哪里休息了......）。