文章 "图形界面 VI: 滑动条与双重滑动条控件(第二章)"

 

新文章 图形界面 VI: 滑动条与双重滑动条控件(第二章)已发布:

在前一篇文章中,我们已经使用四个常用图形界面控件加强我们的开发库:复选框,编辑框,带有复选框的编辑框,以及复选组合框。第六部分的第二章将致力于滑动条与双重滑动条控件的开发。

元件将由六个图形对象构成,它们是:

  1. 背景
  2. 标题 (文字标签)
  3. 输入栏位
  4. 滑块线
  5. 滑动条滑块
  6. 滑动条指示针

 

图 1. 滑动条控件的组成部分。

作者:Anatoli Kazharski

 
Реter Konow:
...

我对您的意见和建议很感兴趣。

我需要澄清。

  1. 如何区分主窗口和设置窗口的概念?
  2. 您建议在当前的窗口实现中添加哪些功能,使其可以被称为 "主窗口"?

 

至于文章中介绍的例子,我的目的是展示元素在不同组合中的作用。这只是展示不同类型元素互不冲突的一种方式。对于下拉元素和使用滚动条 的元素来说尤其如此。

 
Реter Konow:

...

如果将主应用程序窗口设置为复合窗口,那么所有开发人员都有机会为其选择 "主要 "内容。在我看来,"可组合性" 是 "主 "应用程序窗口的显著特征。

无论如何,我认为您应该考虑开发窗口的功能。

思考。目前的库结构允许实现此类功能。但在开始实现之前,我们还需要解决其他一些问题,使其相当美观。我看到了几种方案。我还不知道会采用哪一种,因为我需要进行大量的实验和测试,以选择对资源消耗最小的一种。

我会在当前系列的计划文章发表后再做决定。从开发控制的角度来看,最复杂和最有趣的还在后面。

一般来说,我不保证能很快完成,因为除此之外,我还计划优化 当前版本的代码,并进行一些补充和修正,这将大大减少资源消耗。还有一点,在谈到优化和减少资源消耗的尝试时,最终能否有所收获还是个未知数。你可能会花很多时间,但当你走到终点时,你会发现这根本没有用。但这并不可怕。如果你不尝试,你就不会知道。;)

 
Реter Konow:

不过,这个问题的提法非常有趣....。就我个人而言,我从未想过优化和减少资源消耗可能是不必要的,甚至是有害的,而且在 "终点线 "上也不会有用。你把我难住了....。我们当然可以就这个问题展开讨论或争论,但我不太可能找到足够的论据,因为我从未从这个角度来看待这个问题。

...

优化和减少资源消耗可能是不必要的,甚至是有害的 "这句话不是我说的。在我看来,优化是必须的,而且肯定会有收益。我只管去做,如果有结果,我就会写一篇文章。现在没有足够的时间来阐述这个问题。

整个 OOP 语法真的有必要吗? 例如:既然变量可以在全局级别可见,为什么还要将它们传递到函数中?既然可以连接函数文件,为什么还要连接类?文件不需要复杂的函数互连系统,也不需要创建对象 来访问函数和变量。为什么要使用大量杂乱无章的规则和各种语法呢?

试着做同样的事情,但不使用 OOP。这样,一切都可以像这样运行。我首先试了一下,得出的结论是,如果没有 OOP,即使只为自己做,也很难完成这样一个项目。现在,我可以非常轻松地在这个结构中浏览。一切都井井有条,各就各位。可以访问库中的所有对象和元素。它们不会相互重叠,只有在可以访问的地方才会被访问,每个对象都有自己的类型和名称。我可以看到在哪些地方可以重构、优化代码和某些算法,减少资源消耗。

每个人不仅可以提出建议,还可以提出解决某些问题的方法,只要他们看到并知道如何去做。我已经收到了许多来自不同用户的私下建议,内容涉及需要修复的内容和位置。在英文论坛上,也有人指出了该程序库的一些设计错误。我已经知道至少有四个因素会增加资源消耗。有些显然是不必要的消耗,消除它们很可能会产生效果。但这一切目前还只是理论上的。无论如何,我们都需要进行测试,只有在测试之后,我们才能说是否有一些收获。

无论如何,我认为关于编程方法孰优孰劣的争论毫无意义。你的经验可能会告诉你一件事,而其他人的说法可能恰恰相反。生活是无限丰富多彩的。;)

 
Реter Konow:

但是,顺序本身与实现顺序的特定方法无关。如果你在程序中通过按类划分功能来创建顺序,那么你应该知道,通过按文件划分功能也可以重复相同的顺序

