帆布很酷! - 页 55 1...484950515253545556575859606162...93 新评论 Реter Konow 2020.01.22 12:18 #541 Roman: 如果你还记得Borland，GUI是在可视化编辑器中组装的，控件的布局被放置在工具栏中，然后你再编写处理程序。 如果ME有这样的图形功能，可以在视觉模式下建立布局，那将使建立图形化的应用程序变得更加容易。 由于大多数现代程序员都学习过GUI建设，他们习惯了（所以他们被教导）可视化的GUI编辑器。 而在纯C风格的代码上建立一个图形应用程序的布局，对他们来说兴趣不大。因为它已经是硬核C风格了。 我们需要一个可视化的编辑器来建立一个图形化的应用程序，然后人们就会急于学习它，那些在VS或RadStudio工作的人，他们甚至很快就能掌握可视化的编辑器。 在这里，MQL中已经有了这样一个可视化编辑器的原型。然而，人们激烈地反对它。他们说在交易中没有必要这样做。 总的来说，他们尽其所能地打击了士气。因此，我不知道社区真正需要什么。 Реter Konow 2020.01.22 12:34 #542 Алексей Барбашин:我完全支持需要有能力收集...但是否有必要是另一个问题。我不知道开发者自己是否把终端看作是一种交易工具或编程工具？在这一点上我可能是错的，但我一直认为ME的设计正是为了实现用户需要的交易功能。正是交易!但如今ME的编程深度已经进入了真正需要能够 "建造 "骰子的领域，并对编程有了非常认真的理解....。而这最终会导致什么呢？这导致先进的交易工具变得只有有经验的程序员才能使用!也就是说，如果你不是一个程序员，你在交易中没有任何事情可做...但这是荒谬的。ME只是一个填补缺失功能的助手，这些功能本应更正确地内置于终端本身（不同的向导）。而事实上，ME现在正作为一个新的开发环境发展，对用户的知识要求越来越高。基于这一结论，可视化工具是必要的，但它们的使用应该让没有深厚编程知识的用户也能使用。只有在这种情况下，他们才会有需求。这只是我的观点，我并没有把它强加给任何人。 如果你考虑CCanvas类，有大约20个绘制图形基元的功能。假设一个用户知道他们全部，并且知道OOP的规则和语法。然而，这对他的数据的最简单的可视化来说太少了。更不用说创建最简单的控件--一个按钮。也就是说，在画布上绘制基元是比较容易的，但在创建可视化或GUI时使用这些基元则要困难得多。没有知识，你就不能在这里做，没有开发者的才能，你就不能在这里做。但有多少人拥有它？这就是关键问题。 为了发挥Kanvas类的潜力，你需要能够将图形基元组合成更复杂的对象（控件），将它们的操作与事件驱动模型结合起来，用函数编写关系。或者，将数字数据转换为不同的图形曲线...这是一份适合有天赋和非常努力工作的用户的工作。事实上，不是用户，而是开发者。 Roman 2020.01.22 12:44 #543 Реter Konow:在这里，MQL中已经有了这样一个可视化编辑器的原型。然而，人们激烈地反对它。他们说在交易中没有必要这样做。总的来说，他们尽其所能地打击了士气。因此，我不知道社区真正需要什么。 哇，所以有了一个原型。 因此，也许开发商应该重新考虑社区的浅薄意见？并恢复发展视觉模式的计划。 当然，让一个本质上备受追捧的功能失去士气，这有点奇怪。 现在很少有地方会教如何用C语言构建图形界面，如果有的话，他们还在教。 现在，每个人都被教导要用可视化模式在IDE中工作，由于MT5早已不仅仅是交易平台，，构建图形化应用程序的可视化模式将有很大需求。 说实话，我很震惊，开发者听从了那些反对它的短视者的意见。 Алексей Барбашин 2020.01.22 12:53 #544 Реter Konow: 如果我们考虑CCanvas类，大约有20个函数用于绘制图形基元。假设用户都知道它们，并且知道OOP规则和语法。然而，直到其数据的最简单的可视化 - 它是太少了。更不用说创建最简单的控件--一个按钮。也就是说，在画布上绘制基元是比较容易的，但在创建可视化或GUI时使用这些基元则要困难得多。没有知识，你就不能在这里做，没有开发者的才能，你就不能在这里做。但有多少人拥有它？这就是关键问题。 为了发挥Kanvas类的潜力，你需要能够将图形基元组合成更复杂的对象（控件），将它们的操作与事件驱动模型绑定，用函数编写关系。或者，将数字数据转换为不同的图形曲线...这是一份适合有天赋和非常努力工作的用户的工作。事实上，不是用户，而是开发者。 彼得，你说得很对！你说得很对。 所以我主张创建这样的库，让那些不熟悉OOP的程序员也能直观地理解。 而这不仅适用于GUI。 在标准库 和Anatoly的库中，要建立一个简单的表格需要花费大量的精力！但是，这并不意味着它就能成功。是真的!向右或向左走一步的例子，就是这样，没有什么作用，你必须了解所有的细节。 当然，在所有的语言中，GUI也是建立在库的基础上，但有一个重要的BUT!有一个最初的控件集，在库的核心层完全 "捆绑 "在一起，所有的基本事件处理程序都是 "连线 "的，剩下的就是在你想改变行为或表现时对它们进行订阅。 从本质上讲，标准库的结构是非常周密的，可以作为更高级的库的基础。 Алексей Барбашин 2020.01.22 13:03 #545 Roman: 华，所以有一个原型可用。 因此，也许开发商应该重新考虑社区的浅薄意见？并恢复发展视觉模式的计划。 当然，这很奇怪，他们把一个本质上备受追捧的功能打消了。 毕竟，现在很少有地方教如何用C语言构建图形界面，如果说还有人教的话。 现在他们教在IDE中用视觉模式工作，由于MT5不再只是一个交易平台。 那么构建图形应用程序的视觉模式将是非常需要的。 说实话，我很震惊，开发者听从了那些反对它的短视者的意见。 还有一些其他令人惊讶的因素：指标是100%的可视化，EA是80%的可视化，脚本是20%的可视化。万事万物都有视觉性，对这一点的理解在于表面。然而，在与其他开发环境的整合上有一个发展，表面上是.... 显然，其他每个终端用户都在要求使用python和sql。 罗曼、彼得、尼古拉...终端开发者有自己的愿景，他们是软件产品的作者和所有者。我猜测ME功能和整个终端的发展是基于市场研究。 但没有人阻止我们说话 :) Реter Konow 2020.01.22 13:24 #546 Алексей Барбашин: 还有一些其他令人惊讶的因素：指标是100%的可视化，EA是80%的可视化，脚本是20%的可视化。任何事物都有视觉性，对这一点的理解在于表面。然而，在与其他开发环境的整合上有一个发展，表面上是.... 显然，每一个其他终端用户都会问到python和sql。 罗曼、彼得、尼古拉...终端的开发者有自己的愿景，他们是软件产品的作者和所有者。我认为，ME功能和一般终端的发展是基于市场研究的。 但没有人阻止我们说话 :) 这就对了。 我的观点是：EA的可视化界面将允许在一个应用程序中积累策略，这将对市场销售产生负面影响。如果每个人都能很容易地创建具有动态策略集的专家顾问（GUI允许这样做），他们目前在市场上的旋转将下降，这将影响销售。在内部整合和修改策略的专家顾问将走到前台，淘汰那些只在设置或少数条件上有差异的克隆。这对市场有好处吗？我不知道。但是，专家顾问的水平将上升，在店面中检查它们将变得更加有趣。 Dmitry Fedoseev 2020.01.22 13:37 #547 Реter Konow: 也许大多数用户希望 CCanvas、CGrafic 和 CCanvas3D 是能够产生所需可视化效果的应用程序，而不是需要 OOP 原理和语法知识的类。而且不仅仅是了解，而且基本上是建立他们自己的可视化系统，就像尼古拉斯所做的。 仅仅了解这些课程是不够的。你需要能够在 "低 "水平上从库中建立你自己的解决方案。你需要成为你自己的开发者。而这是给1%的用户的。 如果给他们提供现成的可视化应用，用户将不再需要学习，但会有更多的人。 有必要吗？我不知道。 你需要知道的op的原理是什么？放一个点并从列表中选择一个方法？ Dmitry Fedoseev 2020.01.22 13:40 #548 aleger: 一个后续问题：在 "最强大 "和 "最简单 "的MQL函数中，有多少和哪些函数 足够编写一个功能齐全且可能是最有利可图的专家顾问。 的世界主要货币对？ 而在座的各位对什么R或Python函数失去了理智，足以写出...？看，你坐的凳子--适合做这个吗...？ Dmitry Fedoseev 2020.01.22 13:41 #549 Roman: 好吧，如果你记得Borland，GUI是在可视化编辑器中组装的，你把控件布局放在面板上，然后你写处理程序。 如果ME有这样的图形化能力，可以直观地构建布局，就会大大简化图形化应用 的构建。 由于大多数现代程序员都学习过GUI建设，他们习惯了（所以他们被教导）可视化的GUI编辑器。 而在纯C风格的代码上建立一个图形应用程序的布局，对他们来说兴趣不大。因为它已经是硬核C风格了。 我们需要一个可视化的编辑器来建立一个图形化的应用程序，然后人们就会急于学习它，那些在VS或RadStudio工作的人，他们甚至很快就能掌握可视化的编辑器。 这里为什么需要他们？ Roman 2020.01.22 13:49 #550 Реter Konow: 这就对了。 我的观点是：EA的可视化界面将允许在一个应用程序中积累策略，这将对市场销售产生负面影响。如果每个人都能很容易地创建具有动态策略集的专家顾问（GUI允许这样做），他们目前在市场上的旋转将下降，这将影响销售。在内部整合和修改策略的专家顾问将走到前台，淘汰那些只在设置或少数条件上有差异的克隆。这对市场会有好处吗？我不知道。但是，EA的水平会越来越高，在展示台上看它们会变得更加有趣。 绝对是一个牵强附会的问题。 策略收集的可视化界面是不必要的，如果你需要骰子，去找tslab。 而且我还看到了生成mql代码的程序，在视觉模式下收集带有立方体的策略。 我们不需要可视化模式来开发交易策略和指标，它真的没有必要。 但对于模块化的图形应用，视觉模式，如你在GIF中所展示的，将是非常有用的。 1...484950515253545556575859606162...93 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
如果你还记得Borland，GUI是在可视化编辑器中组装的，控件的布局被放置在工具栏中，然后你再编写处理程序。
如果ME有这样的图形功能，可以在视觉模式下建立布局，那将使建立图形化的应用程序变得更加容易。
由于大多数现代程序员都学习过GUI建设，他们习惯了（所以他们被教导）可视化的GUI编辑器。
而在纯C风格的代码上建立一个图形应用程序的布局，对他们来说兴趣不大。因为它已经是硬核C风格了。
我们需要一个可视化的编辑器来建立一个图形化的应用程序，然后人们就会急于学习它，那些在VS或RadStudio工作的人，他们甚至很快就能掌握可视化的编辑器。
在这里，MQL中已经有了这样一个可视化编辑器的原型。然而，人们激烈地反对它。他们说在交易中没有必要这样做。
总的来说，他们尽其所能地打击了士气。因此，我不知道社区真正需要什么。
我完全支持需要有能力收集...
但是否有必要是另一个问题。
我不知道开发者自己是否把终端看作是一种交易工具或编程工具？
在这一点上我可能是错的，但我一直认为ME的设计正是为了实现用户需要的交易功能。正是交易!
但如今ME的编程深度已经进入了真正需要能够 "建造 "骰子的领域，并对编程有了非常认真的理解....。
而这最终会导致什么呢？这导致先进的交易工具变得只有有经验的程序员才能使用!
也就是说，如果你不是一个程序员，你在交易中没有任何事情可做...但这是荒谬的。
ME只是一个填补缺失功能的助手，这些功能本应更正确地内置于终端本身（不同的向导）。
而事实上，ME现在正作为一个新的开发环境发展，对用户的知识要求越来越高。
基于这一结论，可视化工具是必要的，但它们的使用应该让没有深厚编程知识的用户也能使用。
只有在这种情况下，他们才会有需求。
这只是我的观点，我并没有把它强加给任何人。
如果你考虑CCanvas类，有大约20个绘制图形基元的功能。假设一个用户知道他们全部，并且知道OOP的规则和语法。然而，这对他的数据的最简单的可视化来说太少了。更不用说创建最简单的控件--一个按钮。也就是说，在画布上绘制基元是比较容易的，但在创建可视化或GUI时使用这些基元则要困难得多。没有知识，你就不能在这里做，没有开发者的才能，你就不能在这里做。但有多少人拥有它？这就是关键问题。
为了发挥Kanvas类的潜力，你需要能够将图形基元组合成更复杂的对象（控件），将它们的操作与事件驱动模型结合起来，用函数编写关系。或者，将数字数据转换为不同的图形曲线...这是一份适合有天赋和非常努力工作的用户的工作。事实上，不是用户，而是开发者。
在这里，MQL中已经有了这样一个可视化编辑器的原型。然而，人们激烈地反对它。他们说在交易中没有必要这样做。
总的来说，他们尽其所能地打击了士气。因此，我不知道社区真正需要什么。
哇，所以有了一个原型。
因此，也许开发商应该重新考虑社区的浅薄意见？并恢复发展视觉模式的计划。
当然，让一个本质上备受追捧的功能失去士气，这有点奇怪。
现在很少有地方会教如何用C语言构建图形界面，如果有的话，他们还在教。
现在，每个人都被教导要用可视化模式在IDE中工作，由于MT5早已不仅仅是交易平台，
，构建图形化应用程序的可视化模式将有很大需求。
说实话，我很震惊，开发者听从了那些反对它的短视者的意见。
如果我们考虑CCanvas类，大约有20个函数用于绘制图形基元。假设用户都知道它们，并且知道OOP规则和语法。然而，直到其数据的最简单的可视化 - 它是太少了。更不用说创建最简单的控件--一个按钮。也就是说，在画布上绘制基元是比较容易的，但在创建可视化或GUI时使用这些基元则要困难得多。没有知识，你就不能在这里做，没有开发者的才能，你就不能在这里做。但有多少人拥有它？这就是关键问题。
为了发挥Kanvas类的潜力，你需要能够将图形基元组合成更复杂的对象（控件），将它们的操作与事件驱动模型绑定，用函数编写关系。或者，将数字数据转换为不同的图形曲线...这是一份适合有天赋和非常努力工作的用户的工作。事实上，不是用户，而是开发者。
彼得，你说得很对！你说得很对。
所以我主张创建这样的库，让那些不熟悉OOP的程序员也能直观地理解。
而这不仅适用于GUI。
在标准库 和Anatoly的库中，要建立一个简单的表格需要花费大量的精力！但是，这并不意味着它就能成功。是真的!向右或向左走一步的例子，就是这样，没有什么作用，你必须了解所有的细节。
当然，在所有的语言中，GUI也是建立在库的基础上，但有一个重要的BUT!有一个最初的控件集，在库的核心层完全 "捆绑 "在一起，所有的基本事件处理程序都是 "连线 "的，剩下的就是在你想改变行为或表现时对它们进行订阅。
从本质上讲，标准库的结构是非常周密的，可以作为更高级的库的基础。
华，所以有一个原型可用。
因此，也许开发商应该重新考虑社区的浅薄意见？并恢复发展视觉模式的计划。
当然，这很奇怪，他们把一个本质上备受追捧的功能打消了。
毕竟，现在很少有地方教如何用C语言构建图形界面，如果说还有人教的话。
现在他们教在IDE中用视觉模式工作，由于MT5不再只是一个交易平台。
那么构建图形应用程序的视觉模式将是非常需要的。
说实话，我很震惊，开发者听从了那些反对它的短视者的意见。
还有一些其他令人惊讶的因素：指标是100%的可视化，EA是80%的可视化，脚本是20%的可视化。万事万物都有视觉性，对这一点的理解在于表面。然而，在与其他开发环境的整合上有一个发展，表面上是....
显然，其他每个终端用户都在要求使用python和sql。
罗曼、彼得、尼古拉...终端开发者有自己的愿景，他们是软件产品的作者和所有者。我猜测ME功能和整个终端的发展是基于市场研究。
但没有人阻止我们说话 :)
还有一些其他令人惊讶的因素：指标是100%的可视化，EA是80%的可视化，脚本是20%的可视化。任何事物都有视觉性，对这一点的理解在于表面。然而，在与其他开发环境的整合上有一个发展，表面上是....
显然，每一个其他终端用户都会问到python和sql。
罗曼、彼得、尼古拉...终端的开发者有自己的愿景，他们是软件产品的作者和所有者。我认为，ME功能和一般终端的发展是基于市场研究的。
但没有人阻止我们说话 :)
这就对了。
我的观点是：EA的可视化界面将允许在一个应用程序中积累策略，这将对市场销售产生负面影响。如果每个人都能很容易地创建具有动态策略集的专家顾问（GUI允许这样做），他们目前在市场上的旋转将下降，这将影响销售。在内部整合和修改策略的专家顾问将走到前台，淘汰那些只在设置或少数条件上有差异的克隆。这对市场有好处吗？我不知道。但是，专家顾问的水平将上升，在店面中检查它们将变得更加有趣。
也许大多数用户希望 CCanvas、CGrafic 和 CCanvas3D 是能够产生所需可视化效果的应用程序，而不是需要 OOP 原理和语法知识的类。而且不仅仅是了解，而且基本上是建立他们自己的可视化系统，就像尼古拉斯所做的。
你需要知道的op的原理是什么？放一个点并从列表中选择一个方法？
一个后续问题：在 "最强大 "和 "最简单 "的MQL函数中，有多少和哪些函数
足够编写一个功能齐全且可能是最有利可图的专家顾问。
的世界主要货币对？
而在座的各位对什么R或Python函数失去了理智，足以写出...？看，你坐的凳子--适合做这个吗...？
好吧，如果你记得Borland，GUI是在可视化编辑器中组装的，你把控件布局放在面板上，然后你写处理程序。
如果ME有这样的图形化能力，可以直观地构建布局，就会大大简化图形化应用 的构建。
由于大多数现代程序员都学习过GUI建设，他们习惯了（所以他们被教导）可视化的GUI编辑器。
而在纯C风格的代码上建立一个图形应用程序的布局，对他们来说兴趣不大。因为它已经是硬核C风格了。
我们需要一个可视化的编辑器来建立一个图形化的应用程序，然后人们就会急于学习它，那些在VS或RadStudio工作的人，他们甚至很快就能掌握可视化的编辑器。
这里为什么需要他们？
这就对了。
我的观点是：EA的可视化界面将允许在一个应用程序中积累策略，这将对市场销售产生负面影响。如果每个人都能很容易地创建具有动态策略集的专家顾问（GUI允许这样做），他们目前在市场上的旋转将下降，这将影响销售。在内部整合和修改策略的专家顾问将走到前台，淘汰那些只在设置或少数条件上有差异的克隆。这对市场会有好处吗？我不知道。但是，EA的水平会越来越高，在展示台上看它们会变得更加有趣。
绝对是一个牵强附会的问题。
策略收集的可视化界面是不必要的，如果你需要骰子，去找tslab。
而且我还看到了生成mql代码的程序，在视觉模式下收集带有立方体的策略。
我们不需要可视化模式来开发交易策略和指标，它真的没有必要。
但对于模块化的图形应用，视觉模式，如你在GIF中所展示的，将是非常有用的。