Re: Lightspeed for frmQuery and other issues.

Dave Page wrote:
>
> -----Original Message----- From: "Andreas
> Pflug"<pgadmin(at)pse-consulting(dot)de> Sent: 30/04/06 14:48:08 To: "Dave
> Page"<dpage(at)vale-housing(dot)co(dot)uk> Cc:
> "pgadmin-hackers(at)postgresql(dot)org"<pgadmin-hackers(at)postgresql(dot)org>
> Subject: Re: Lightspeed for frmQuery and other issues.
>
>
>> EditGrid is untouched. copying of arbitrary groups of cells did
>> *never* work correct. The current implementation will omit cells if
>> it doesn't know how to handle it. This is not acceptable: The ctl
>> needs to be rewritten to not accept selections that can't be
>> executed.
>
>
> I've never run into such a bug, nor has it been reported. How can it
> be reproduced?

Simply select some non-adjacent cells in arbitrary cols and rows.

Had it been reported, it would have been looked at of
> course.
>
>
>> As I already may have mentioned earlier, I don't intend to spent
>> time on the crappy wxGrid. So if anybody else likes to do so,
>> he/she should pay attention not to change the ctlSQLResult
>> interface for that.
>
>
> With or without a bug, removing useful functionality is completely
> unnacceptable. You would be understandably pissed off if a feature
> you used was removed, and I would ensure the author reimplemented it,
> or rollback the change. Bug aside, please fix the copy to clipboard
> to match what was there.

The implementation did not meet the primary requirement, so I objected
clearly and early. You decided to commit an half-brewn "enhancement"
based on a technique that was known not to meet the TODO, i.e. doing it
with a virtual control. You can't be too surprised I basically rolled
back that beast, to have the first step made before the second.

The reporting stuff is going to frustrate you and me as well. I tried to
fix at least the menuing stuff, but had to retract, realizing that you
kind-of reinvented the most ugly interaction between the MNU_
enumeration and schema objects acting on that I removed months ago. This
basically means that it can't be refactored partially, but essentially
needs rewrite. The current implementation style is that of pgAdmin 0.1
to 1.2, which was becoming more and more painful when adding new
features. I'm less than inclined to accept having this creeping back in.

Regards,
Andreas