我的方法。核心是引擎。 - 页 86

新评论
 
彼得，我从椭圆的GIF中了解到，该表格是一个固体画布？那么下拉列表是如何工作的呢？我对下拉列表超过表单大小的情况感兴趣。
 
Vasiliy Sokolov:

让我这样说吧--我自己也不喜欢我的解决方案中的一些马虎。你必须创建MT对象。但是，在现实中，这只是一种偏见。这有什么区别呢？你不需要超过20-30个，就可以完成一个完整的转移。

30*64个字符=1920个字符。这足以传输大型表格数据。

 
Dmitry Fedoseev:
彼得，我从椭圆GIF中看到，表格是一个连续的画布？那么下拉列表是如何工作的呢？我对下拉列表超过表单大小的情况感兴趣。

是的，该表格是一个单一的kanvas。构造函数写下画布本身的名字，并制作包装函数与之配合。

下拉列表在窗口外的区域也可以工作。这一点已经落实。

下拉列表是另一个kanvas。当按钮被点击时，它就会出现并消失。

 
Vasiliy Sokolov:

通过联合体直接映射结构到字节数组，为全局访问共享。我不知道这在技术上是否可行，但如果是这样，速度将是宇宙级的，因为你根本不需要复制任何东西。

如果你提供一个例子，我很乐意接受这个解决方案。

 

对通过图形对象进行的数据交换 要慎重 :-)

否则，你可以很容易地使你的专家顾问看起来像 "无法优化"...

 
Реter Konow:

我的解决方案是在初始条件下的最佳选择。

什么是字符串。

  1. 没有固定的尺寸。因此，不可能组织一个字符串的数组，也不可能访问该数组中的任意一个字符串。
  2. 完全没有字符串的数据输入。你必须在字符串解析里面动态地定义一个子类型。你把宝贵的时间浪费在解析需要的标记上；而且，如果词组包含错误，字符串也不会以任何方式控制它。你得到一个字符串并祈祷它是正确的。
  3. 每一字节的信息存储效率低。像 "opt=1;cancel=3 "这样的服务字符串最多使用256个可能的字符（字节）中的35-40个（17%）。为了发送100字节的信息，你应该形成一个588字节的字符串，使通信通道超载。如果你压缩字符，会使代码非常复杂。如果你缩写变量名称，它只能起到一点作用。

尽管有这些显而易见的事情，你却像罗宾汉 一样，仍然宣称你有多快多准，你猜的弦有多好。不，我没有，而且这都是很不健康的。

在需要基本知识的地方，不要试图驾驭你的直觉。

 
Vasiliy Sokolov:

什么是字符串。

  1. 没有固定的尺寸。因此，不可能组织一个字符串的数组，也不可能访问该数组中的任意一个字符串。
  2. 在字符串中完全没有数据输入。你必须在字符串解析里面动态地定义一个子类型。你把宝贵的时间浪费在解析需要的标记上；而且，如果词组包含错误，字符串也不会以任何方式控制它。你得到一个字符串并祈祷它是正确的。
  3. 每个字节的信息存储效率低。像 "opt=1;cancel=3 "这样的服务字符串最多使用256个可能的字符（字节）中的35-40个（17%）。为了发送100字节的信息，你应该形成一个588字节的字符串，使通信通道超载。如果你压缩字符，会使代码非常复杂。如果你缩写变量名称，它只能起到一点作用。

尽管有这些显而易见的事情，你却像罗宾汉 一样，仍然宣称你有多快多准，你猜的弦有多好。不，我没有，而且这都是很不健康的。

在你需要了解基本原理的地方，不要试图驾驭你的直觉。

Vasily，你不认为MT开发者在保留MT对象的描述时考虑到了字符串的问题吗？

骑在别人的基本知识上，用你的直觉来实现更多的目标，这要酷得多。

 
Реter Konow:

Vasiliy，你不认为MT开发者在存储MT对象描述时，考虑到了字符串的问题吗？

彼得，每一种数据存储算法都有其弱点和优势。开发者当然考虑到了很多事情，他们当然也很好，但从根本上说，字符串永远是字符串。

 
Vasiliy Sokolov:

彼得，每种数据存储算法都有其弱点和优势。当然，开发者考虑到了很多东西，它们当然是好的，但从根本上说，字符串将永远是字符串。

瓦西里，如果实践表明我的解决方案有缺陷，我将放弃它。而我将采取尼古拉的解决方案。如果它也不好，我就会返回OnChartEvent()，说什么也不能做。

然而，还没有理由相信我的解决方案的实施会很逊色。

我们很快就会知道了。

 
z.s. 具体到在MT对象中存储字符串的问题，有一个奇怪的故障。如果你开始压缩数据并在对象名称中使用不可打印的字符，在某些情况下你将无法访问该对象。这个故障可能仍然存在，因为它非常特殊，没有多少人知道它，但你还是可能偶然发现它。
1...798081828384858687888990919293...184
新评论