Подскажите, пожалуйста, как правильно реализовать следующую задумку:

В DLL реализована функция с прототипом:

BOOL Get(URLPARAM *Param,LPSTR & Head,LPSTR & Body), где URLPARAM — структура содержащаю урл, прокси, и прочие флаги соединения, а Head и Body используются только для возврата значений.
Получение происходит с помощью функций:
InternetOpen -> InternetConnect -> HttpSendRequest -> HttpHueryInfo -> InternetReadFile -> InternetCloseHandle(3)
есть внутренний буфер char[1024], в который считывается информация (InternetReadFile), затем перевыделяется память
под общий буфер (Body = realloc) и дописывается свежесчитанный кусок. В завершении ставим последним символом общего буфера "\0" и получаем на выходе функции указатель на буфер нужной длины.

Теперь суть проблемы: В вызовах функций wininet НЕ устанавливается флаг асинхронной работы.
Но после вызова Get из приложения, начинает обрабатываться буфер Body, что и вызывает исключение.
НО если после вызова Get стоит MessageBox — все проходит на ура и программа работает...

Как реализовать ожидание заполнения буфера?

Здравствуйте formatc, вы писали:

F>BOOL Get(URLPARAM *Param,LPSTR & Head,LPSTR & Body), где URLPARAM — структура содержащаю урл, прокси, и прочие флаги соединения, а Head и Body используются только для возврата значений.

F>Теперь суть проблемы: В вызовах функций wininet НЕ устанавливается флаг асинхронной работы.
F>Но после вызова Get из приложения, начинает обрабатываться буфер Body, что и вызывает исключение.
F>НО если после вызова Get стоит MessageBox — все проходит на ура и программа работает...

Сдаётся мне, что синхронизация здесь никаким боком. Интересно посмотреть на код вызывающей функции и в особенности на последующую обработку буфера. А сам прототип я бы паписал так:

BOOL Get(URLPARAM& Param,LPSTR Head,LPSTR *Body)
  или
LPSTR Get(URLPARAM& Param,LPSTR Head)

Здравствуйте IT, вы писали:

IT>Здравствуйте formatc, вы писали:

F>>Теперь суть проблемы: В вызовах функций wininet НЕ устанавливается флаг асинхронной работы.
F>>Но после вызова Get из приложения, начинает обрабатываться буфер Body, что и вызывает исключение.
F>>НО если после вызова Get стоит MessageBox — все проходит на ура и программа работает...

IT>Сдаётся мне, что синхронизация здесь никаким боком. Интересно посмотреть на код вызывающей функции и в особенности на последующую обработку буфера. А сам прототип я бы паписал так:

IT>

IT>BOOL Get(URLPARAM& Param,LPSTR Head,LPSTR *Body)
IT>  или
IT>LPSTR Get(URLPARAM& Param,LPSTR Head)
IT>

Прототип я переписал как:

BOOL Get(URLPARAM& Param,LPSTR* Head,LPSTR *Body);

Но это ничего не изменило. Зато появились следующие непонятности:
После вызова метода Get, вызывается функция

char * GetCookie(char * Head);

использующая функции sltrlen и регулярные выражения (исходных текстов под рукой нет, могу отослать мылом), применяемо к параметру Head. Так вот если MessageBox поставить после этой функции:

char * lpszHead = NULL, *lpszBody = NULL;
BOOL bGetExec = Get(&Param,lpszHead,lpszBody);
if(bGetExec)
{
   char * Cookie = GetCookie(char * Head); // здесь стоит BreakPoint
   MessageBox(nWnd,Cookie,"Cookie",MB_OK);
   ....  
}

то все идет как надо, в обратном случае Head содержит "...Bad Request..."

Здравствуйте formatc, вы писали:

F>Но это ничего не изменило. Зато появились следующие непонятности:

[skip]

F>то все идет как надо, в обратном случае Head содержит "...Bad Request..."

Ну прям чудеса. Здесь без исходников не разобраться, нужно больше информации.

Здравствуйте IT, вы писали:

IT>Ну прям чудеса. Здесь без исходников не разобраться, нужно больше информации.

исходники на http://cash-club.virtualave.net/wininet.ZIP

Здравствуйте formatc, вы писали:

F>Здравствуйте IT, вы писали:

IT>>Ну прям чудеса. Здесь без исходников не разобраться, нужно больше информации.

F>исходники на http://cash-club.virtualave.net/wininet.ZIP

char szHBuf[2048];
DWORD dwBrcv = 2048;
bRes = HttpQueryInfo(hReq, HTTP_QUERY_RAW_HEADERS_CRLF, szHBuf, &dwBrcv, NULL);
szHBuf[dwBrcv] = 0;

Ошибка в последней строке. szHBuf[dwBrcv] указывает на 2049 символ от начала szHBuf, т.е. в наличии выход за границы масситва. При этом ноль затирает часть переменной dwBrcv, следующей сразу за массивом, ну а дальше сам понимаешь... Лечится:

