在不同终端中运行的两个EA之间交换数据 - 页 4

新评论
 

注册表的一个替代方案是简单的文件共享。(我指的是NTFS文件系统)

有2个终端c:\mt1，c:\mt2，在他们每个人中当然都有experts\files

创建c:\mt1\experts\files\exchange c:\mt2\experts\files\exchange

从Windows Server 2003资源 包工具 中创建linkd命令（适用于win 2000,2003,xp）在vista MKLINK中。

linkd.exe c:\mt1\experts\files\exchangec:\mt2\experts\files\exchange

现在这是一个与终端共享的目录。(复制任何文件到c:mt1\experts\files\exchange并浏览 到 c:mt2\experts\files\exchange )

同样可以用Far - Alt F6来完成。

 
JavaDev >> :

注册表的一个替代方法是简单的文件共享。(我指的是NTFS文件系统)

有2个终端c:\mt1，c:\mt2，在他们每个人中当然都有experts\files

创建c:\mt1\experts\files\exchange c:\mt2\experts\files\exchange

从Windows Server 2003资源 包工具 中创建linkd命令（适用于win 2000,2003,xp）在vista MKLINK中。

linkd.exe c:\mt1\experts\files\exchangec:\mt2\experts\files\exchange

现在这是一个与终端共享的目录。(复制任何文件到c:mt1\experts\files\exchange并浏览 到 c:mt2\experts\files\exchange )

你可以用Far - Alt F6做同样的事情。

不过，通过文件进行沟通并不是正确的工具。不是正确的。

文件是为长期储存信息而发明的。为什么要用一个磁盘呢？有RAM用于通信。

 
Andres >> :

之后，它被接收。

2009.05.19 01:22:16 2008.12.31 01:49 temp EURUSD,M1: ####
2009.05.19 01:22:16 2008.12.31 01:49 temp EURUSD,M1: RegCreateKeyExA(): 一个不存在的分区被创建。
2009.05.19 01:22:16 开始测试的临时程序

也就是说，缓冲区的内容没有变化，尽管调用时没有发生错误。而注册表正好包含 "测试 "字符串

从论坛 的帖子中我了解到，它的发生是因为从MQL环境到DLL函数的不寻常的字符串传递。在MQL环境中，开发人员使用他们自己的管理器（字符串池）对字符串进行操作，显然，在这个边界上，错误的缓冲区被填充，因此我们无法看到API-函数返回的结果。但如果我们使用初始化为整个最大长度的字符串，那么，就我所见，就没有问题了。这就是为什么有255个字符的 "#"字符串的原因。选择 "#"字符只是为了让眼睛看到这个字符串。这与Win API本身没有关系，因为在调用之前，缓冲区被填满了什么并不重要。这就是我前面提到的字符串长度限制。你可以将超过255个字符的字符串传入SetStringValue()，但它将无法读取这些字符串。

当然，没有限制是好事，但我不认为这有什么大的不便。这就引出了一个问题：为什么你需要读取一个特定大小的字符串？如果是关于约束，你可以通过编写一个函数将输入字符串分割成N个长度为255+"余数 "的参数来绕过它们。而在阅读时，它又把它收集起来。没有其他办法。如果你有困难，请与我联系，我会做到的。很简单，每个人都有不同的需求，我们不可能提供所有的东西，对我来说只有这些就足够了，有人使用全局变量，甚至在几个层面上。

我很迷惑...255个字符的限制在哪里？我知道的是，在MQL4中没有这样的限制。

示例代码是一个微妙的提示点:-))

 
Zhunko >> :

不过，通过文件进行沟通并不是正确的工具。不是正确的工具。

文件的发明是为了长期储存信息。为什么要折磨这个磁盘？有RAM用于通信。

我部分同意你的观点。

通过RAM可以，但很难（毕竟论坛不是100%的系统程序员，甚至不是50%）。

如果你看得宽一点--在unix中--所有的文件、内存、磁盘和进程。

我只是提出了许多方法中的一种。

 
Zhunko >> :

我不明白...255个字符的限制在哪里？我知道的是，在MQL4中没有这种限制。

代码样本是对问题本质的一个微妙提示 :-))

那么，在程序执行过程中，当你递增一个字符串时，没有任何限制，但后来发现它不再是一个字符串常数了。文档中对字符串常数的长度有非常明确的规定。

字符串常数的长度从0到255个字符。如果字符串常数超过了最大长度，不必要的字符将被向右截断，编译器将产生相应的警告。

 
Andres >> :

好吧，当你在程序执行过程中增加字符串时，没有任何限制，但那时它就不再是一个字符串常数了。这里 清楚地写着关于字符串常数的长度的文档。

在我们的案例中，它是否是一个常数并不重要。

所以你可以用一个变量做更多的事情？

 
Zhunko >> :

在我们的案例中，是否是常数并不重要。

所以你可以做得更多，用一个变量？

为什么这不重要？重点是这很重要（！），因为用一个常量字符串的缓冲区，API调用可以正常工作，而用一个 "动态 "创建的字符串的缓冲区，API调用可以正常工作，没有错误，但我们没有观察到这个字符串中的注册表数据，原因如前所述。


安德烈写道 >>
在程序执行过程中，你必须增加字符串，它没有限制，但后来发现它不是字符串常数。文档中说，它对字符串常量的长度很清楚。

这里我说的是字符串的长度限制，而不是库的限制。

试着用字符串常数和动态递增的字符串从注册表中获取数据，你会看到区别。在第一种情况下，数据进来了，在第二种情况下，它没有。

 
Andres >> :

这里我说的是字符串的长度限制，而不是库的限制。

试着用字符串常数和动态递增的字符串从注册表中检索数据，你会看到其中的区别。在第一种情况下收到了数据，在第二种情况下没有收到。

>>...奇怪！...那么，事实证明，在函数中的哪个位置分配内存是重要的？

 

IMHO，在程序之间交换数据 的最佳方式是通过虚拟文件。

// Открываем объект-отображение FILE_MAP_READ

hMMF = OpenFileMapping( FILE_MAP_WRITE, FALSE, lpFileShareName);

// Если открыть не удалось, выводим код ошибки

if( hMMF == NULL) {

MessageBox(NULL,"OpenFileMapping: Error","RealTimeData", MB_OK );

return 0;

}

// Выполняем отображение файла на память FILE_MAP_READ 

// В переменную lpMMF будет записан указатель на отображаемую область памяти

lpMMF = MapViewOfFile( hMMF, FILE_MAP_WRITE,0,0,sizeof( NSDTfeedTick));

// Если выполнить отображение не удалось, выводим код ошибки

if( lpMMF == 0) {

MessageBox(NULL,"MapViewOfFile: Error","RealTimeData", MB_OK );

return 0;

}

//---

等等.....

一切工作都很可靠，没有故障....经过电子测试 :)

 
klot >> :

IMHO，在程序之间交换数据的最佳方式是通过虚拟文件。

等等.....

一切工作都很可靠，没有故障....经过电子测试 :)

完全正确。FileMapping是一个很好的工具，虽然不是最简单的。你也可以尝试管道或邮件槽。

12345678
新评论