Отправлено: 21.04.09 15:43. Заголовок: Помогите советом начинающему...

Тут вот надумал переползти на xHarbour. Возникла следующая проблема: имена всех функций и подпрограмм дополняются префиксом HB_FUN_. А можно ли этого избежать так, чтобы остались родные, начальные имена. У меня весь софт построен на скриптах, в которых уже стоят вызовы функций и процедур по привычным, родным именам. И перелопатить везде в 5000 текстовых файлах-скриптах вызовы функций и поменять на новые - задача крайне утомительная с непонятной перспективой на успех.

 Отправлено: 02.07.09 14:58. Заголовок: Опять не понял... Ко..

Опять не понял... Когда подготавливал предыдущее сообщения посыпал голову пеплом, что пропали скобки и индексы к arr в цикле. При составлении письма убедился, что все нормально, т.к. неудобно уважаемых коллег два раза вводить в заблуждение. Однако в вижу, что опять пропали индексы в том, что отобразилось. Весьма странно, ведь в первоначальном варианте примера квадратные скобки и индексы пропали только в цикле, а ниже остались...
Не знаю почему так. В цикле три раза присваивается значение i-му элементы массива
arr(i) (это я квадратные скобки заменил на круглые для примера, а то опять куда-то денутся)

 Отправлено: 02.07.09 15:03. Заголовок: Работает здесь имеет..

цитата:

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

Дело в том, что вы исправляете первый элемент не Клипперовским кодом, а низкоуровневой С функцией ( Mid ), вся проблема в ней. Т.е., вы залезаете во внутреннюю структуру Клипперовских переменных. Естественно, нельзя ожидать, что это будет одинаково работать во всех Клиппер-совместимых системах.

 Отправлено: 02.07.09 15:28. Заголовок: Ф-я Mid() должна име..

Ф-я 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 ); }

 Отправлено: 02.07.09 15:31. Заголовок: Urri Поправил твой ..

Urri
Поправил твой пример , теперь скобки на месте. Пришлось добавить пробел.
Cкобки съедало потому что есть тэг Italic [ i ][ / i ]

 Отправлено: 02.07.09 15:44. Заголовок: alkresin пишет: Дел..

alkresin пишет:

цитата:

Дело в том, что вы исправляете первый элемент не Клипперовским кодом, а низкоуровневой С функцией ( Mid ), вся проблема в ней. Т.е., вы залезаете во внутреннюю структуру Клипперовских переменных. Естественно, нельзя ожидать, что это будет одинаково работать во всех Клиппер-совместимых системах.

Но ведь я пользуюсь исключительно разрешенными приемами при обращении к внутренней структуре Клипперовских переменных, определенными правилами совместимости Клиппера (Harbour) и С через extend.h и extend.api. Поэтому и ожидал одинаковой работы. Думаю, что здесь все-таки некоторая недоработка в Харборах...
Ну ладно, это я как-то поборол. А что же делать с SQL запросом, который работает только 44 раза?

По вашей рекомендации запускал make_gnu.bat clean install, отдельно clean а потом install - не помогает, вылетает опять на TBROWSE.

 Отправлено: 02.07.09 15:48. Заголовок: &r+='*' ..

цитата:

&r+='*'

Вот такие варианты будут работать и в Клиппере, и в Harbour:
&(r) += '*'
или
&r = &r + '*'

Но в лист я все равно сообщение отправил.

 Отправлено: 02.07.09 15:58. Заголовок: Но ведь я пользуюсь ..

цитата:

Но ведь я пользуюсь исключительно разрешенными приемами при обращении к внутренней структуре Клипперовских переменных, определенными правилами совместимости Клиппера (Harbour) и С через extend.h и extend.api. Поэтому и ожидал одинаковой работы.

Использование _parc() чтобы получить значение параметра и _retc(), чтобы вернуть значение - безусловно, разрешенные приемы. А вот изменение полученной с помощью _parc() строки - это неразрешенное вмешательство во внутреннюю структуру Клипперовских переменных :). Правильно будет, как показано в моем варианте Mid(), скопировать полученную с помощью _parc() строку в новое место - и там уж делать с ней все, что надо. Под Linux ( это особенности реализации C компилятора ) изменение полученной _parc() строки может вызвать даже аварийное завершение программы ( GPF ).

 Отправлено: 02.07.09 16:17. Заголовок: Да, спасибо большое...

Да, спасибо большое. Так работает в тестовом примере. Сейчас попробую воспользоваться в основных программах.

