Re: where are the query output tuples stored
От | Dave Page |
---|---|
Тема | Re: where are the query output tuples stored |
Дата | |
Msg-id | AANLkTikdhcJopp0RnnZe2eVi36gJYLmypjPvCMXjDobV@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: where are the query output tuples stored (Qiqi YU <vonclemay@gmail.com>) |
Список | pgadmin-support |
On Tue, Mar 15, 2011 at 10:01 AM, Qiqi YU <vonclemay@gmail.com> wrote: > 2011/3/14 Dave Page <dpage@pgadmin.org>: >> On Mon, Mar 14, 2011 at 2:39 PM, Qiqi YU <vonclemay@gmail.com> wrote: >>> Hi Dave, >>> >>> Thanks for your fast reply. As I went through the code of function >>> ctlSQLResult::DisplayData(bool single), there seems to be no calling >>> of wxGrid Control to display data? My understanding is that the >>> displayData function would set up the frame of the outputs (i.e. all >>> the column attributes name and row number). But where is the output >>> data being inserted into the output table? >> >> It's not - you've got it backwards. The grid control calls >> sqlResultTable::GetValue() whenever it wants to render a cell. That >> function returns the text to display. > > For this part, I still can't get it. There are two parts of the > codes, executeQuery and onQueryComplete. The displayData function is > called inside onQueryComplete, so is that pgadmin would call grid > control to insert data after it has called the function displayData? You're still thinking about it backwards. pgAdmin doesn't push the data into the grid anywhere - you won't see code like grid->SetCellValue(row, col, value); In ctlSQLResult::DisplayData(), the important part of the code is this: /* * Resize and repopulate by informing it to delete all the rows and * columns, then append the correctnumber of them. Probably is a * better way to do this. */ wxGridTableMessage *msg; sqlResultTable*table = (sqlResultTable *)GetTable(); msg = new wxGridTableMessage(table, wxGRIDTABLE_NOTIFY_ROWS_DELETED, 0, GetNumberRows()); ProcessTableMessage(*msg); delete msg; msg = newwxGridTableMessage(table, wxGRIDTABLE_NOTIFY_COLS_DELETED, 0, GetNumberCols()); ProcessTableMessage(*msg); delete msg; msg = newwxGridTableMessage(table, wxGRIDTABLE_NOTIFY_ROWS_APPENDED, NumRows()); ProcessTableMessage(*msg); delete msg; msg = new wxGridTableMessage(table, wxGRIDTABLE_NOTIFY_COLS_APPENDED, thread->DataSet()->NumCols()); ProcessTableMessage(*msg); delete msg; What this does is inform the grid that the data in the underlying table has been changed. First, we tell it that all rows and all columns have been removed (just so we can start from a clean state). We then tell it how many rows and columns are currently in the table (really, the PGresult structure from libpq, encapsulated by the sqlResultTable class). The grid itself (not pgAdmin) then determines which cells it needs to render, and for each one, it calls sqlResultTable::GetValue(). It does this efficiently - it'll work out which cells it needs to render by looking at whether or not they will be visible. It then renders a few extra in each direction to ensure that scrolling doesn't cause any strange effects. From then on, it'll only render cells when they are about to be scrolled into view. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgadmin-support по дате отправления: