Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

TServerSocket.ReceiveText в Delphi 2009 возвращает '????????...'


Страницы:   1 2

d@vinchi ©   (2009-09-09 19:01:00) 

В delphi 2009 тип строк по умолчанию юникоидный, но попытки привести полученную строку от TServerSocket.ReceiveText к нормальному виду пока никчекму не привели...
Кто сталкивался с этой траблой - как решить?


evgeny2k   (2010-03-01 12:32:00) [1]

Я бы вот так написал (работает)

var
sReceiveText: AnsiString;
...
SetLength(sReceiveText, Socket.ReceiveLength());
SetLength(sReceiveText, Socket.ReceiveBuf(Pointer(sReceiveText)^, Length(sReceiveText)));

Или под Билдером
AnsiString _Str;

_Str.SetLength(Socket->ReceiveLength());
Socket->ReceiveBuf(_Str.c_str(), _Str.Length());
RichEdit1->Lines->Add(_Str);
Эх, не спроста они эти компоненты на палитру по-умолчанию не вывели...


Anatoly Podgoretsky   (2009-09-11 11:08:00) [2]

> d@vinchi  (10.09.2009 17:41:20)  [20]

Строки они разные бывают и они разные все поддержаны, включая utf-8


Сергей М.   (2009-09-11 08:31:00) [3]


> теперь про String вообще нужно забыть?


В данном контексте String если и можно использовать, то совсем не так - ты в этом убедился, уведев "вопросы".


d@vinchi   (2009-09-10 17:43:00) [4]


> > var
> > sReceiveText: String;

это я скопипастил так, там естественно AnsiString...


d@vinchi   (2009-09-10 17:41:00) [5]

т.е. теперь про String вообще нужно забыть?


Сергей М.   (2009-09-10 17:03:00) [6]


> var
> sReceiveText: String;


Да почему же опять String, а не AnsiString ?


d@vinchi   (2009-09-10 16:55:00) [7]

Спасибо в очередной раз! переписывать метод не стал т.к. используется в только одном месте, траблу решил так:

var
sReceiveText: String;
...
 SetLength(sReceiveText, Socket.ReceiveBuf(Pointer(nil)^, -1));
 SetLength(sReceiveText, Socket.ReceiveBuf(Pointer(sReceiveText)^, Length(sReceiveText)));
...

далее работаем со строкой sReceiveText как обычно. Странно что эта ошибка даже в последних обновлениях на BDS 2009 не исправлена...


> Поскольку кроме ошибки с типом, также еще и SetLenght неверен,
>  итого в функии правильны только две строки, это BEGIN и
> END
> и таких мест множество, практически в каждой сетевой функции,
>  если используются строки. Эта же проблема и с рядом DB
> библиотек, точно также безответсвенно подошли и там.

самое страшное что это еще может много где всплыть...


Anatoly Podgoretsky   (2009-09-10 16:48:00) [8]

TServerSocket это компонент из Д7 вроде бы?


Сергей М.   (2009-09-10 16:21:00) [9]


> Думаешь, что они и там устроили пакость?


Все может быть ..

В принципе ты прав - в ситуации, когда разбираться с этой чехардой нет времени и/или неохота, написать свою функцию будет простейшим и лучшим решением.


Anatoly Podgoretsky   (2009-09-10 16:15:00) [10]

Думаешь, что они и там устроили пакость?
Это же убийство, если в пакетах Ansi, а в dcu Unicode
Не думаю, просто они не стали трогать, как было написано string так и оставили, не меняя. А пакеты тоже перекомпилировали.


Сергей М.   (2009-09-10 16:12:00) [11]


> что бы не трогать генофонд


Думаю, что его можно не трогать, если воспользоваться рантайм-пакетом scktcomp - вряд ли его перекомпиляли. Т.е. внутри него по-прежнему живут анси-строки


Сергей М.   (2009-09-10 16:09:00) [12]


> ReceiveBuf(Pointer(Result)^


Да, косяк именно в случае, когда Result является WideString.
Потому и [3]


Anatoly Podgoretsky   (2009-09-10 16:07:00) [13]

Это я предлагаю написать свою функцию, что бы не трогать генофонд.

Не знаю связано ли это с спешкой или нет, они просто не тестировали и на Инглише проблема особо не заметна.

Вместо ReceiveText можно пользоваться ReceiveBuf


d@vinchi   (2009-09-10 15:59:00) [14]


> function TCustomWinSocket.ReceiveText: AnsiString

так вот у меня
function TCustomWinSocket.ReceiveText: String
на сколько я понял это разработчики так спешили перейти на юникод что накосячили в TCustomWinSocket.


Anatoly Podgoretsky   (2009-09-10 15:55:00) [15]

Можно написать так

> function TCustomWinSocket.AnsiReceiveText: AnsiString;
> begin
>    SetLength(Result, ReceiveBuf(Pointer(nil)^, -1));
>    SetLength(Result, ReceiveBuf(Pointer(Result)^, Length(Result)));
>
> end;

Поскольку кроме ошибки с типом, также еще и SetLenght неверен, итого в функии правильны только две строки, это BEGIN и END
и таких мест множество, практически в каждой сетевой функции, если используются строки. Эта же проблема и с рядом DB библиотек, точно также безответсвенно подошли и там. Хотя проводили очень долгую компанию по переводу проектов пользователей под Юникод, а сами такого натворили.


Сергей М.   (2009-09-10 15:50:00) [16]


> 3. рассматривал под отладчиком


Отладчик не показывает "вопросов", если ты им правильнопользуешься.
Покажи hex-дамп строки..


Anatoly Podgoretsky   (2009-09-10 15:50:00) [17]


> никак не доганю что не так?

Должно быть function TCustomWinSocket.ReceiveText: AnsiString;


d@vinchi   (2009-09-10 15:41:00) [18]

1. Проект скомпелированный на Delphi 2007 работает как надо, т.е. в sReceiveText получаю строку в нормальном виде ожидаемого формата, на Delphi 2009 эта строка приходет в виде ???????????<вагон всякого мусора>
2. Конкретно то что мне отправляют если я Вас правильно понял, а отправляют мне строгоотформатированное текстовое сообщение (SIP протокол).
3. рассматривал под отладчиком...


Сергей М.   (2009-09-10 15:15:00) [19]


> чего явно не должно быть


Начнем с того - а что на самом деледолжно быть ?
Что конкретно ты ожидал увидеть в строке sReceiveText ?
И какими средствами ты разглядывал содержимое этой строки - под отладчиком или каким-нить ShowMessage() ?


d@vinchi   (2009-09-10 15:05:00) [20]

из всех вариантов наиболее приближенный к ожидаемому результату так:

var
 sReceiveText: String;
...
 sReceiveText:=PAnsiChar(Socket.ReceiveText);
...

хотя предпологаю что так не совсем правильно и вместо пустых строк символ 's', чего явно не должно быть... Иногда при таком варианте в sReceiveText присутствуют куски "мусора". По сути вызов Socket.ReceiveText и так реализован через ReceiveBuf, вот его реализация:

function TCustomWinSocket.ReceiveText: string;
begin
 SetLength(Result, ReceiveBuf(Pointer(nil)^, -1));
 SetLength(Result, ReceiveBuf(Pointer(Result)^, Length(Result)));
end;

никак не доганю что не так?


Страницы:   1 2

Наверх

Титульная страница Поиск, карта сайта Написать письмо