Troca de dados entre dois EAs funcionando em terminais diferentes - página 4

Novo comentário
 

Uma alternativa para o registro é o simples compartilhamento de arquivos. (quero dizer sistema de arquivo NTFS)

Há 2 terminais c:\mt1, c:\mt2 em cada um deles, é claro, os arquivos dos especialistas

Criar c:\mt1=peritos c:\mt2=peritos c:\mt1=peritos c:\mt2=peritos c:\mt2=peritos

Criar comando linkd a partir do Windows Server 2003 Resource Kit Tools (para vencer 2000,2003,xp) em vista MKLINK

linkd.exe c:\mt1=peritos troca de arquivosc :\mt2=peritos troca de arquivos

este é agora um diretório compartilhado com os terminais. (Copie qualquer arquivo para o c:\mt1{files}experts}exchangee navegue para o c:\mt2{files}experts}exchange )

o mesmo pode ser feito usando Far - Alt F6.

 
JavaDev >> :

Uma alternativa para o registro é o simples compartilhamento de arquivos. (quero dizer sistema de arquivo NTFS)

Há 2 terminais c:\mt1, c:\mt2 em cada um deles, é claro, os arquivos dos especialistas

Criar c:\mt1=peritos c:\mt2=peritos c:\mt1=peritos c:\mt2=peritos c:\mt2=peritos

Criar comando linkd a partir do Windows Server 2003 Resource Kit Tools (para vencer 2000,2003,xp) em vista MKLINK

linkd.exe c:\mt1=peritos troca de arquivosc :\mt2=peritos troca de arquivos

este é agora um diretório compartilhado com os terminais. (Copie qualquer arquivo para o c:\mt1{files}experts}exchangee navegue para o c:\mt2{files}experts}exchange )

você pode fazer o mesmo com Far - Alt F6.

Ainda assim, a comunicação através de arquivos não é a ferramenta correta. Não é a correta.

Os arquivos são inventados para o armazenamento de informações a longo prazo. Por que se preocupar com um disco? Existe RAM para a comunicação.

 
Andres >> :

Depois disso, é recebido:

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(): Foi criada uma divisória inexistente.
2009.05.19 01:22:16 temp começou os testes

Ou seja, o conteúdo do buffer não muda, embora não ocorram erros ao ligar. E o registro contém exatamente a seqüência "Test".

Dos posts do fórum entendi que isso acontece por causa da passagem de strings incomuns do ambiente MQL para as funções DLL. No ambiente MQL os desenvolvedores operam com strings usando seu próprio gerente (string pool), e aparentemente nesta borda o buffer errado é preenchido e, portanto, não podemos ver o resultado retornado pela função API. Mas se usarmos cordas inicializadas em todo o comprimento máximo, então, até onde posso ver, não há problema. É por isso que a cadeia de 255 caracteres "#" está lá. O caracter "#" foi escolhido simplesmente para tornar a corda visível aos olhos. Não tem nada a ver com o próprio Win API, porque não importa com o que o buffer é preenchido antes da chamada. Esta é a limitação do comprimento das cordas que mencionei anteriormente. Você pode passar cordas com mais de 255 caracteres em SetStringValue() mas não conseguirá lê-las.

É claro que é bom não ter limitações, mas não vejo como isso seja um grande inconveniente. Isso levanta a questão: por que você precisa ler um fio de um determinado tamanho? Se se tratar de restrições, você pode contorná-las escrevendo uma função que divide a cadeia de entrada em N parâmetros que são 255 de comprimento + parâmetro "restante". E quando o lê recolhe de volta. Não há outra maneira. Se você tiver dificuldade, por favor, entre em contato comigo, eu o farei. Simplesmente, todos têm necessidades diferentes, não podemos fornecer tudo, para mim é suficiente apenas isto, e alguém usa variáveis globais, e até mesmo em vários níveis.

Estou confuso... Onde está o limite de 255 caracteres? Sei de fato que não existe tal restrição na MQL4.

O código de exemplo foi uma dica sutil no ponto :-))

 
Zhunko >> :

Ainda assim, a comunicação através de arquivos não é a ferramenta correta. Não é a ferramenta correta.

Os arquivos são inventados para armazenar informações por um longo período de tempo. Por que atormentar o disco? Existe RAM para a comunicação.

Eu concordo parcialmente com você.

Através da RAM você pode, mas é difícil (afinal de contas, o fórum não é 100% programadores de sistemas e nem mesmo 50%).

E se você olhar um pouco mais amplo - em unix - todos os arquivos e RAM e discos e processos.

Eu acabei de sugerir 1 de muitas maneiras.

 
Zhunko >> :

Eu não entendo... Onde está o limite de 255 caracteres? Sei de fato que não há tal limitação na MQL4.

A amostra de código foi uma dica sutil na essência da questão :-))

Bem, quando durante a execução do programa você incrementa uma corda, não há nenhuma restrição, mas então ela acaba por não ser mais uma constante de corda. A documentação é muito clara sobre o comprimento das constantes das cordas :

O comprimento constante da corda é de 0 a 255 caracteres. Se a constante da corda exceder o comprimento máximo, os caracteres desnecessários serão truncados para a direita e o compilador gerará o aviso correspondente.

 
Andres >> :

Bem, não há limitação quando você aumenta a string durante a execução do programa, mas então ela não é mais uma constante de string. Está claramente escrito aqui na documentação sobre o comprimento das constantes das cordas:

Em nosso caso, não importa se é uma constante ou não.

Então você pode fazer mais com uma variável?

 
Zhunko >> :

Em nosso caso, não importa se é uma constante ou não.

Então você pode fazer mais, com uma variável?

Por que isso não importa? A questão é que é importante (!), porque com um buffer como uma chamada API de string constante funciona como deveria, e com um buffer de chamada API de string criada "dinamicamente" funciona sem erros, mas não observamos os dados do registro nesta string, pelas razões descritas anteriormente.


Andres escreveu >>
Quando durante a execução do programa você deve aumentar a string, ela não tem limite, mas então ela acaba não sendo constante da string. A documentação diz claramente sobre o comprimento das constantes das cordas:

Aqui eu estava falando da limitação do comprimento das cordas, não da limitação da biblioteca.

Tente obter dados do registro com string constante e com string dinamicamente incrementada e você verá a diferença. No primeiro caso, os dados chegam, no segundo, não chegam.

 
Andres >> :

Aqui eu estava falando da limitação do comprimento das cordas, não da limitação da biblioteca.

Tente recuperar os dados do registro usando uma string constante e dinamicamente incrementada, e você verá a diferença. No primeiro caso os dados são recebidos, no segundo caso não.

>>...esquisito!... Então, afinal é importante onde na função a memória é alocada?

 

A melhor maneira de trocar dados entre programas, IMHO, é através de arquivos virtuais:

// Открываем объект-отображение 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;

}

//---

e assim por diante.....

Tudo funciona de forma confiável e sem falhas.... Testado eletronicamente :)

 
klot >> :

A melhor maneira de trocar dados entre programas, IMHO, é através de arquivos virtuais:

e assim por diante.....

Tudo funciona de forma confiável e sem falhas.... Testado eletronicamente :)

Absolutamente certo. O FileMapping é uma ótima ferramenta, embora não seja a mais fácil. Você também poderia tentar tubos ou mailslots.

12345678
Novo comentário