Quoting Andreas Pflug <[EMAIL PROTECTED]>:
I still don't see a need for that extended handling, because the ctl
always allowed row selections (and column selections can be achieved
from SELECT ...., a basic SQL feature... )
Very often in my work, I would not know exactly what columns I need
the data from until after I see the results of the query. Someone
would walk into my office and say "What's wrong with Joe Smith's
account?" I'd run a query to get an overview of the account, and what
columns I needed would change depending on what looked to be wrong.
It's a lot easier to click on the cell I need and hit copy than to run
another query to narrowing things down.
Users dont care about virtual controls or not.
They do. It's the speed issue, esp. on non-win32.
The implementation I did was 4x faster than the old implementation,
which apparently had been acceptable for a long time, but also offered
more features. There was no tradeoff to that work, unless you had a
phobia of grids. Now you're into trading features for speed.
Users care about basic functionality like being able to copy
subsets of data into the clipboard. Only behing able to copy
entire rows at a time is a half brewn implementation. It would
have been much easier for you to refactor things into a virtual
table
Wrong. Look at the current implementation, which basically takes
version 5021 and *removes* 100 lines of code.
Sticking the new data retrieval code into a virtual table still would
have been less work than ripping out the grid and implementing a
virtual list. Most of the code you removed was there either to
implement the additional clipboard support your code doesn't handle,
or to work around your earlier instance on keeping the retrieval the
same.
Not quite, I always insisted on doing it "the virtual way" and made
quite clear that I'd enforce it. Explaining how to do it required more
work than to do it, I said that earlier. See how it works now, and do
it with wxGrid if you like.
You said this months ago when I did the initial grid patch:
Please *dont* try to handle data retrieval different from what it is
now. We do have the problem of long GUI updates, but we also have
consistent behaviour on the libpq side, making it comparable to psql
and so forth. This must remain guaranteed
You refused to clarify when asked what was and wasn't acceptable, and
basically gave the impression that nothing could possibly satisfy you.
So, the only thing that seemed reasonable to do was to disturb as
little code as possible. Hence how we ended up where we're at now.
Ed
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
