Отправлено: 12.11.05 03:57. Заголовок: Clipper 5.2-5.3 проблем, а в Harbour?

Надоело биться с Clipperами 5.2(SIX)-5.3
Выяснилось, например, что значения SCOPE не воспринимаются как ограничители для первой/последней записи списка в TBrowse при нажатии комбинаций Ctrl_PgUp и Ctrl_PgDown соответственно... Так что получаем переход на первую или последнюю запись неSCOPанутого списка и как следствие (если запись не соответствует SCOPу) - зависание...
Хотелось бы попробовать Harbour, но как на него перейти, чёткого алгоритма пока не встречал. То есть где-то полгодика тому увидел и скачал FAQи на эту тему, но там нет алгоритма действий, всё вразброс, да и рассчитано на человека, который знает-понимает, что такое Си, а если с ним и с его библиотеками не сталкивался в принципе никогда? Кто-нибудь может порадовать алгоритмом перехода на Harbour?

 Отправлено: 22.11.05 20:20. Заголовок: Re:

Вот KeySec и KeyTime, конечно без поддержки скэнкодов, используй
пока так, я их залью на CVS и в следующем релизе они будут

keyb1.prg:

Static nHandle := 0
Static nSeconds, nsKey, nsTime, nsCounter, lsMode

Function KeySec(nKey, nTime, nCounter, lMode)
Local lActivated := .f.

if nHandle != 0
HB_IdleDel(nHandle)
nHandle := 0
endif

if nKey != nil

if nTime < 0
nTime := -nTime/18.2
endif
if nCounter == nil
nCounter := 1
endif
if lMode == nil
lMode := .f.
endif

nsKey := nKey
nsTime := nTime
nsCounter := nCounter
lsMode := lMode
nSeconds := Seconds()

nHandle := HB_IdleAdd({|| doKeySec()})
lActivated := .t.

endif
Return lActivated

Static function doKeySec()
Local nSec := Seconds()

if lsMode .and. ! Empty(NextKey())
nSeconds := nSec
elseif nsCounter != 0 .and. nSec - nSeconds >= nsTime
__Keyboard(nsKey)
if nsCounter > 0
nsCounter --
endif
if nsCounter == 0
HB_IdleDel(nHandle)
nHandle := 0
else
nSeconds := nSec
endif
endif
Return nil

 Отправлено: 22.11.05 20:23. Заголовок: Re:

и keyb2.prg:


Static nHandle := 0, cTime, nsKey
Static nHour, nMin, nSec, nLast


Function KeyTime(nKey, cClockTime)
Local lActivated := .f.

if nHandle != 0
HB_IdleDel(nHandle)
nHandle := 0
endif

if nKey != nil .and. ValType(cClockTime) = 'C'

nsKey := nKey
cTime := cClockTime
nHour := Val(Substr(cClockTime, 1, 2))
nMin := Val(Substr(cClockTime, 4, 2))
nSec := Val(Substr(cClockTime, 7, 2))
nLast := -1
nHandle := HB_IdleAdd({|| doKeyTime()})
lActivated := .t.

endif
Return lActivated

Static function doKeyTime()
Local ccTime := Time()
Local nHr := Val(Substr(ccTime, 1, 2))
Local nMn := Val(Substr(ccTime, 4, 2))
Local nSc := Val(Substr(ccTime, 7, 2))

if nHour = 99
if nHr > nLast
__Keyboard(nsKey)
nLast := nHr
if nHr == 23
HB_IdleDel(nHandle)
nHandle := 0
endif
endif
elseif nMin = 99 .and. nHr == nHour
if nMn > nLast
__Keyboard(nsKey)
nLast := nMn
if nMn == 59
HB_IdleDel(nHandle)
nHandle := 0
endif
endif
elseif nSec = 99 .and. nHr == nHour .and. nMn == nMin
if nSc > nLast
__Keyboard(nsKey)
nLast := nSc
if nSc == 59
HB_IdleDel(nHandle)
nHandle := 0
endif
endif
elseif ccTime > cTime

__Keyboard(nsKey)
HB_IdleDel(nHandle)
nHandle := 0

endif
Return nil

 Отправлено: 23.11.05 13:52. Заголовок: Re:

Pasha, спасибо большое!

А в полноэкранном режиме всегда такие тормоза? (Пока тестирую под Миллениум, под другие Винды еще не пробовал).
Как-то с этом бороться можно?

 Отправлено: 23.11.05 22:36. Заголовок: Re:

Тормоза в фуллскрин есть только под Win98, WinMe и наверное в Win95
В оконном режиме в этих ОС тормозов нет
В winnt/2k/xp/2003 тормозов нет ни в фуллскрин ни в оконном режиме
Тормоза связаны с медленной работой в win9x консольных винапишных
функций работы с курсором (т.е. тормоза возникают только при
изменении позиции курсора или SetCursor(1)/SetCursor(0))
Такая же проблема стояла и в других консольных win32 программах,
пример far и dos navigator (win32-версия). В этих программах
проблема решена путем вызова этих функций в отдельном потоке
(thread). В харборе эта проблема к сожалению не решена. Я пытался
создавать поток для вызова SetConsoleCursorPosition и тому подобное,
но результата не было - видать не хватает опыта использования winapi
Работу в фуллскрин можно заметно ускорить путем использования при
выводе на экран функций DispBegin() - DispEnd(). Например перед первым
@ say get поставить DispBegin(), а перед READ - DispEnd(). В этом случае
вывод на экран буферируется и весь экран обновляется один раз после
DispEnd. И пореже включать/выключать курсор. При выключенном курсоре
вывод на экран выполняется быстро и тормозов нет !
Кстати сам текстовый терминал харбора gtwin предельно оптимизирован
и где только можно использует буферизацию.
У меня например благодаря такой буферизации фуллскирин работает
довольно приемлемо и тормоза почти не чувствуются. Да и win9x
сейчас выходит из употребления, а в winxp проблемы нет вообще

Ну а радикальный способ решить вопрос - использовать другой терминал:
gtwvt. Это не текстовый режим, а его эмуляция через графику, почти как
оконный режим, но при этом дополнительно есть много других возможностей

 Отправлено: 23.11.05 23:00. Заголовок: Re:

Pasha
я так понял что контакта с автором FAR ни кто не нашел..........
Интерестно через что он работает, WINAPI или как то иначе......

 Отправлено: 24.11.05 10:44. Заголовок: Re:

