Как можно в засисимости от количества записей в таблице "показать" загрузку с помощью PgoressBar? То есть чем больше записей, тем медленнее ползунок...

Странный вопрос
Ну делай цикл

Код

var i: Integer; begin Table1.Active := true; with ProgressBar1 do  for i:=1 to Table1.RecordCount do begin      Position:=Round((i/Table1.RecordCount)*100); end; end;

Цитата

Ну делай цикл

Нет, так нельзя. Надо оценить время открытия таблицы заранее. Открывать её в отдельном потоке, а в основном потоке запускать ProgressBar.

А зарание никак. В процесс открытия то же вряд ли можно влезть. Можно только сначало открыть таблицу и засечь время

Код

a, b, c : TDateTime; begin a := time(); Table1.Active := true; b := time(); c := b-a; end;

А потом иммитировать открытие таблицы и показать ProgressBar тем способом, который я уже приводил

Цитата

Странный вопрос Ну делай цикл Код var i: Integer; begin Table1.Active := true; with ProgressBar1 do for i:=1 to Table1.RecordCount do begin     Position:=Round((i/Table1.RecordCount)*100); end; end;

Странный подход, я бы сказал.... По-моему, действительно дело в обработке потоков....

Maverick
ну и как предлогаешь влезть в поток?
И потом, для работы ProgressBar, нужно что-то принять за 100%, а как ты собираешься узнать сколько время будет загружаться таблица, до того момента как она загружена? Это все равно, что сказать как закончится матч РОССИЯ-ПОРТУГАЛИЯ прямо сейчас, не дожидаясь пока матч начнется.

Cashey
Я просто в шоке.... я счас попробовал - действительно работает.... но как? почему?

Цитата

with ProgressBar1 do for i:=1 to Table1.RecordCount do begin     Position:=Round((i/Table1.RecordCount)*100);

Почему движения Bar зависят от степени открытия таблицы - я не вижу здесь связи в коде..... я скорее не поверю собственным глазам....

Совершенно посторонняя переменная i контролирует Bar.... Что тормозит Bar от мгновенного пробега? Загруженность процессора? Переключение между процессами открытия таблицы и отрисовкой позиции Bar? Значит, все равно потоки косвенно?

с таблицами это не получится. с запросами - можно, только не со всеми субд. у запросов есть метод Fetch и свойство (PacketSize, кажется, не помню) отвечающее за кол-во профетчиваемых записей. вот там можно в цикле профетчить все записи, сопровождая это дело беганьем прогрессбара. а варианты с "предугадыванием времени" - это отстой. время зависит и от процессора, и от скорости обращения к винту, и от объёма свободной памяти, и от размера базы, а для сетевых БД - ещё и от пропускной способности сети и загруза её в данный момент. тут запаришься угадывать.

Работает.... Законектился с сервером, именно Table, выбрал таблицу покрупнее - все отработало и Bar как ручной сделал все..... Я сам вот сижу и думаю как?

Да блин не может это работать. Этот код делает совсем не то, что прдполагается в топике. Народ, почитайте об отображении визуальной информации из наборов данных, почитайте ФАК в конце концов, не зря же Вит писал. После открытия таблицы RecordCount не даст правильного количества выбранных записей, если не был сделан FetchAll.
Получается, что сначала НД открыли, а потом пробегаете по его записям. А надо то отобразить время открытия НД. А если ваш Table.Active будет отрабатывать минуты 2, а с БДЕ такое возможно, я сталкивался?
А оценить время открытия *приблизительно) можно. ТОлько здесь общего решения нет. Для каждого вида запроса и движка БД решение своё.

Maverick, что у тебя работает?

gray_k, я не знаю, кто что писал, а делается это в два этапа: выполняем запрос вида select count (*) from ...., этот запрос отработает на порядки быстрее любого другого, узнаём из него кол-во записей, потом запускаем сам запрос, уже не count (*), а перечисление полей по-честному (есс-но, с теми же from, where, etc.). после этого открываем запрос и фетчим его потихоньку. кол-во записей, кторое всего придётся фетчить - известно.

есстественно, что с ущербной бде это не работает. а в ado, midas, даже в том же ibx - за милую душу.

Да, если сначала послать запрос на count(*), то работать будет, про это я не подумал .
А ты не оценивал, насколько изменится скорость выполнения коде, если после Open сразу сделать FetchAll и если фетчить по одной записи? Просто интересно.

gray_k, всё зависит от способа доступа. в ADO в этом плане много вкусного - асинхронный фетч, масса настроек и т.д. в ibx и TClientDataset - всё немного попроще, но тоже забавно. по скорости - впечатление слишком субъективное при фетче по 20-30 записей тебе кажется, что таблица открывается мгновенно, и по мере записей подсасывается из базы. нажмёшь на гриде Ctrl+End - и получишь тот же FetchAll со всеми вытекающими так что в принципе смысла в этом особо нет. я по работе всегда делаю FetchAll, и всегда в основном потоке, но это связано с тем, что db-aware контролы я вообще не пользую. для нервных юзеров на экране висит табличка типа "Hold your horses...". и на мой взгляд оптимальный вариант, это

Код

Cursor := crSqlWait; try  try    Table.Active := TRUE;  except    on E: Exception do MessageDlg ('Ошибка открытия таблицы:'#13#13 + E.Message, mtError, [mbOk], 0);  end; finally  Cursor := crDefault; end;

а всякие там прогрессбары - цыганское великолепие.

Это сообщение отредактировал(а) x77 - 8.4.2004, 13:50

Значит так....

Я тоже был уверен, что не сработает....
Кинул на форму Table, DataSource, Grid, Progressbar и кнопку.....
Все обычное - BDE.... Table подключил к серверу Informix к очень большой таблице.... На клик кнопки повесил указанный Cashey код.... прямо скопировал, не менял....

вот это

Цитата

Код var i: Integer; begin Table1.Active := true; with ProgressBar1 do for i:=1 to Table1.RecordCount do begin     Position:=Round((i/Table1.RecordCount)*100); end; end;

Запустил, нажал на кнопку - ProgressBar начал постепенно (!) , равномерно заполняться... Когда заполнился весь - в Grid появилась таблица....

Я сам ОФИГЕЛ, но это факт.... я согласен со всем вами сказанным, это не должно работать.... Я до сих пор не могу понять как.... Я уже много раз запускал и ОФИГИВАЛ....

Maverick, офигевать тут не с чего абсолютно. убери весь код после Active := TRUE - и твоя таблица откроется мгновенно. и мгновенно профетчится. в коде, который привел Cashey строчка Position:=Round((i/Table1.RecordCount)*100); даёт дикие тормоза. сделай код таким:

Код

Table1.Active := true;  with ProgressBar1 do begin    Max := Table1.RecordCount;    for i:=1 to Table1.RecordCount do begin      Position := i; //      j := Table1.RecordCount;    end;  end;

и у тебя всё будет летать. а потом откомментируй вон ту строчку с обращением к RecordCount - и получишь тоже самое, что и было.

короче говоря, в коде Cashey'я просто исскуственно замедляется проход прогрессбара уже после того, как таблица давно открыта. а пока идёт в цикле обращение к RecordCount - есс-но, записи в гриде не отображаются.

Добавлено @ 14:43
в конце концов, поставь после Active := TRUE всего одну строчку: DBGrid1.Update; и ты увидишь значения полей задолго до конца пробега прогрессбара. другой вариант - вставить ProcessMessages - и ты будешь уже гулять по всей таблице, когда прогресбар будет ещё ползти и ползти

Да то, что открывается гораздо медленнее я сразу понял.... Я не мог понять, почему цикл влияет на Bar.... Почему не сразу пробегает мгновенно как должно быть.... Неужели RecordCount до такой степени тормозючий? Да не могет быть.....
Добавлено @ 14:47
Да и с ProcessMessages я тоже игрался.... Обманули...... Не.... пора в отпуск....

Maverick, это вопрос к DbiGetRecordCount и DbiGetExactRecordCount. бде всё тормознючее, увы.

разве я тебя обманул? или ты не про меня? не понял эту фразу я же привёл в примере. ничего не делаем, просто присваиваем RecordCount какой-то переменной без всяких вычислений. и всё, система ложится. закомментируй обращение к RecordCount - и будет пробегать влёт, как положено. по большому счёту можно было с таким же успехом написать

Код

Table.Open; ProgressBar.Max := RecordCount; for i := 1 to Table.RecordCount do begin  ProgressBar.Position := i;  Sleep (100); end;

Да нет... это так - эмоции.... Понимаешь, я был так уверен, что это не сработает, вся моя сущность была против.... Но когда запустил и получилось - все равно как .... Выглядело очень лонично - бар прошелся, таблица открылась - я просто дара речи лишился... Я был настолько шокирован, что оцепенел как кролик перед удавом.... Была мысль вставить ProcessMessage, что потом и сделал, но в из-за шока подумалось - а вдруг именно в этом и есть уловка... в отсутствии.... Поэтому реплика "Обманули" это ни к кому.... Это себе... Ну повелся как на Мавроди.... Спасибо за вывод из шока....

Maverick,

x77
Абсолютно верно, если запустить мой код (например, в кнопке) то в гриде записи появятся одновременно с концом работы ProgressBar'а. Вот только это не показатель загрузки таблицы, а мы задерживаем циклом отображение данных в гриде.
Вообщем-то можно использовать если надо обмануть пользователя и показать ему "вот видете скока надо ждать"
А иначе я вообще не вижу смысла использовать Бар. Я проверил время загрузки таблицы dBase с более чем 15000 записями занимает ок. 60 миллисикунд. ProgressBar имеет смысл использовать только если загрузка больше хотя бы 3-5 сек.

И еще x77 твой вариант тоже не идет, я проверил время загрузки Квери и Тэйбла почти одинаково, своим кодом ты обеспечишь 2-х кратную ошибку

Цитата

Вот только это не показатель загрузки таблицы, а мы задерживаем циклом отображение данных в гриде.

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

Цитата

Вообщем-то можно использовать если надо обмануть пользователя и показать ему "вот видете скока надо ждать" А иначе я вообще не вижу смысла использовать Бар. Я проверил время загрузки таблицы dBase с более чем 15000 записями занимает ок. 60 миллисикунд. ProgressBar имеет смысл использовать только если загрузка больше хотя бы 3-5 сек.

У меня таблица была в полмиллиона записей - ты обманул меня на полторы минуты.... слишком жестоко даже для среднего пользователя... Да и смысл - создавать ореол проге? Обычно такие таблицы грузятся секунд 15...




Добавлено @ 17:04
Я где-то компонент видел соответствующий..... ищу....

Добавлено @ 17:13
не нашел ... ну ладненько....

А какие типы тиблиц вы используете?
Я пробовал на Paradox7 - таблица на 500 тыс записей открывается моментально, и никакого процесса показа не происходит

Informix... Жутко загруженный сервер и сеть...

а может в BDE есть какие-нибудь функции типа Dbi...тыры-пыры?
в некорорых программа это ведь реализовано, наверное.

dsergey, в бде - нет. есть левосторонние пакеты, которые работают с теми же dbf без участия бде. и вот в них мне такое встречалось. но навскидку я не помню

Неужели крутые программисты из дяди Бормана немогли сделать что-нибудь для показа процесса загрузки таблиц?

dsergey, не было смысла. и таблицы и квери, работаеют, по большому счёту, одинаково, разница только в тои, что квери позволяет выполнять запросы. но если ты посмотришь исходники, сами методы организации буфера, доступа к записям, - используют одни и те же процедуры bde, а точнее - dbi. в этом смысле бормановская TQuery представляет собой как бы эмуляцию нормальной квери, но открывается она точно так же, как и таблица. гнусное нае@#$во, в общем. а таблицы открываются влёт, т.к. все записи из базы они не сосут: это происходит только при нажатии, например, Ctrl+End на гриде.

смеха ради воткни на форму Table1 и Query1, пропиши для обоих Open, и посмотри, что он запускает. для обоих запускаться будет метод TDataSet.Open, сводящийся к вызову TDataSet.SetActive. он вызовет виртуальный метод InternalOpen, который переопределён в TBdeDataSet, являющимся одним из предков как квери, так и таблицы. все различия между ними связаны с обработкой запросов, парааметров, и пр., а механизм доступа к данным одинаков абсолютно. и заключается этот механизм в буферизованном чтении таблицы, предполагающем мгновенное открытие и подсос по мере надобности. спрашивается, зачем там прогрессбар? тормозить может только обработка сложного запроса, но отобразить это процесс невозможно, т.к. на любом субд он представляет из себя "чёрный ящик", никто не знает, сколько времени он займёт и на каком этапе в данный момент эта обработка находится. а после того, как сам запрос "сгенерён", открытие происходит действительно влёт независимо от кол-ва записей.

тормоза при работе с парадоксовскими таблицами как правило вызваны корявостью самого кода, когда при инициализации программы кто-то умный открывает десяток справочных таблиц, связанных между собой десятком лукап-полей, а потом жалуется, какое, дескать, тормознутое бде. а реально, при грамотной организации работы, бде - одна из самых быстрых субд вернее, самая быстрая "иммитация" субд.

То х77 - огромное спасибо за объяснения.

Кажись компонентик есть для энтого дела.


Добавлено @ 10:38
Нашел как называется : TDBProgressBar, правда версия 2.7 для Delphi5
Так что кому нужно для Delphi 6 и выше можете поискать в Net.

Никогда не пользовался этим компонентом - предлагаю не проверенный товар.

Если устраивает кого такие условия, могу скинуть

dsergey, это не столько объяснения, сколько рассуждения вслух. ребята, читайте исходники. на ночь, вместо Hustler и Playboy'а. и всё будет классно ;)

jonik_Dk, кидай на [email protected]

кидай ентот компонентик сюда dsermail {at} rambler.ru

Я кинул на [email protected].

Если не получишь пиши, не жадный кину еще раз!

на выходных поглядим

После просмотра, просьба высказаться как работает компонент.

Времени нет даже поставить его, не то чтобы проверить !!!

Надо было написать, что он для Delphi5.
А как его установить для 7-ой версии, например?

компонент этот юзает стандартные функции бде, в частности, DbiRegisterCallback. смысл её в том, чтобы, например, возвращать процент выполнения большой batch-операции, отменить выполнение квери и др. но я никогда не слышал, чтобы этой функцией можно было выдать процесс выполнения запроса. если интересно, вот копия из справки по бде:

Цитата

Types of callbacks The application can choose to be notified of many different types of events, depending on which callback type it registers. The application can specify the following callback types in a call to DbiRegisterCallback. Callback Description cbGENPROGRESS Informs applications about the progress made during large batch operations. cbRESTRUCTURE Supplies information about an impending action and requests a response from the caller. cbBATCHRESULT Batch processing results. cbTABLECHANGED Notifies user that table has changed. cbCANCELQRY Allows user to cancel a Sybase query. cbINPUTREQ A BDE driver requests input from user. cbDBASELOGIN Enables clients to access encrypted dBASE tables. cbFIELDRECALC Field(s) recalculation. cbTRACE Trace. cbDBLOGIN Database login. cbDELAYEDUPD Cached updates callback. cbNBROFCBS Number of callbacks. Callback function declarations and associated parameter lists, function return types, and callback data types are defined in the BDE header file for the particular BDE-using programming tool used (for Borland C, this header file is called IDAPI.H, for C++Builder, it is BDE.HPP, and for Delphi it is BDE.INT). Return codes The application responds to a callback by issuing a return code that commands an appropriate action: Return code Action description cbrUSEDEF  Take default action. cbrCONTINUE Continue. cbrABORT Abort the operation. cbrCHKINPUT Input given. cbrYES  Take requested action. cbrNO  Do not take requested action. cbrPARTIALASSIST  Assist in completing the job. Registering a general progress report callback Suppose that an application must copy a million-record table, and you want to periodically display a progress report on screen indicating the progress of the copy operation. You would use the following procedure: 1. Write the body of the of the progress callback function, declaring it with an associated predefined parameter list: typedef CBRType far *pCBRType; typedef CBRType (DBIFN * pfDBICallBack)  ( CBType        ecbType,            // Callback type UINT32        iClientData,        // Client callback data pVOID          pCbInfo              // Call back info/Client Input ); 2. The application allocates memory for the buffer pCbBuf to be used for passing data back and forth from the application to the function, and pointing to a CBPROGRESSDesc structure. typedef struct { INT16        iPercentDone;        // Percentage done DBIMSG        szMsg;              // Message to display } CBPROGRESSDesc; typedef CBPROGRESSDesc far * pCBPROGRESSDesc; 3. To register a callback, the application calls DbiRegisterCallback passing cbGENPROGRESS as the value for ecbType. 4. The application issues a call to DbiBatchMove. 5. BDE returns either a percentage done (in the iPercentDone parameter of the CBPROGRESSDesc structure), or a message string to display on the status bar. The application can assume that if the iPercentDone value is negative, the message string is valid; otherwise, the application needs to consider the value of iPercentDone. The message string format is <Text String><:><Value> to allow easy international translations. For example: Records copied: 250 6. To continue processing the application returns the code cbrUSEDEF. The application can abort the BDE function call in progress by returning cbrABORT.

dSergey:
Я писал, что компонент для Delphi5, надо быть внимательней.

x77: Спасибо, но я противник BDE. Жаль что он работает через BDE.

Может, кто знает, как установить этот компонент по D7.

Этот компонент требует файл Proxies.pas - у кого есть пришлите на dsermail {at} rambler.ru, пожалуйста.