在Canvas上做一个众包项目 - 页 41

 
Реter Konow:

尼古拉,你的意见总是很有趣。我已经完成了这个图形项目,只想把它交给人们。还有一些时间,任何人都会测试发动机和设计师。然后,我将继续进行完全不同的发展。

Alexey决定帮助我把矩阵翻译成标准的OOP格式。我并不介意,但坦率地说--我非常怀疑。更确切地说,我清楚地知道,这几乎是不可能的。需要一年的时间才能创造出一个同等的模拟物。从我的观点来看--只有这样才有意义--让人们有机会编辑和发展这个项目。如果我突然停止,其他人可以继续。

最主要的是让它对社区都有用)。

我想现在是时候翻过这一页,继续前进了。获得了良好的经验。
,但当然没有人会开发你的项目。你必须实事求是。

 
Nikolai Semko:

现在可能已经是翻过这一页,继续前进的时候了。已经取得了良好的经验。
但当然没有人会开发你的项目。你必须实事求是。

他们不会发展,但他们会应用。

 
Nikolai Semko:

Piotr,你的创作看起来更像是一种请求的语言,而不是一种标记的语言。
而且,正如我们所知,MQL5最近已经能够与SQLite 数据库一起工作。

什么是数据库? 它是一组表和它们之间的关系。

而查询语言(SQL--结构化查询语言)正在与这些表一起工作(创建、修改、查询和访问、删除)。
我不会给出任何建议。我已经发现,你是那种不需要任何人建议的人。
只是供思考的信息。
而且,为一个已经被标准化和开发的格式给出一个解决方案是很昂贵的。
现在我正在研究Java与数据库(MySQL)的互动。Java不得不为此创造特殊工具(JPA、Hibernate、DAO设计模式)。这个话题与你的非常接近。这些工具本质上是类--Java到SQL的翻译器。
我的看法是,在成功练习了OOP和SQL之后,从头开始,这是一个更好的方法。而标记语言XML也可能 派上用场。

它将会派上用场!跨平台的解决方案运行在WPF的声明性描述上,activiti在android,Xamarin,网页在最后--都使用XML

"Java不得不为此创造特殊的工具"--任何附加组件和工具都是为了方便访问,本地访问甚至对象绑定,从数据库中读取数据和向其中添加数据都是在不调用终端开发者的查询的情况下完成的。当然,一切都可以在查询中进行,只是都被深深地隐藏在附加组件中。

而对彼得来说,如果他有意愿,一切都会顺利进行。到目前为止,他已经摆脱了试图 "推动 "其模型的顽固习惯。而我则是试图把他从他的矩阵中抽象出来,转到一般的推理上。只要他执着于他的矩阵,就很难理智地推理。但到目前为止,事情进展得很顺利。

尼古拉,我希望你能不时地加入我们的讨论。

 
Алексей Барбашин:

...

如果彼得有意愿,一切都会顺利进行。到目前为止,他有试图 "推动 "其模式的习惯。我正试图把他从他的矩阵中抽象出来,转到一般的推理上。只要他执着于他的矩阵,就很难理智地推理。但到目前为止,事情进展得很顺利。

...

我不再试图推动什么了)。只是,我不知道如何将这一切转化为课程。我现在全神贯注于调试,只要我一公布,你和其他人就会对它有一个更好的了解。那么也许会有某种计划。也许集体主义在这个问题上仍然会得到回报)。
 
Алексей Барбашин:

尼古拉,我希望你能不时地加入到对话中来。

我不介意,但说实话,我甚至不知道我可以怎么帮助。我都说过很多次了。彼得只需要走他自己的路。

他是一个自给自足的人,不需要赞助,因为他是自己的老板。虽然有时你会感觉到他需要一个靠山,但这只是一个幻觉,一个把戏,一种诱惑 :)

 
Nikolai Semko:

我不介意,但说实话,我甚至不知道我可以怎么帮助。我都说过很多次了。彼得只需要走他自己的路。

他是一个自给自足的家伙,不需要监督,因为他是自己的老板。虽然有时你会感觉到他需要一个靠山,但这只是一种幻觉,一种引诱:))。

尼古拉,你认为是否值得放弃引导彼得走上另一条个人发展道路的尝试?

P.S.: 是我的问题还是昨天网站瘫痪了?

 
Алексей Барбашин:

尼古拉,你认为是否值得离开尝试引导彼得以另一种方式发展他的个性?

这是关于以另一种方式指导项目。它的代码比我的更容易重写)。
有一种观点认为,我们应该制作一个基类CElement,并从它那里继承所有类型的元素。

如果我们考虑元素之间的链接逻辑,那是对的,但如果我们考虑元素的结构,那么基类应该是CRec、CImage、CText。
所以,一切都取决于分类标准的选择。

我们可以根据元素的物理结构进行分类,也可以根据其类型进行分类。有许多分类的变体,每一种都提供了不同的类库结构。有必要选择一个标准并遵循它。
 
Реter Konow:
这是关于将项目指向另一个方向。它的代码比我的更容易重写)。
我们的想法是建立一个基类CElement,然后从它开始,将所有类型的元素作为后代。

如果我们考虑元素关系的逻辑,这是正确的,但如果我们考虑元素的结构,那么基类应该是CRec、CImage、CText。
所以,一切都取决于分类标准的选择。

我们可以根据元素的物理结构进行分类,也可以根据其类型进行分类。有许多分类的变体,每一种都提供了不同的类库结构。有必要选择一个标准并遵循它。

我认为最好是看一下界面和控制的祖先的经验。我不认为重新发明轮子或将事情过度复杂化有什么意义。很多东西在我们之前就已经被发明了,我们只需要把它们移植到mql上。

我不只是问这些或那些控制有什么共同点。

现在我再问一件事:彼得,把以下控件的图片贴在这里--带图标和标题的按钮、带图标和标题的文本标签、复选框、单选按钮、组合框、面板、输入框

 
Алексей Барбашин:

我认为在这个问题上,最好是看看界面和控制设计的先辈们的经验。重新发明车轮或将事情过度复杂化是没有意义的。很多东西在我们之前就已经被发明了,我们只需要把它们移植到mql上。

我不只是问这些或那些控制有什么共同点。

现在我再问一件事:彼得,把以下控件的图片放在这里 - 带有图标和标签的按钮,带有图标和标签的文本标签,复选框,单选按钮,组合框,面板,输入框

我有祖先的经验,但哪一个会有用?例如,工作人员的图书馆,或Anatoly的图书馆提供了一个现成的班级结构,但这些都是图书馆。也就是说,元素是通过调用正确的函数创建的。我有一种标记语言,这意味着你可以用一种特殊的语言在一个单独的文件中编写GUI。这是一种完全不同的技术。如果你没有考虑到这一点,你可以创建一个普通的库,在MQL中我们已经有了两个。你不需要另一个。这不是关于它们是否在画布上的问题,而是关于在它们上创建一个界面有多容易。

图片将被公布。
 
Реter Konow:
祖先的经验是有的,但这其中哪一个会做?例如,职工图书馆或安纳托利亚图书馆提供了一个现成的班级结构,但这些都是图书馆。也就是说,元素是通过调用正确的函数创建的。我有一种标记语言,这意味着你可以用一种特殊的语言在一个单独的文件中编写GUI。这是一种完全不同的技术。如果你没有考虑到这一点,你可以创建一个普通的库,在MQL中我们已经有了两个。你不需要另一个。这不是关于它们是否在画布上的问题,而是关于在它们上创建一个界面有多容易。

我将张贴图片。

这是关于两者的问题。这是关于在什么基础上完成的绘画,以及用它来建立一个界面有多容易。

事实上,所有东西都是一个图书馆。例如,你已经创建了一个对话框构造函数 但基于什么? 基于相同的库控件。因此,为了让用户能够在表单上投放东西,他必须提供这些非常的控件,也就是说,他可以从 ...图书馆。这就是为什么它叫这个名字。然后你在此基础上生成一个标记文件,用户可以在mql中使用,但最初的事实是,用户将从可用列表中选择控件。这是同一个图书馆,只是 "从侧面看"。