Вы уверены? Мне кажется, что LEN не умеет отдавать больше, чем 255.
См.рис:
Вложение 64378
ПС: bOlolo объявлена как dword. Тупо забыл имя поменять на dwOlolo.
Вид для печати
Вы уверены? Мне кажется, что LEN не умеет отдавать больше, чем 255.
См.рис:
Вложение 64378
ПС: bOlolo объявлена как dword. Тупо забыл имя поменять на dwOlolo.
Странно. Не заметил ее сразу.
Протестировал.
Она работала бы. Но вот длину строки 16000 символов она не принимает. Возвращает пустой результат.
А при длине строки 50 символов - работает нормально.
Может это как-то связано с тем, что используется не срока, а указатель на буфер?
Вообще, размер буфера при вызове функции задается в виде переменной типа INT, так что его максимальное значение 32767 байт.
Ваши строки по размеру близки к граничным значениям - например, склеить две строки по 16000 символов с помощью этой функции не получится.
Один из вариантов решения проблемы предложил выше capzap.
Альтернативный - использовать эту библиотеку:
https://dropmefiles.com/3g5BL
В ней есть своя версия функции StrConcatW, где буфер уже типа UDINT и есть ФБ StringWriter, который предназначен как раз для склеивания длинных строк.
Хорошо. Попробую этот метод.
Создаю массив и указатель:
arrDataSend : ARRAY[1..20000] OF BYTE; // Буфер для отправки
wPointer : WORD := 0; // Указатель для накидывания новых строк в буфер
wsLine01 : WSTRING := "Строка с кириллицей номер 01"; // Наша первая строка
wsLine02 : WSTRING := "Строка с кириллицей номер 02"; // Наша вторая строка
wsLine03 : WSTRING := "Строка с кириллицей номер 03"; // Наша третья строка
Программа по склеиванию:
// Первая строка:
MEM.MemMove(ADR(wsLine01), ADR(arrDataSend[wPointer]), len(wsLine01));
wPointer := wPointer + (len(wsLine01) * 2);
// Вторая строка:
MEM.MemMove(ADR(wsLine02), ADR(arrDataSend[wPointer]), len(wsLine02));
wPointer := wPointer + (len(wsLine02) * 2);
// Третья строка:
MEM.MemMove(ADR(wsLine03), ADR(arrDataSend[wPointer]), len(wsLine03));
wPointer := wPointer + (len(wsLine03) * 2);
// Отправка на сервер:
...
fbTcpWrite(xExecute:=TRUE, hConnection:=fbTcpClient.hConnection, pData:=ADR(arrDataSend), szSize:=wPointer);
...
Указатель каждый раз инкрементируется на len*2 (из-за WSTRING) и каждая следующая строка начинает ложиться в буфер по новому значению.
Тут есть вопрос: len не хочет отдавать длину строки, если она wstring. Видимо, len работает только со string. Какая функция отдаст длину wstring?
И вообще, я правильно понял предложенную реализацию?
Спасибо.
сложно это передать словами, проектом тоже конкретно надо заниматься чтоб сделать его обучающим, ловите мою тестовую если разберетесь хорошо
Я не пользуюсь wstring потому что в КДС2 их нет, но суть в том что каждую строку и указатель на неё надо задавать с фиксированным количеством символов, тогда в массив они будут попадать в нужные места занимая столько байт сколько нужно
Использовать массив вместо строки получилось. И массив этот склеивается нормально (по указателю раз за разом).
Я проверяю это: запускаю обратную функцию MEM.MemMove() и собираю из массива переменную. В этой переменной вижу склеенные части. (в отладке. Строка видна и читабельна. А массив - это набор кодов: там хрен-читаемо...)
В массиве каждый байт занимает две ячейки. Это ведь аналог wstring. Поэтому так.
Но вот на сервер этот массив не отправляется. Или отправляется неправильно.
Я сделал тестовую короткую строку (около 80 символов), на которую сервер гарантированно отвечает коротким тестовым ответом.
Этот ответ не приходит. Увы.
Тут загвоздка:
fbTcpWrite(xExecute:=TRUE, hConnection:=fbTcpClient.hConnection, pData:=ADR(arrDataSend[1]), szSize:=wPointer+2);
Раньше там была ссылка на строку и это работало:
fbTcpWrite(xExecute:=TRUE, hConnection:=fbTcpClient.hConnection, pData:=ADR(sDataSend), szSize:=TO_DWORD(STU.StrLenA(ADR(sDataSend)) + 1));
Ну откуда же нам знать просто по тексту, хотя бы онлайн показывали. А так зачем к длине прибавляет двойку, не выходит ли это за диапазон массива и соответственно ошибочная отправка.
не встретил проблем и с wstring
на скрине то что получает ПК с контроллера и сам проект во вложении
Вложение 64494
Спасибо. Буду разбираться.