Skip site navigation (1) Skip section navigation (2)

Re: Query tool results in grid

From: "Edward Di Geronimo Jr(dot)" <edigeronimo(at)xtracards(dot)com>
To: "Andreas Pflug" <pgadmin(at)pse-consulting(dot)de>
Cc: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>,pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Query tool results in grid
Date: 2006-02-23 19:21:01
Message-ID: 3398.67.83.175.202.1140722461.squirrel@67.83.175.202 (view raw or flat)
Thread:
Lists: pgadmin-hackers
> What I mean is:
> Recoding ctlSqlResult based on the current wxGrid seems a waste of time
> to me. We're currently using wxGrid for View Data, and have enough
> problems with it to get its in-line editing to work. Marking for copying
> appears still non-flawless to me too.

After the changes I made to the View Data grid for copying data, the only
thing you can't do is highlight completely arbitrary groups of cells and
copy them. You can copy any an individual cell, any arbitrary set of
entire rows, any arbitrary set of entire columns, or a rectangular
selection. I didn't allow copying anything else simply because it becomes
a nightmare trying to figure out a logical arrangement for the data in the
clipboard. If you have a suggestion on handling it, say so.

> While it certainly is a good idea to have a super ctlSqlResult2 or
> something, based on wxGrid2 or whatever, that's capable of handling all
> our needs for View Data or the Query Tool, the current base classes
> don't seem appropriate.

I really don't see the issue. I have pgAdmin 1.2.2 and the current dev
version installed on my Windows system. Comparing the dev version with my
results in grid patch against 1.2.2, the grid consistantly displays
results in about half the time the list does. As the data grows larger,
the performance difference increases. This is with just a basic wxGrid.
The View Data grid with its custom table class seems to be interactable as
soon as the query to load the data finishes, and has instant response
time.

If wxWidgets isn't very good, then it means either we deal with its flaws
or we use something else. It's not a reason to sacrifice basic
functionality. Being able to run queries is of limited use if you can't
easily use the results.

Ed


pgadmin-hackers by date

Next:From: Peter EisentrautDate: 2006-02-24 09:44:35
Subject: localpipe
Previous:From: Andreas PflugDate: 2006-02-23 16:39:40
Subject: Re: select inside transactions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group