|
|
|
Отображение шкалы при Select
|
|||
|---|---|---|---|
|
#18+
Форма As Top Level. Выполняется Select. Фоксовская шкала выполнения запроса не отображается. Что мне надо сделать чтоб она отображалась? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2006, 15:18 |
|
||
|
Отображение шкалы при Select
|
|||
|---|---|---|---|
|
#18+
1. Не забыть дать команду Set talk on (думаю, что ты не забыл ;-) ) 2. Сделать форму побольше размером, чтобы стандартный градусник поместился. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2006, 16:46 |
|
||
|
Отображение шкалы при Select
|
|||
|---|---|---|---|
|
#18+
А вопрос уже поднимался Код: plaintext 1. 2. 3. 4. и помоему другого решения нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2006, 16:47 |
|
||
|
Отображение шкалы при Select
|
|||
|---|---|---|---|
|
#18+
У меня был такой эффект на VFP6 - когда основное окно скрыто, и на экране отображалась только маленькая форма, прогресс-бар не показывался, несмотря на Set Talk on и запрос, выполнявшийся полчаса. Увеличил размеры формы - прогресс-бар появился :) Вполне может быть, что эффект сохранился и в более поздних версиях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2006, 20:07 |
|
||
|
Отображение шкалы при Select
|
|||
|---|---|---|---|
|
#18+
Решение есть, я такое делал, правда немного кривовато, но работает: 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... Это основная идея... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2006, 00:01 |
|
||
|
Отображение шкалы при Select
|
|||
|---|---|---|---|
|
#18+
2 Valerii Мне идея очень понравилась - только думаю что исполнение такого запроса сильно затянется (в десятки раз) + время предварительного Селекта но если пользователю будут важнее шашечки а не ехать - вполне подойдет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2006, 08:31 |
|
||
|
Отображение шкалы при Select
|
|||
|---|---|---|---|
|
#18+
karly™1. Не забыть дать команду Set talk on (думаю, что ты не забыл ;-) ) 2. Сделать форму побольше размером, чтобы стандартный градусник поместился. Set TALK ON - стоял. Сделал форму на весь экран - всё равно нет шкалы. Valerii Насчет прогрессбара ActiveXного: нехотелось бы замедлять работу итак селект довольно долго идет, но выбора походу нет. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2006, 10:00 |
|
||
|
Отображение шкалы при Select
|
|||
|---|---|---|---|
|
#18+
Обычно вместо прогресса используют проигрывание авишки. И индикация есть, и не тормозит запрос. Тем более что прогресс никакой корректной информации не показывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2006, 10:19 |
|
||
|
Отображение шкалы при Select
|
|||
|---|---|---|---|
|
#18+
SET TALK ON приведет к возникновению индикатора прогресса в основном окне FoxPro (_SCREEN). Для As Top-Level форм работать не будет. Точнее, будет, но внутри _SCREEN, которое скрыто. Правда, можно попробовать поиграться с SET TALK WINDOW, но тут я не уверен. Вообще, создание приложений целиком на базе As Top-Level форм, лично я считаю баловством. Именно тот случай, когда важнее "шашечки". FoxPro "заточен" под работу с формами IN SCREEN. При построении всего приложения на базе As Top-Level форм будешь натыкаться на самые разные недоразумения, которые потребут усилий по их преодолению. При любом раскладе необходима главная (управляющая) форма всего приложения. Почему в этом качестве не использовать основное окно FoxPro? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2006, 10:36 |
|
||
|
Отображение шкалы при Select
|
|||
|---|---|---|---|
|
#18+
ВладимирМ При любом раскладе необходима главная (управляющая) форма всего приложения. Почему в этом качестве не использовать основное окно FoxPro? Да я согласен, но если приложенице состоит всего то из одной формы не очень красиво тогда смотрится _screen ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2006, 11:11 |
|
||
|
Отображение шкалы при Select
|
|||
|---|---|---|---|
|
#18+
авторНасчет прогрессбара 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2006, 11:20 |
|
||
|
Отображение шкалы при Select
|
|||
|---|---|---|---|
|
#18+
Я уже озвучивал мысль, что если данных много, и распределены они достаточно равномерно, можно запоминать длительность предыдущего расчета, и сообщать пользователю, что текущий расчет продлится "примерно столько же". Если у расчетов есть параметры, длительность можно приводить к одному знаменателю. Например: - если пользователь задал диапазон дат от 01.06.2006 до 10.06.2006, и расчеты заняли 10 минут, то на обсчет одного дня в среднем уходит 1 минута. Когда пользователь в следующий раз укажет 01.03.2006-20.03.2006, мы можем предположить, что расчеты продлятся 20 минут, и сообщить об этом пользователю. Wait window "У вас есть свободное время примерно до " + Transform(DateTime() + lnEvaluation) nowait Select ... from ... where ... Алгоритм оценки может быть достаточно сложным - например, можно не учитывать слишком короткие промежутки, выходные, и т.п. Главное, что бы оценка не считалась дольше, чем сами расчеты ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2006, 13:32 |
|
||
|
Отображение шкалы при Select
|
|||
|---|---|---|---|
|
#18+
проходящийОбычно вместо прогресса используют проигрывание авишки. И индикация есть, и не тормозит запрос. Тем более что прогресс никакой корректной информации не показывает. А по овоему зачем первый Select .T. InTO ARRAY, для того, чтоб показать реальное количество будущих записей... это значение и становиться ActivexProgressBar.Max... Дружище, ты не прав.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2006, 21:48 |
|
||
|
Отображение шкалы при Select
|
|||
|---|---|---|---|
|
#18+
S8662 Valerii Мне идея очень понравилась - только думаю что исполнение такого запроса сильно затянется (в десятки раз) + время предварительного Селекта но если пользователю будут важнее шашечки а не ехать - вполне подойдет. Нет, по скорости будет чуть чуть длинее, так как первый селект отбирает .Т. записи по условию, и эта фича кэшируется технологией RushMore.... Но конечно Progressbar - это определенный тормоз, можно Shape (только о его толщине подумайте....) использовать и тогда все более неменее норма... Вариантов море.... А если в selecte есть вычисляемое поле, тогда в него воткнуть приращение ProgressBara.... Тогда я вас уверяю, разница незначительная - проверено - believe me... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2006, 21:54 |
|
||
|
Отображение шкалы при Select
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2006, 18:24 |
|
||
|
Отображение шкалы при Select
|
|||
|---|---|---|---|
|
#18+
Игорь здравствуй, Конечно, в моем случае, есть много если (Если на момент выборки никто данные не изменеяет, если кол-во записей не миллион и пр..) В качестве механизма - поверь, работает... У меня таблица 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 и все красиво отрабатывается.... Так что этот метод - довольно приличный.... хотя согласен, не идеальный, я в самом начале об этом написал... Успехов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2006, 03:50 |
|
||
|
Отображение шкалы при Select
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 01:15 |
|
||
|
|

start [/forum/topic.php?fid=41&msg=33794943&tid=1591321]: |
0ms |
get settings: |
5ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
139ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
30ms |
get tp. blocked users: |
1ms |
| others: | 190ms |
| total: | 385ms |

| 0 / 0 |