char szHBuf[2048];
DWORD dwBrcv = sizeof(szHBuf)-1;

Здравствуйте IT, вы писали:


IT>

IT>char szHBuf[2048];
IT>DWORD dwBrcv = 2048;
IT>bRes = HttpQueryInfo(hReq, HTTP_QUERY_RAW_HEADERS_CRLF, szHBuf, &dwBrcv, NULL);
IT>szHBuf[dwBrcv] = 0;
IT>

IT>Ошибка в последней строке. szHBuf[dwBrcv] указывает на 2049 символ от начала szHBuf, т.е. в наличии выход за границы масситва. При этом ноль затирает часть переменной dwBrcv, следующей сразу за массивом, ну а дальше сам понимаешь... Лечится:

Спасибо, но это здесь не при чем. Ведь 2048 это максимальный размер, а возвращается всего 400-500 и в итоге никакого переполнения быть не может...
Хотя все равно мой недосмотр есть!
Исправил, но проблему не решило — все по старому :(

Здравствуйте formatc, вы писали:

F>Исправил, но проблему не решило — все по старому :(

Откомпилял пример, запустил, всё работает, Body выводил через MessageBox.

Здравствуйте IT, вы писали:

F>>Исправил, но проблему не решило — все по старому :(

IT>Откомпилял пример, запустил, всё работает, Body выводил через MessageBox.

В том вся и фишка, что если MessageBox убрать — работать перестанет...
Я BreakPoint's ставил после вызовов Get и смотрел переменные.

Ладно — попробовал я тут по другому все это сделать:
В функции смотрю код ответа сервера и возвращаю TRUE если он меньше 400, т.е. нет ошибки, иначе FALSE.

Вот как выглядит теперь работающий вызов:

...
BOOL bGet = Get(&Param, &lpszHead, &lpszBody);
if (!bGet) {
         MessageBox(NULL,"Error in server ansver","Error",0);
         return FALSE
           }
... // обработка

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

Короче устал я с этим разбираться, придется наверное оставлять так, хотя сердце кровью обливаетися глядя на такой код :(

Если кому-нить интересно продолжение этой истории, либо есть люди знающие как избавиться от глюка, то дополнительная информация по вопросу есть на
http://clubpro.spb.ru/ubb/Forum3/HTML/000132.html

Помогите, пожалуйста — очень нужно в сжатые сроки разрешить проблему.

Спасибо за внимание.

Здравствуйте formatc, вы писали:

F>Если кому-нить интересно продолжение этой истории, либо есть люди знающие как избавиться от глюка, то дополнительная информация по вопросу есть на
F>http://clubpro.spb.ru/ubb/Forum3/HTML/000132.html

Там тебе тоже говорят, что чудес не бывает. И это праильно.

F>Помогите, пожалуйста — очень нужно в сжатые сроки разрешить проблему.

Ващета надо предупреждать, что компилятор lcc. Как я уже говорил на vc у меня твой пример нормально работает. Посмотри здесь Введение в WinInet

Автор(ы): Игорь Ткачёв
Дата: 03.08.2001

класс и примеры. С многозадачностью аккуратней, WinInet в части HTTP не шибко многозадачный. Я, после долгой возни со всеми глюгами и фичами WinInet, окончательно пришел к умозаключению, высказанному в конце вышеприведённой ссылки. Т.е. сейчас у меня стоит одноразовый DCOM сервер, который запускается как отдельный процесс для каждого создаваемого объекта. Иногда я наблюдаю до 30 процессов 8), но, тем не менее, все счастливы, все довольны и я уже стал забывать, что у меня когда-то были какие-то проблемы. Если надо, исходники могу выслать или куда-нибудь выложить.

Здравствуйте IT, вы писали:

IT>Там тебе тоже говорят, что чудес не бывает. И это праильно.

Я не питаю никаких илюзий по поводу чудес.
И знаю что практически все ошибки происходят по недосмотру или незнанию... В моем случае я все таки обвиняю второе, т.к. я чувствую что где-то моя ошибка, но, знаний видимо не хватает и я вынужден просить помощи в ее обнаружении.

С WinAPI я столкнулся всего несколько недель назад, и приношу Вам, Игорь, отдельную благодарность за статью "Введение в WinInet", т.к. именно она оказалось первым документом, показавшимся мне более-меннее полным и понятным!
А вообще прикольно — лежит на столе распечатка, а то что с ее автором общаюсь не знал... %))

IT>Ващета надо предупреждать, что компилятор lcc. Как я уже говорил на vc у меня твой пример нормально работает.

Я сейчас пробую перейти на VC, хотя LCC мне понравился больше — и размером ЕХЕ и скоростью.

IT>Если надо, исходники могу выслать или куда-нибудь выложить.
Очень хотелось бы... можно на m_star@mail.ru. Все таки придется разобраться "что такое COM и с чем его едят" :))