Форум » [x]Harbour » Помогите советом начинающему... » Ответить
Помогите советом начинающему...
Urri: Тут вот надумал переползти на xHarbour. Возникла следующая проблема: имена всех функций и подпрограмм дополняются префиксом HB_FUN_. А можно ли этого избежать так, чтобы остались родные, начальные имена. У меня весь софт построен на скриптах, в которых уже стоят вызовы функций и процедур по привычным, родным именам. И перелопатить везде в 5000 текстовых файлах-скриптах вызовы функций и поменять на новые - задача крайне утомительная с непонятной перспективой на успех.
Urri: Опять не понял... Когда подготавливал предыдущее сообщения посыпал голову пеплом, что пропали скобки и индексы к arr в цикле. При составлении письма убедился, что все нормально, т.к. неудобно уважаемых коллег два раза вводить в заблуждение. Однако в вижу, что опять пропали индексы в том, что отобразилось. Весьма странно, ведь в первоначальном варианте примера квадратные скобки и индексы пропали только в цикле, а ниже остались... Не знаю почему так. В цикле три раза присваивается значение i-му элементы массива arr(i) (это я квадратные скобки заменил на круглые для примера, а то опять куда-то денутся)
alkresin: Работает здесь имеется ввиду не то что вылетает, а то что потом при исправлении первого элемента остальные не портятся. Дело в том, что вы исправляете первый элемент не Клипперовским кодом, а низкоуровневой С функцией ( Mid ), вся проблема в ней. Т.е., вы залезаете во внутреннюю структуру Клипперовских переменных. Естественно, нельзя ожидать, что это будет одинаково работать во всех Клиппер-совместимых системах.
alkresin: Ф-я Mid() должна иметь вот такой вид: HB_FUNC( MID ) { /* par1 - исх.строка par2 - начальная позиция par3 - сколько символов par4 - чем заменить */ char *str1 = hb_parc(1), *str2 = hb_parc(4), *str3; int k = hb_parni(2)-1, l = hb_parni(3), j=0; int m = hb_parclen(1), n = hb_parclen(4); str3 = hb_xgrab( m + 1 ); memcpy( str3, str1, m ); *( str3+m ) ='\0'; switch (l) { case 0: break; case -1: while( (k<m) && (j<n) ) str3[k++] = str2[j++]; break; default: l += k; while( (k<l) && (j<n) ) str3[k++] = str2[j++]; break; }; if( ISBYREF(1) ) hb_storclen( str3, m, 1 ) ; hb_retclen_buffer( str3, m ); }
Dima: Urri Поправил твой пример , теперь скобки на месте. Пришлось добавить пробел. Cкобки съедало потому что есть тэг Italic [ i ][ / i ]
Urri: alkresin пишет: Дело в том, что вы исправляете первый элемент не Клипперовским кодом, а низкоуровневой С функцией ( Mid ), вся проблема в ней. Т.е., вы залезаете во внутреннюю структуру Клипперовских переменных. Естественно, нельзя ожидать, что это будет одинаково работать во всех Клиппер-совместимых системах. Но ведь я пользуюсь исключительно разрешенными приемами при обращении к внутренней структуре Клипперовских переменных, определенными правилами совместимости Клиппера (Harbour) и С через extend.h и extend.api. Поэтому и ожидал одинаковой работы. Думаю, что здесь все-таки некоторая недоработка в Харборах... Ну ладно, это я как-то поборол. А что же делать с SQL запросом, который работает только 44 раза? По вашей рекомендации запускал make_gnu.bat clean install, отдельно clean а потом install - не помогает, вылетает опять на TBROWSE.
alkresin: &r+='*' Вот такие варианты будут работать и в Клиппере, и в Harbour: &(r) += '*' или &r = &r + '*' Но в лист я все равно сообщение отправил.
alkresin: Но ведь я пользуюсь исключительно разрешенными приемами при обращении к внутренней структуре Клипперовских переменных, определенными правилами совместимости Клиппера (Harbour) и С через extend.h и extend.api. Поэтому и ожидал одинаковой работы. Использование _parc() чтобы получить значение параметра и _retc(), чтобы вернуть значение - безусловно, разрешенные приемы. А вот изменение полученной с помощью _parc() строки - это неразрешенное вмешательство во внутреннюю структуру Клипперовских переменных :). Правильно будет, как показано в моем варианте Mid(), скопировать полученную с помощью _parc() строку в новое место - и там уж делать с ней все, что надо. Под Linux ( это особенности реализации C компилятора ) изменение полученной _parc() строки может вызвать даже аварийное завершение программы ( GPF ).
Urri: Да, спасибо большое. Так работает в тестовом примере. Сейчас попробую воспользоваться в основных программах. alkresin пишет: Вот такие варианты будут работать и в Клиппере, и в Harbour: &(r) += '*' Сейчас проверю, а то я по всем своим программам переделал уже на второй предложенный вариант &r = &r + '*' ... Забодался. Неожиданное решение... Я кстати до сих пор не могу понять почему для определения типа переменной, например ааа, в клиппере нужно использовать ф-цию type(('aaa')) именно с двумя скобками. А что же делать с SQL запросом и русскими буквами в нем?
alkresin: Я кстати до сих пор не могу понять почему для определения типа переменной, например ааа, в клиппере нужно использовать ф-цию type(('aaa')) именно с двумя скобками. ?? В первый раз слышу. Всегда использовал эту функцию обычным образом: type( "AAA" ). А что же делать с SQL запросом и русскими буквами в нем? Какое именно изменение вы сделали в ADSEXECUTESQLDIRECT ? Приведите полный текст нового варианта.
Urri: HB_FUNC( ADSEXECUTESQLDIRECT ) { ADSAREAP pArea = hb_adsGetWorkAreaPointer(); /* NOTE: Removed test for hb_ads_hConnect as it is not actually used; the func was just trying to confirm a real connection existed but we're trying to remove dependence on statics; if we saved the nConnection to a WA, that would take care of it. As is, it requires pArea->hStatement which we only allow created if there's Connection so we should be OK. [bh 10/9/2005 2:51PM] */ if( /* hb_ads_hConnect && */ pArea && pArea->hStatement && ISCHAR( 1 ) ) { /* char * pucStmt = hb_adsOemToAnsi( hb_parc( 1 ), hb_parclen( 1 ) ); Так было */ char * pucStmt = hb_parc( 1 ); /* Так сделал по рекомендации Pasha */ Дальше по тексту ничего не менял....
alkresin: Значит, у вас осталась строка ( Petr рекомендовал вам ее убрать! ) : hb_adsOemAnsiFree( pucStmt ); В этом, по-видимому, и есть корень зла. Есть и другой способ отказаться от OemToAnsi преобразования. 2-й параметр в вызове AdsSetCharType( 2, .T. ) это преобразование разрешает. Так что попробуйте восстановить оригинальный adsfunc.c, а в своей программе поставьте: AdsSetCharType( 2, .F. ) IF !AdsExecuteSqlDirect( cSQL ) ? "AdsExecuteSqlDirect - error" SELECT( selsql ) USE SELECT( sel ) AdsSetCharType( 2, .T. ) return - 2 ENDIF AdsSetCharType( 2, .T. )
Urri: alkresin пишет: hb_adsOemAnsiFree( pucStmt ); В этом, по-видимому, и есть корень зла. Да, большое спасибо. Так заработало, не вылетает. Только вот опять же по тому примеру, что мы обсуждаем. После выполнения команды update street set naim=left(upper(naim),50)] в поле NAIM часть букв русских, часть букв неизвестно каких.
alkresin: в поле NAIM часть букв русских, часть букв неизвестно каких. А раньше все нормально было ? После чего буквы стали искажаться ?
Urri: alkresin пишет: А раньше все нормально было ? После чего буквы стали искажаться ? Не могу сказать. В примере, который мы отрабатывали, я больше упор сделал на то, что неожиданно программа ломалась после какого-то неопределенного количества шагов (то 28, то 22, то 44). А на качество работы ф-ции upper внимательно не смотрел. Попробовал временно откатить все изменения, которые я внес в RDDADS по советам местных гуру - результат такой же (ну и вернулись прежние вылеты).
alkresin: Проверьте настройки ADS сервера ( соответствующий ini файл ) локального и удаленного. Ф-я Upper() выполняется сервером, т.к. она входит в запрос, поэтому если кодовая страница сервера установлена не как русский OEM, то это преобразование он будет делать неправильно.
Urri: Это первое, что мне пришло в голову. Я это давно уже настроил, но еще сейчас перепроверил на всякий случай. В ADSLOCAL.CFG есть такие строки ANSI_CHAR_SET=RUSSIAN OEM_CHAR_SET=RUSSIAN Вот так работает ф-ция UPPER: исходное значение "Привет", результат "П└ибе┬" Меня удивляет то, что только четные буквы испортила. При этом нечетные не сделала UPPER, а оставила без изменения
Dima: Urri Файлы EXTEND.CHR , ANSI.CHR присутствуют ?
Urri: Конечно. Я скопировал все файлы из Advantage81\acesdk\Redistribute\ ace32.dll adsloc32.dll adslocal.cfg ansi.chr axcws32.dll extend.chr files.txt (даже этот, не очень и нужный) в Windows\System32 и там поправил ADSLOCAL.CFG implib сделал (как здесь учили), пересобрал RDDADS с указанием на актуальный, правильный acesdk.
Dima: Urri пишет: исходное значение "Привет", результат "П└ибе┬" На удаленном ADS такая же ситуация ?
Urri: Проверил. На удаленном ADS работает также странно
полная версия страницы