文章 "图形界面 X: 在多行文本框中选择文本 (集成构建 13)"
酷！从缓冲区粘贴的情况如何？
我还没有向 servicedesk 的开发人员 提出这样的要求。
也许，不仅需要从缓冲区插入，还需要向缓冲区发送，以便在需要时在输入字段之间传输文本。
最有可能的是，我们需要能够处理按 Ctrl + X（剪切）、Ctrl + C（复制）和 Ctrl + V（粘贴）键引起的系统事件。
这一定会让你很好奇：）。
您会在下一篇文章中展示新绘制的元素吗？我很好奇：)
1.所有元素最终都将是绘制元素。作为开发第二阶段的一部分：1 个元素=1 个对象（用于绘制的画布）。
2.是的，就像所有已经绘制的元素一样，我们也使用CCanvas 类。它已经有了绘制简单图形的方法。这是一个很好的类，如果它不存在，你就必须自己实现它。在库中已绘制的元素中，使用了逐像素绘制和线条、文本输出以及矩形、带填充矩形等形状的方法。
...
OOP 方法比你描述的要简单得多。前面已经介绍过的库方案的改动微乎其微。最后，一切都会比现在更方便、更好。
我完全不知道这种没有内部重生的系统开发秘诀。这就像圣杯一样--我愿意相信它的存在，但它不太可能....。
当然，绘制元素并不难。几乎所有东西都可以通过矩形绘制（渐变除外），但必须创建另一个事件模型。OnChartEvent() 函数 将不再在绘制的元素图案上提供固定的点击事件。用于确定优先级的 Zorder 也无济于事。很久以前，我告诉过你们创建对象映射，并列举了它的优点，但后来你们拒绝了这一解决方案，而现在，没有它你们哪儿也去不了。
毫无疑问，绘制的元素具有更多属性，与它们的交互也更加复杂。在这项技术中，系统应该更加全面，机制应该更加通用。例如，所有界面元素都应该有一个共同的存储器，其中包含它们所有属性的值。这比在不同的结构和类中创建许多单独的数组和变量更有效。所有的 OOP 约定（例如，引用对象访问其他类的变量，从中获取某个对象的某个属性的值）都只会减慢工作速度并使之复杂化，而不会简化工作。OOP 还有一个缺点，因此我并不后悔没有像你一样使用别人的类。在开发过程中使用他人创建的代码块的开发人员，对自己开发的了解不如自己创建一切的开发人员，此外，他在改进自己开发的可能性方面受到更多限制，这不仅是因为他对自己开发的了解不如别人，还因为他不会重新设计他人的代码块，因为这不是 "专业风格 "的开发所能提供的。
以上只是我的观点，我已经说完了。
我将饶有兴趣地关注图书馆的进一步发展。
当然，绘制元素并不难。几乎所有元素都可以通过矩形绘制（渐变除外），但必须创建另一个事件模型。OnChartEvent() 函数 将不再提供绘制元素细节的点击事件固定。 用于确定优先级的 Zorder 也无法提供帮助。很久以前，我告诉过您创建对象映射，并列举了它的优点，但您拒绝了这一解决方案，而现在，没有它，您将一事无成。
你总是错的。下面是一些例子，即使在当前的模型中，我也没有遇到你所说的问题（见下面的 GIF 动画）。桌子是绘制出来的，与它的交互是所有现有元素中最复杂的，甚至可以说是最复杂的。此外，这还不是最终版本。也许在下一篇文章中就会有这个表格的最终代码。
//---
请告诉我你们是如何实现同样功能的。
//---
...毫无疑问，绘制的元素具有更多的属性，与它们的交互也要复杂得多。在这种技术中，系统应更具整体性，机制应更具通用性。例如，所有界面元素都应该有一个共同的存储器，其中包含它们所有属性的值。这比在不同的结构和类中创建许多独立的数组和变量更有效。
我发现与绘制的元素进行交互要容易得多。渐渐地，一切都将变得尽可能通用。实际上，在本系列的每一篇文章中，如果你仔细阅读，而不是只看图片，这个过程都会很明显。你可以创建一个共享内存，也可以像我一样，让一个类可以轻松访问每个元素的属性。你不能断言它应该是这样而不是那样。谁也不欠谁什么。在你的开发过程中，你可以按照自己的喜好行事。我更喜欢在这个或那个问题上有自己的看法。我个人的实践和生活经验告诉我，别人说的很多都是错的。同时，我也不把自己排除在这个数字之外。但我并不害怕犯错，如果我错了，我也会想办法改正错误。
...所有的 OOP 惯例（例如，通过引用对象访问其他类的变量，从而获取某个对象的某个属性的值）都只会减慢工作进度并使之复杂化，而不会简化工作。
你的情况是这样，我的情况 则不是。)
Retag Konow：
OOP 还有一个缺点，但我并不后悔，因为我没有像你一样使用别人的类的优势。在开发过程中使用他人创建的代码块的开发人员比自己创建所有代码块的开发人员更不了解自己的开发，此外，他改进自己开发的可能性也更有限，这不仅是因为他更不了解自己的开发，还因为他不会重新设计他人的代码块，因为这不是 "专业风格 "的开发所能提供的。
在这种情况下，从零开始，靠自己。编写自己的操作系统，然后用 MQL 语言编写交易终端，然后开始开发自己的图形界面库。做完这一切之后，你就可以自豪地把脚后跟磕在胸口上了。)))
//---
附注： 我的任务是
- 练习编程。
- 为自己编写一个库，用于创建质量令我满意的图形界面。
- 与 MQL 社区分享开发成果。
- 至少部分抵消开发的人力成本。感谢 MQ 对该项目的支持。
我认为结果非常好。至少我不是唯一一个喜欢这个结果的人。:)
阿纳托利，我已经阐述了我的观点，我不想再和你进行激烈的争论。
我的表格还没有完成，但您演示的例子对我来说是一样的。表格是交互式的，单元格中有图片，有复选框，甚至列的宽度也会改变。当然，并非一切都能完美运行....。外观有点不同。添加列和列的功能尚未实现。我就不在这里展示了，否则又会因为公关被封号。
我所说的都是我在努力工作过程中获得的经验，我分享这些经验不应被视为敌意。毕竟，这里还有谁能和你一起平等地讨论所有这些问题呢？
祝你好运。
阿纳托利，我已经阐述了我的观点，我不想再与你进行激烈的争论。
好吧，我不打扰您了。)
我的表格还没有完成，但您演示的例子也是这样的。表格是交互式的，单元格中有图片，有复选框，甚至列的宽度也会改变。当然，并非一切都能完美运行....。外观有点不同。添加列和栏的功能尚未实现。我就不在这里展示了，否则又要被封公关了。
您有很大的机会阅读有关此主题的文章，甚至可以轻松使用源代码中发布的解决方案，只需将其调整为您的方案即可。
您可以在自己的博客上发布结果。我正在关注您的出版物。;)
新文章 图形界面 X: 在多行文本框中选择文本 (集成构建 13)已发布：
本文将实现使用各种组合键选择文本, 及删除所选文本的功能, 类似于在其它任意文本编辑器中完成的方式。此外, 我们将继续优化代码, 并为进入函数库演变第二阶段的最后一个过程准备好类, 其中所有控件均作为单独的图像 (画布) 呈现。
选择文本的方法已经实现了, 这就是它在完成后的应用程序中的外观:
图例. 6. 在 MQL 应用程序文本框中实现文本选择的演示。
作者：Anatoli Kazharski