Да у Рошаля спрашивать уже и ничего не надо, что делать вобщем-то понятно,
только вот как :( техника хромает
DOS Navigator ведь тоже OpenSource проект, я смотрел его паскалевские сырцы,
и делал также в харборовском gtwin на C. Тормоза оставались
Может там еще что-то инициализировать надо, не знаю

 Отправлено: 25.11.05 00:13. Заголовок: Re:

Pasha пишет:

цитата

---

Тормоза в фуллскрин есть только под Win98, WinMe и наверное в Win95
В оконном режиме в этих ОС тормозов нет

---

В оконном режиме, действительно все нормально. Странно вот что -
тестировал программу на трех компьютерах, полноэкранный режим -
- Win XP - Celeron-1000 - все идеально
- Win 98 - P-166 (первый пентиум) - вполне неплохо
- Win Me - Celeron-1000 - очень сильно тормозит, на порядок больше, чем на P-166.

 Отправлено: 25.11.05 11:21. Заголовок: Re:

Что тут сказать... Значит в Me эта функция winapi работает еще хуже
Или дело в видеодрайвере
Я тоже замечал что харбор-терминал на Cel1100 работает шустрее чем на Cel2000
И там и там win98

 Отправлено: 25.11.05 12:49. Заголовок: Re:

Pasha пишет:

цитата

---

Проблема пока детская, будут и серьезнее
Ты вероятно используешь в prg код без начальной процедуры или функции
Убери в bld.bat в строке 116 параметр -n или в своих prg оформи главный модуль:

proc main
...
return

---

Не понял, какой такой bld.bat???
Ошибка возникает, когда я выполняю компиляцию:
xharbour.exe fun.prg ,например. И такая лабуда на каждый абсолютно prg...
Также не понял, что, в каждом prg должна быть процедура MAIN? Но тогда уж точно Redefinition получится!

 Отправлено: 25.11.05 17:52. Заголовок: Re:

Лукашевскмй
Покажи пример небольшого исходника который ты не можешь компильнуть.

Процедура MAIN должна быть в основном модуле.
А вообще юзай например HBMAKE в интерактивном режиме для создания и редактирования сценария.

BLD.BAT батничек который лежит в harbour\bin и служит для сборки.
Пример запуска можно увидеть , запустив его без параметров.

 Отправлено: 26.11.05 07:42. Заголовок: Re:

Dima пишет:

цитата

---

BLD.BAT батничек который лежит в harbour\bin и служит для сборки.
Пример запуска можно увидеть , запустив его без параметров.

---

У меня в xharbour\bin только 3 файла: harbour.exe, hbdoc.exe и hamake.exe и всё! Никакого bld.bat там нет. Ну и ладно, до линковки мне ещё семь вёрст и всё лесом...
А компилить я пытаюсь АБСОЛЮТНО те же самые PRG от 5.2, ни единого знака в них не менял!

 Отправлено: 26.11.05 08:11. Заголовок: Re:

Dima

Понял по компиляции: в xharbour (по крайней мере 0.99.50, который я скачал), нельзя чтобы PRG-модуль назывался так же, как любая из процедур или функций внутри него... Но у меня половина модулей по названиям функций, кот. внутри, называется. А модулей штук 90, если я их переименую, то запутаюсь нафиг без всякого harbour... Что делать?
А вот чего не понял, это почему результирующий PRG.C в Нортоне по F4 отображается в одну строку, а по F3 нормально... То есть понятно, что дело в концах строк, а как бы это изменить? Или это в Cи так принято?

 Отправлено: 26.11.05 12:27. Заголовок: Re:

Дошло до меня кажется
Похоже при сборке релиза для bcc в xharbour\bin забыли положить *.bat
По крайней мере год назад это делали. Это так ? Я и не знаю, релиз не скачиваю
Лукашевский, давай свой адрес, срочно вышлем !
И надо собирать программу харбором с теми же параметрами, что ты
ее собираешь в клиппере. А для этого исправить строку не помню уже номер
в bld.bat

Юниксовые компиляторы С понимают разделитель строк Chr(10), а виндозные -
и Chr(10) и Chr(13)+Chr(10). Для общности компилятор харбора генерирует
выходной С-файл с разделитетем Chr(10)
Используй вместо нортона фар, он тоже понимает оба разделителя строк
Менять компилятор харбора из-за особенности редактора древнего нортона никто не станет

 Отправлено: 27.11.05 02:39. Заголовок: Re:

Pasha пишет:

цитата

---

Похоже при сборке релиза для bcc в xharbour\bin забыли положить *.bat
По крайней мере год назад это делали. Это так ? Я и не знаю, релиз не скачиваю
Лукашевский, давай свой адрес, срочно вышлем !

---

Именно так, Bat-ников в BIN нет.
Мой адрес не дом и не улица, а kniga@online.ru
Хотелось бы узнать, с чем ещё я ОБЯЗАТЕЛЬНО столкнусь. Вызов каких-то дополнительных функций нужно в процедуру MAIN всобачить, вроде бы?

 Отправлено: 27.11.05 12:46. Заголовок: Re:

Отправил

В майн надо поставить русскую кодовую страницу - это есть в фак
И не забудь скачать gtwin с xharbour.nm.ru

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

 Отправлено: 28.11.05 01:26. Заголовок: Re:

Спасибо за BAT, но у меня тоже Millennium и сообщение о нехватке памяти для переменных среды при выполненни батника... Но Сишный файл вроде создаётся...

Насчёт gtwin.lib - есть ли существенная разхница между файлом от 21.06.05 в архиве с xharbour.nm.ru и файлом от 06.06.05 из папки LIB из архива XHarbour? По размеру они одинаковы... И кстати, чего с ним делать-то нужно?

 Отправлено: 28.11.05 09:10. Заголовок: Re:

Лукашевский
Снеси этот каличный Линолиум ;)))

 Отправлено: 28.11.05 10:15. Заголовок: Re:

С миллениум я не помогу, у меня его нет, поищи на гугле или спроси на каком-нибудь форуме по виндузам

gtwin.lib с xharbour.nm.ru надо переписать в каталог lib
пофиксен ввод русской буквы "р"

 Отправлено: 28.11.05 12:35. Заголовок: Re:

Pasha пишет
>Тормоза в фуллскрин есть только под Win98, WinMe и наверное в Win95
>В оконном режиме в этих ОС тормозов нет
При работе в сети в режиме файл- сервер , таблица расположена на сервере, и в оконном режиме , тормозит.Но скорость вычислений нормальная.Поэтому сетевые программы не могу на Харбор перевести

 Отправлено: 28.11.05 15:08. Заголовок: Re:

Медленнее чем в клиппере ? На каких операцих ? На чтении или записи в таблицу ?
Странно, у меня как раз быстрее чем в клиппере получается

Есть один момент. Есть тормоза при обновлении файлов, то надо:
в модуле source\rtl\filesys.c в функции fsCommit между строк:

HB_TRACE(HB_TR_DEBUG, ("hb_fsCommit(%p)", hFileHandle));
и
HB_STACK_UNLOCK

вставить:

#if defined(HB_OS_WIN_32)
hb_fsSetIOError( TRUE, 0 );
return;
#endif

и пересобрать этот модуль
Может поможет