Обмен данными между двумя советниками, работающими в разных терминалах - страница 4

Новый комментарий
 

Как альтернатива терзанию реестра - простой файловый обмен. (подрузамеваю что файловая система NTFS)

Есть 2 терминала c:\mt1, c:\mt2 в  каждом естественно \experts\files

создаём папки обмена c:\mt1\experts\files\exchange c:\mt2\experts\files\exchange

создаём link командой linkd из пакета Windows Server 2003 Resource Kit Tools (для win 2000,2003,xp) в vista MKLINK

linkd.exe  c:\mt1\experts\files\exchange  c:\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

создаём link командой linkd из пакета Windows Server 2003 Resource Kit Tools (для win 2000,2003,xp) в vista MKLINK

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

теперь это обший каталог у терминалов. (закопируйте любой фвйл в c:\mt1\experts\files\exchange и просмотрите каталог  c:\mt2\experts\files\exchange )

тоже самое можно проделать при помощи Far - Alt F6.

Всё-таки, общение через файлы это не тот инструмент. Не по назначению.

Файлы придуманы для длительного хранения информации. Зачем терзать диск? Для общения есть ОЗУ.

 
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 temp started for testing

То есть содержимое буфера не меняется, хотя ошибок при вызове не происходит. И в реестре содержится именно строка "Test"

Из сообщений на форуме, я понял, что это происходит из-за необычной передачи строк из среды MQL в функции DLL. В среде MQL разработчики оперируют строками при помощи своего собственного менеджера (строкового пула), и видимо на этой границе происходит заполнение не того буфера, и поэтому мы не можем видеть результат возвращаемый API-функцией. Но если использовать строки, инициализированные во всю максимальную длину, то, на сколько мне ясно, проблем не возникает. Именно поэтому там строка на 255 символов "#". Символ "#" был выбран просто для того чтобы строка была заметна глазу. К самим Win API это не имеет никакого отношения, так как не важно чем буфер заполнен до вызова. В этом и ограничение на длину строки о котором я говорил раньше. Вот передавать в SetStringValue() можно строки бОльшие, чем 255 символов, но прочитать их не получится.

Конечно хорошо, когда ограничений нету, но особого неудобства не вижу. Возникает вопрос: зачем Вам чтение строки заданного размера ? Если дело в ограничении, то и его можно обойти, просто написав функцию, которая при записи в реестр разбивает исходную строку на N параметров длинной по 255 + "остаточный" параметр. А при чтении - собирает обратно. По другому вроде никак. Если затрудняетесь, то обращайтесь - сделаю. Просто потребности у всех разные, всего не предусмотришь, мне хватает только этого, а кто-то использует глобальные переменные, да ёщё и на нескольких уровнях.

Не понял... Где находиться ограничение в 255 знаков? Точно знаю, что в MQL4 такого ограничения нет.

Пример кода был тонким намёком на суть вопроса :-))

 
Zhunko >>:

Всё-таки, общение через файлы это не тот инструмент. Не по назначению.

Файлы придуманы для длительного хранения информации. Зачем терзать диск? Для общения есть ОЗУ.

Отчасти с Вами согласен.

Через ОЗУ можно - но сложно (всётаки на форуме не 100 % программисты системщики и даже не 50 %).

А если посмотреть чуть ширее - в unix - там всё файлы и RAM и диски и процессы.

Я просто предложил 1 из множества путей.

 
Zhunko >>:

Не понял... Где находиться ограничение в 255 знаков? Точно знаю, что в MQL4 такого ограничения нет.

Пример кода был тонким намёком на суть вопроса :-))

Ну когда в процессе выполнения программы наращиваешь строку - то ограничения нету, но тогда она получается уже не строковая константа. А про длину строковых констант тут, в документации ясно сказано:

Длина строковой константы - от 0 до 255 символов. Если длина строковой константы превосходит максимальную, лишние символы справа отбрасываются, и компилятор выдает соответствующее предупреждение.

 
Andres >>:

Ну когда в процессе выполнения программы наращиваешь строку - то ограничения нету, но тогда она получается уже не строковая константа. А про длину строковых констант тут, в документации ясно сказано:

В нашем случае не важно константа она или нет.

Значит можно больше, с помощью переменной?

 
Zhunko >>:

В нашем случае не важно константа она или нет.

Значит можно больше, с помощью переменной?

Почему не важно ? В том то и дело что важно (!), так как с буфером в виде константой строки вызов API работает как положено, а с буфером "динамически" созданной строки вызов API работает без ошибок, но данных из реестра в этой строке мы не наблюдаем, по описанным ранее причинам.


Andres писал(а) >>
Ну когда в процессе выполнения программы наращиваешь строку - то ограничения нету, но тогда она получается уже не строковая константа. А про длину строковых констант тут, в документации ясно сказано:

Тут я говорил про ограничение длины строки, а не про ограничение библиотеки.

Попробуйте сами получить данные из реестра при помощи строковой константы, и при помощи динамически увеличенной строки, и увидите разницу. В первом случае данные приходят, во втором - нет.

 
Andres >>:

Тут я говорил про ограничение длины строки, а не про ограничение библиотеки.

Попробуйте сами получить данные из реестра при помощи строковой константы, и при помощи динамически увеличенной строки, и увидите разницу. В первом случае данные приходят, во втором - нет.

Чудно!... Получается, что важно в каком месте функции выделяется память?

 

Самый лучший способ обмена данными между программами, ИМХО, через виртуальные файлы:

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

Самый лучший способ обмена данными между программами, ИМХО, через виртуальные файлы:

и так далее.....

Всё работает надежно и без глюков.... Проверенно электроникой :)

Совершенно верно. FileMapping замечательный, хоть и не самый простой, инструмент. Можно ещё pipes или mailslots попробовать.

12345678
Новый комментарий