alkresin пишет:

цитата:

Вот такие варианты будут работать и в Клиппере, и в Harbour: &(r) += '*'

Сейчас проверю, а то я по всем своим программам переделал уже на второй предложенный вариант &r = &r + '*' ... Забодался. Неожиданное решение... Я кстати до сих пор не могу понять почему для определения типа переменной, например ааа, в клиппере нужно использовать ф-цию type(('aaa')) именно с двумя скобками.

А что же делать с SQL запросом и русскими буквами в нем?

 Отправлено: 02.07.09 18:45. Заголовок: Я кстати до сих пор ..

цитата:

Я кстати до сих пор не могу понять почему для определения типа переменной, например ааа, в клиппере нужно использовать ф-цию type(('aaa')) именно с двумя скобками.

?? В первый раз слышу. Всегда использовал эту функцию обычным образом: type( "AAA" ).

цитата:

А что же делать с SQL запросом и русскими буквами в нем?

Какое именно изменение вы сделали в ADSEXECUTESQLDIRECT ? Приведите полный текст нового варианта.

 Отправлено: 02.07.09 18:59. Заголовок: HB_FUNC( ADSEXECUTES..

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 */

Дальше по тексту ничего не менял....

 Отправлено: 02.07.09 19:46. Заголовок: Значит, у вас остала..

Значит, у вас осталась строка ( 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. )

 Отправлено: 03.07.09 10:12. Заголовок: alkresin пишет: hb_..

alkresin пишет:

цитата:

hb_adsOemAnsiFree( pucStmt ); В этом, по-видимому, и есть корень зла.

Да, большое спасибо. Так заработало, не вылетает.

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

update street set naim=left(upper(naim),50)]

в поле NAIM часть букв русских, часть букв неизвестно каких.

 Отправлено: 03.07.09 11:41. Заголовок: в поле NAIM часть бу..

цитата:

в поле NAIM часть букв русских, часть букв неизвестно каких.

А раньше все нормально было ? После чего буквы стали искажаться ?

 Отправлено: 03.07.09 13:57. Заголовок: alkresin пишет: А р..

alkresin пишет:

цитата:

А раньше все нормально было ? После чего буквы стали искажаться ?

Не могу сказать. В примере, который мы отрабатывали, я больше упор сделал на то, что неожиданно программа ломалась после какого-то неопределенного количества шагов (то 28, то 22, то 44). А на качество работы ф-ции upper внимательно не смотрел. Попробовал временно откатить все изменения, которые я внес в RDDADS по советам местных гуру - результат такой же (ну и вернулись прежние вылеты).

 Отправлено: 03.07.09 14:16. Заголовок: Проверьте настройки ..

Проверьте настройки ADS сервера ( соответствующий ini файл ) локального и удаленного. Ф-я Upper() выполняется сервером, т.к. она входит в запрос, поэтому если кодовая страница сервера установлена не как русский OEM, то это преобразование он будет делать неправильно.

 Отправлено: 03.07.09 15:07. Заголовок: Это первое, что мне ..

Это первое, что мне пришло в голову. Я это давно уже настроил, но еще сейчас перепроверил на всякий случай.

В ADSLOCAL.CFG есть такие строки

ANSI_CHAR_SET=RUSSIAN

OEM_CHAR_SET=RUSSIAN

Вот так работает ф-ция UPPER:
исходное значение "Привет", результат "П└ибе┬"

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

 Отправлено: 03.07.09 15:16. Заголовок: Urri Файлы EXTEND.C..

Urri
Файлы EXTEND.CHR , ANSI.CHR присутствуют ?

 Отправлено: 03.07.09 15:34. Заголовок: Конечно. Я скопирова..

Конечно.
Я скопировал все файлы из
Advantage81\acesdk\Redistribute\

ace32.dll
adsloc32.dll
adslocal.cfg
ansi.chr
axcws32.dll
extend.chr
files.txt (даже этот, не очень и нужный)

в Windows\System32 и там поправил ADSLOCAL.CFG

implib сделал (как здесь учили), пересобрал RDDADS с указанием на актуальный, правильный acesdk.

 Отправлено: 03.07.09 15:46. Заголовок: Urri пишет: исходно..

Urri пишет:

цитата:

исходное значение "Привет", результат "П└ибе┬"

На удаленном ADS такая же ситуация ?

 Отправлено: 03.07.09 15:54. Заголовок: Проверил. На удаленн..

Проверил. На удаленном ADS работает также странно