顺序--是的,但访问和操作许多不同类型的对象--不是。在我看来,这在 OOP 中要容易得多。

如果你创建了一个枚举或结构 AS THESE,那么它们就不必按照 OOP 规则和 OOP 语法来完成。你只需注释掉这一行,然后写上 "结构 A. 元素列表:",变量的访问就会简化。OOP 无助于对任何东西进行排序,而只是为编写 现成的排序方案提供了一个统一的标准

为什么 呢?因为你可以一次性创建一个完整的结构,然后通过声明它的实例、数组,甚至数组的数组来处理所有这些。不使用 OOP 也能做到这一点,但在我看来,OOP 更方便。

如果变量 在结构或类之外,访问变量 又如何简化呢?恰恰相反,正是 OOP 中经过深思熟虑的有序方案有助于组织一切,并简化对可访问变量和不可访问变量的访问--将它们完全关闭。

Retag Konow
在这里我无法反驳你。因为 OOP 已被普遍接受,您的程序库的开发很容易被其他程序员所接受。我希望你能做到这一点。:)

这也是我们开始做这件事的初衷。一个人是好的,但还不够。;)

 
Реter Konow:

如果这不是秘密,它与你何干?

问问宇宙吧我们只是它手中的工具。;)


虚荣?

不,是满足。但不是来自虚荣。我也不知道为什么。也许是因为我把脑子里成群结队的未实现的想法和任务稀释了一部分。写文章也能约束我,因为责任更重了。我已经大大改进了这个库的代码,它最初是我为自己写的。这还远远不是极限。

另外,为文章付费至少也是对我所花时间的一点补偿。

Retag Konow

大多数人都是懒惰的,他们更看重成品,而不是附带说明的工具包或制作这些产品的建筑材料。 迫于无奈,他们会使用你的库,但如果有机会减少工作量,不写代码就能创建界面,不幸的是,他们很快就会忘记你美丽的库。这将是社会对诚实高尚、无私奉献的人的背叛。

也许大多数人是这样,但不是所有人。我与他们分享。正如他们与他人分享一样。

顺便说一句,我也在考虑制作一个用于创建图形界面的 可视化工作室。它将在这个库的帮助下创建。我想做一些类似于微软 Visual Studio 所做的事情。也许会做得更好。时间会证明一切。像往常一样,一切都要从小实验开始。甚至我都不知道最终会得到什么。)

Retag Konow

在我看来,在创建交易程序的实践中,社区进行革命的时机已经成熟,而你却想提供另一种 "升级"。 不过,对于这一切,我祝你好运。:)

当然了!这就是我决定公布这一切的原因。为了解决这个问题,并进一步朝着这个方向前进。;)

 
Реter Konow:

多么雄心勃勃,多么乐观就像我一样......))))))

你的雄心壮志还停留在口头上。来吧,已经展示了你的竞争力!
 
Реter Konow:

能否请您说明一下,您是在向谁发出呼吁--是我,还是阿纳托利和我?

如果是对我,我最近已经演示了我的窗口、滚动条、表格和特效的基本功能。

当然是对你。你想用你的视频与阿纳托利评论良好的资料竞争吗?哪一类?)

要对程序进行评估,您至少需要一个演示版。这是一个界面,你需要去感受它。

这就是为什么我建议您不要再谈论 "可怕的竞争对手",而是看看它的演示版;)

 
Реter Konow:
...问问阿纳托利是否认为我是他的竞争对手?让他自己告诉你。:)

不,我不认为你是竞争对手。我的工作形式不同,我们之间没有任何重叠。我也不想参加比赛。我会按照自己的节奏工作。

只有在我或多或少达到我认为可以接受的质量之后,我才会发表我的材料。

顺便说一下,下一篇要发表的文章是: 图形界面 VII:"表格 "的要素(第 1 章)。它将介绍多达三种类型的表格。;)

 
Реter Konow:

我希望来点竞争!:)真遗憾。哦,好吧。我发现这个社区的竞争意识很弱。当我问起市场上的竞争时,他们说没有竞争,当我试图支持另一个人举办锦标赛的倡议时,他们又说没有竞争,所以参与者几乎没有....。无聊透顶......;)好了,没事了。

我一定会关注今后的文章。祝你好运。:)

让我们在质量和功能上一决高下。

此外,我已经发表了18 篇文章。那就是18 招。不,你已经进了18 个球。而你一球未进。我保证至少再进7 球只进一球的比赛可没什么意思。;)