powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Отображение шкалы при Select
17 сообщений из 17, страница 1 из 1
Отображение шкалы при Select
    #33793239
alexFV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Форма As Top Level. Выполняется Select. Фоксовская шкала выполнения запроса не отображается. Что мне надо сделать чтоб она отображалась?
...
Рейтинг: 0 / 0
Отображение шкалы при Select
    #33793626
karly™
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
1. Не забыть дать команду Set talk on (думаю, что ты не забыл ;-) )

2. Сделать форму побольше размером, чтобы стандартный градусник поместился.
...
Рейтинг: 0 / 0
Отображение шкалы при Select
    #33793631
S866
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А вопрос уже поднимался

Код: plaintext
1.
2.
3.
4.
set talk on

select ...

set talk off

и помоему другого решения нет
...
Рейтинг: 0 / 0
Отображение шкалы при Select
    #33794129
karly™
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
У меня был такой эффект на VFP6 - когда основное окно скрыто, и на экране отображалась только маленькая форма, прогресс-бар не показывался, несмотря на Set Talk on и запрос, выполнявшийся полчаса. Увеличил размеры формы - прогресс-бар появился :)

Вполне может быть, что эффект сохранился и в более поздних версиях.
...
Рейтинг: 0 / 0
Отображение шкалы при Select
    #33794314
Valerii
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Решение есть, я такое делал, правда немного кривовато, но работает:
progress = 0
Select .T. From Your_Table Where YourWhereHavingGroupCondition INTO array nrRecord

Select fld1, fld2....fld_n, fn AS exp1 FROM Where YourWhereHavingGroupCondition INTO CURSOR yourResultCursor

Function fn
Progress = progress +1
oProgressbar.Value = Progress
RETURN
Задействуется Actvex ProgressBar...
Это основная идея...
...
Рейтинг: 0 / 0
Отображение шкалы при Select
    #33794462
S866
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Valerii

Мне идея очень понравилась - только думаю что исполнение такого запроса сильно затянется (в десятки раз) + время предварительного Селекта

но если пользователю будут важнее шашечки а не ехать - вполне подойдет.
...
Рейтинг: 0 / 0
Отображение шкалы при Select
    #33794645
alexFV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
karly™1. Не забыть дать команду Set talk on (думаю, что ты не забыл ;-) )

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

Set TALK ON - стоял. Сделал форму на весь экран - всё равно нет шкалы.


Valerii
Насчет прогрессбара ActiveXного: нехотелось бы замедлять работу итак селект довольно долго идет, но выбора походу нет. Спасибо.
...
Рейтинг: 0 / 0
Отображение шкалы при Select
    #33794732
Проходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Обычно вместо прогресса используют проигрывание авишки. И индикация есть, и не тормозит запрос. Тем более что прогресс никакой корректной информации не показывает.
...
Рейтинг: 0 / 0
Отображение шкалы при Select
    #33794796
Фотография ВладимирМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SET TALK ON приведет к возникновению индикатора прогресса в основном окне FoxPro (_SCREEN). Для As Top-Level форм работать не будет. Точнее, будет, но внутри _SCREEN, которое скрыто.

Правда, можно попробовать поиграться с SET TALK WINDOW, но тут я не уверен.

Вообще, создание приложений целиком на базе As Top-Level форм, лично я считаю баловством. Именно тот случай, когда важнее "шашечки".

FoxPro "заточен" под работу с формами IN SCREEN. При построении всего приложения на базе As Top-Level форм будешь натыкаться на самые разные недоразумения, которые потребут усилий по их преодолению. При любом раскладе необходима главная (управляющая) форма всего приложения. Почему в этом качестве не использовать основное окно FoxPro?
...
Рейтинг: 0 / 0
Отображение шкалы при Select
    #33794943
alexFV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ВладимирМ При любом раскладе необходима главная (управляющая) форма всего приложения. Почему в этом качестве не использовать основное окно FoxPro?

Да я согласен, но если приложенице состоит всего то из одной формы не очень красиво тогда смотрится _screen
...
Рейтинг: 0 / 0
Отображение шкалы при Select
    #33794973
Cyv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторНасчет прогрессбара ActiveXного: нехотелось бы замедлять работу
Попробуй вариант родного прогрессбара из FFC. Особых тормозов я не
замечаю. Вот примерная схема:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
SET TALK OFF

CREATE CURSOR CTest (nid I, cname C( 10 ))
LOCAL i
FOR m.i =  1  TO  100000 
	INSERT INTO CTest (nid, cname) VALUES (m.i, SYS( 2015 ))
NEXT

PRIVATE poTherm, pnCallCount
pnCallCount =  0 
poTherm = NEWOBJECT("_thermometer",HOME( 1 )+ "FFC\_therm.vcx",NULL,"Please Wait...",RECCOUNT("CTest"))
poTherm.Show()

SELECT nid, cname ;
	FROM CTest ;
	WHERE MOD(nid, 2 )= 0  AND RefreshTherm() ;
	INTO CURSOR CResult
	
??CHR( 7 )
poTherm.Complete()
RELEASE poTherm, pnCallCount
CLOSE TABLES ALL


PROCEDURE RefreshTherm
IF VARTYPE(poTherm) = "O"
	pnCallCount = m.pnCallCount +  1 
	poTherm.Update(m.pnCallCount)
ENDIF
ENDPROC
...
Рейтинг: 0 / 0
Отображение шкалы при Select
    #33795541
karly™
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Я уже озвучивал мысль, что если данных много, и распределены они достаточно равномерно, можно запоминать длительность предыдущего расчета, и сообщать пользователю, что текущий расчет продлится "примерно столько же".

Если у расчетов есть параметры, длительность можно приводить к одному знаменателю. Например:
- если пользователь задал диапазон дат от 01.06.2006 до 10.06.2006, и расчеты заняли 10 минут, то на обсчет одного дня в среднем уходит 1 минута. Когда пользователь в следующий раз укажет 01.03.2006-20.03.2006, мы можем предположить, что расчеты продлятся 20 минут, и сообщить об этом пользователю.

Wait window "У вас есть свободное время примерно до " + Transform(DateTime() + lnEvaluation) nowait

Select ... from ... where ...


Алгоритм оценки может быть достаточно сложным - например, можно не учитывать слишком короткие промежутки, выходные, и т.п. Главное, что бы оценка не считалась дольше, чем сами расчеты
...
Рейтинг: 0 / 0
Отображение шкалы при Select
    #33798314
Valerii
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
проходящийОбычно вместо прогресса используют проигрывание авишки. И индикация есть, и не тормозит запрос. Тем более что прогресс никакой корректной информации не показывает.

А по овоему зачем первый Select .T. InTO ARRAY,
для того, чтоб показать реальное количество будущих записей... это значение и становиться ActivexProgressBar.Max...
Дружище, ты не прав....
...
Рейтинг: 0 / 0
Отображение шкалы при Select
    #33798319
Valerii
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
S8662 Valerii

Мне идея очень понравилась - только думаю что исполнение такого запроса сильно затянется (в десятки раз) + время предварительного Селекта

но если пользователю будут важнее шашечки а не ехать - вполне подойдет.
Нет, по скорости будет чуть чуть длинее, так как первый селект отбирает .Т. записи по условию, и эта фича кэшируется технологией RushMore....
Но конечно Progressbar - это определенный тормоз, можно Shape (только о его толщине подумайте....) использовать и тогда все более неменее норма... Вариантов море....
А если в selecte есть вычисляемое поле, тогда в него воткнуть приращение ProgressBara....
Тогда я вас уверяю, разница незначительная - проверено - believe me...
...
Рейтинг: 0 / 0
Отображение шкалы при Select
    #33813049
Igor Korolyov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hi Valerii!

> А по овоему зачем первый Select .T. InTO ARRAY,
> для того, чтоб показать реальное количество будущих записей...

Ты серьёзно считаешь что за время исполнения такого долгоиграющего (а иначе
зачем прогрессбар?) запроса в таблице ничего не изменится и число записей
"предварительного" отбора совпадёт с окончательным?
Кроме того видимо ты исходишь из предположения что записи в любом случае
отбираются с одной и той-же скоростью - однако это может быть совсем не
так - и плавность работы ползунка будет далека от идеала.

> Нет, по скорости будет чуть чуть длинее

По скорости это будет КАК МИНИМУМ в 2 раза медленнее просто одиночного
запроса с включенным SET TALK (это ещё при условии что внутри самой функции
НИЧЕГО не делается - если там идёт обновление визуального контрола - то
разница в скорости будет ещё больше) - конечно если заодно исключить разные
нереальные ситуации типа эксклюзивного открытия таблиц - но даже в такой
надуманной ситуации мы будем иметь весьма странную картину - скажем 30
секунд без всякого движения на экране (пока идёт первый запрос) - а потом
очень быстрое "пробегание" ползунка - IMHO весьма непрофессиональный подход
к интерфейсу.

> так как первый селект отбирает .Т. записи по условию, и эта фича
> кэшируется технологией RushMore...

Только в случае эксклюзивного открытия таблицы, или отключения обновления
буферов через SET REFRESH TO 0,0 (в VFP9) - в реальной жизни кэширование не
сильно поможет. Кстати Rushmore к этому имеет весьма опосредованное
отношение.

> Но конечно Progressbar - это определенный тормоз, можно Shape (только о
> его толщине подумайте....) использовать и тогда все более неменее норма...

Никакой способ не даётся забесплатно - особенно если он включает вызов UDF
из запроса - и тем паче вызов UDF для КАЖДОЙ обрабатываемой записи - вариант
Cyv тут более интересен, хотя тоже имеет много ограничений (например в
случае реального условия отбора, нет никакой гарантии что найдётся хотя-бы
одна "проходящая" запись с таким id, что сработает вызов UDF).

> Тогда я вас уверяю, разница незначительная - проверено - believe me...

Ну если у тебя используется выборка в массив, и оно к тому-же работает на
версиях ДО VFP9 - т.е. заранее известно что будет выбрано не более 64000
записей - то наверное ты прав - ты просто не можешь заметить никакой
разницы. В прочих же случаях замедление будет более чем заметно.
IMHO это может проверить любой интересующийся вопросом :) Главное не
сравнивать миллисекунды на табличках по 100 записей, а запустить запрос на
хотя-бы миллионную таблицу и работающий к тому-же хотя-бы 20 секунд (для
прочих случаев сама идея вывода прогресбара очень сомнительна).

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
Отображение шкалы при Select
    #33813210
Valerii
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Игорь здравствуй,
Конечно, в моем случае, есть много если (Если на момент выборки никто данные не изменеяет, если кол-во записей не миллион и пр..) В качестве механизма - поверь, работает...
У меня таблица 620 тыс записссей, обычная средняя величина для фоксовых таблиц, согласен?
Так вот select .T. From ThisTable WHERE eExpression = 0,22 сек. (Celeron-1.2GHz, 256RAM не супер тачка)
_TALLY = 120689 или oProgressBar.Max....

Потом
SELECT fld1, fld2, oProgressBar.Value+1 FROM thisTable WHERE eExpression и все красиво отрабатывается....
Так что этот метод - довольно приличный.... хотя согласен, не идеальный, я в самом начале об этом написал...
Успехов...
...
Рейтинг: 0 / 0
Отображение шкалы при Select
    #33815662
Igor Korolyov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hi Valerii!

> Конечно, в моем случае, есть много если

Вот именно :(

> В качестве механизма - поверь, работает...

То что работает (в некоторых случаях - ограничения описаны выше) это
бесспорно - то что это полезный "механизм" - сомнительно... По крайней мере
по сравнению с тривиальным SET TALK ON.

> У меня таблица 620 тыс записссей, обычная средняя величина для фоксовых
> таблиц, согласен?

Тут IMHO нет "средних величин" (10 записей это тоже вполне нормальная
таблица, равно как и 10 000 000) - чуть важнее тут размер файла/записи - это
определяет тот объём даных которые придётся считать фоксу - учти, что даже
запрос типа SELECT .T. считывает целиком записи попадающие под условие! Нет
в фоксе механизма "частичного" считывания записи - единственное возможное
исключение - memo/general поля, но и тут я не уверен что фокс настолько
интеллектуален чтоб "пропускать" их...
Вот если бы ты делал запрос вида SELECT COUNT(*) FROM ... Тогда другое
дело - тогда для случая полной оптимизации действительно не будет
считываться dbf файл - только соответствующие части cdx файла (что как
правило гораздо быстрее происходит). Но это IMHO довольно редкий случай.

> Так вот select .T. From ThisTable WHERE eExpression = 0,22 сек.
> (Celeron-1.2GHz, 256RAM не супер тачка)

Это значит что ползунок тут ВООБЩЕ не требуется - т.к. SELECT нужные_поля
.... будет выполняться примерно столько-же (ну конечно если размер записи
огромен, то часть времени уйдёт на запись tmp файла - в остальном же разницы
никакой нету)!!! Вот если у тебя навороченные udf-ы в запросе тогда да -
могут быть заметные тормоза на втором этапе.

> _TALLY = 120689 или oProgressBar.Max....

VFP9 значится - иначе получаем ошибку 1809 SQL: Out of memory - т.к. массив
ограничен по размеру.

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
17 сообщений из 17, страница 1 из 1
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Отображение шкалы при Select
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]