文章 "自定义图形控件。第一部分:创建简单控件"

 

新文章 自定义图形控件。第一部分:创建简单控件已发布:

本文介绍开发图形控件的一般原则。我们将准备若干用于快速和方便地处理图形对象的工具,分析一个创建用于输入文本或数字的简单控件的例子以及使用该控件的方法。

作者:Dmitry Fedoseev

 
我想知道第二部分的计划是什么?
 
sergeev:

我想知道第二部分的计划是什么?
第二部分是标准控件 库(10 多个项目:复选框、组合框、滚动条、列表、单选按钮等),第三部分是创建带控件的表单。
 

......我真的需要它改变。

也许我们应该从第三部分开始--用控件 创建表格。

然后再进入下一部分--了解每个元素的内部工作原理。

也就是说,首先要让用户了解这个综合体作为一个整体是如何工作的,子元素是如何与父元素交换信息和事件的,以及整个意识形态是如何工作的。这一点很重要,因为从一般到特殊,再到每个具体元素的微妙之处,都是可取的。

顺便说一句,你不应该强调绘制,即每个元素是如何绘制的(你可以做得很简短,但你可以通过 "显示 "功能绘制所有元素,这样用户就会知道在每个类中从哪里可以看到绘制块)。与整个过程的意识形态相比,绘制真的不算什么。

最好是展示一些现成的表单示例,在这些示例中,所有元素都是关联的。

也就是说,在一个现成的例子上,对具体内容进行细分。

 
sergeev:

意识形态会改变吗......我真的需要它改变。

也许我们应该从第三部分开始,即模具的制作。

然后再逐步深入到每个元素的内部运作。

到底什么是ideoligy?

形状基本上什么都不是--X 和 Y 坐标。

如果你从一个表单开始,你会在上面写什么--"这是一个表单,在这里你将添加一个控制元素,在这里你将处理它的事件......",但它是什么样的控制元素,它代表什么--没有人知道。

如果你在第二部分制作了一个表单,而我们只有一个控制元素--这既不具指示性,也不美观。

 
Integer:

意识形态究竟是什么?

形式本质上什么都不是--X 和 Y 坐标。

对上面的答案进行了扩展。

你说得没错。这就是问题所在,形式什么都不是。重要的是事件的交换过程和所有元素的整体互动。只有当你展示了整个系统的运作,而不是逐个元素的运作时,才能解释这一点。

 
Integer:

如果您在第二部分中制作了一个表单,而我们只有一个控件元素--这既不具指示性,也不美观。
您已经准备好表单和控件类了吗?
 
sergeev:

扩展了刚才的答案。

你说得没错。这就是问题所在,形式算不了什么。最重要的是事件交换过程和所有元素的整体交互。

表单上会有 "确定 "和 "取消 "按钮,终端重启时会保存数据。还将有事件处理、拖动表单、最小化表单等功能。
 
sergeev:
表单和控件类准备好了吗?

已经准备好了。一开始我做的时候没有子窗口,现在我正在重新设计一切,以便在子窗口中工作。

 
sergeev:

......我真的需要它改变。

也许我们应该从第三部分开始--用你的控件创建表格。

然后再进入下一部分--了解每个元素的内部工作原理。

也就是说,先让用户了解整个综合体是如何工作的,子元素和父元素之间是如何交换信息和事件的,以及整个意识形态是如何工作的。这一点很重要,因为最好能从一般转向特殊,即每个具体元素的微妙之处。

顺便说一下,不应强调渲染,即每个元素是如何绘制的。最好是举例说明形式是如何运作的,以及所有元素是如何联系在一起的。与整个过程的意识形态相比,绘画实在算不了什么。


别跟我说,创建简单代码的例子已经够多了,但你却无法创建一个成功的类层次结构,或者至少无法创建一个通用的、易于转换的产品的易实现方案。即使是 MQ 中的标准类,也常常因为预先设定了各种可能性而使程序的编写复杂化。

 
Integer:
表单上将有一个 "确定 "和 "取消 "按钮,以便在终端重新启动时保存数据。还将有事件处理、拖动表单、最小化等功能。

好的。这非常好。

如果你在第二部分讲述高级功能,那么文章中的组件会用得更快。
我还是会从表单+按钮(+输入框)开始,然后在第三部分才讲述具体的控制组件--列表、菜单等。

毕竟,我们的任务是教授如何编写此类控件。
此外,只要您在第二部分就给出表单+按钮(我指的是 3 种--单选、按下、复选)+编辑框,用户就会将这些类视为一个整体,并能够独立创建自己的控件。