Re: Lightspeed for frmQuery and other issues.

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: <pgadmin(at)pse-consulting(dot)de>, <dpage(at)vale-housing(dot)co(dot)uk>
Cc: <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Lightspeed for frmQuery and other issues.
Date: 2006-04-30 17:14:41
Message-ID: 008201c66c79$99c36749$6a01a8c0@valehousing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers


-----Original Message-----
From: "Andreas Pflug"<pgadmin(at)pse-consulting(dot)de>
Sent: 30/04/06 17:23:04
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.

> That's in frmQuery only, right? If so, the local solution is fine. If
> it's more global, it should go somehow to dlgClasses.

Yes, but it used wxGrid methods to build the report, thus, like the copy functionality, would have needed fixing to work with a listview (actually, frmReport has a listview->reporttable method that could be used).

> > Please restore the functionality or I will back out the patch until it is completed in it's > > entirety.

> Which functionality?

The ability to copy columns and arbitrary groups of cells as well as rows.

> Again: I said early enough the base was wrong. And I didn't see *any*
> speed increase on linux. Probably, any virtual solution will be ok, but
> any non-virtual solution *cant* be ok.

The point was that it was a distinct improvement, even if not the ultimate solution - anyway, that's irrelevant now so let's move on.

> It should have been, but things are horribly intervowen. I'd have to
> understand in detail what's going on to continue, because apparently
> removing MNU_XXX entries would kill methods too.

Are you doing this or me? I'm happy to work on it if you'll provide feedback when needed. If you're doing it though, let me know and I'll do something else.

/D

-----Unmodified Original Message-----
Dave Page wrote:
>
> -----Original Message-----
> From: "Andreas Pflug"<pgadmin(at)pse-consulting(dot)de>
> Sent: 30/04/06 16:19:51
> 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.
>
>>It wasn't removed explicitely, but the underlying class that didn't meet
>>the requirement was backed out. You've painted the wall before
>>wallpapering it.
>
>
> Quickreport sat over that class as well - is that now broken too?

That's in frmQuery only, right? If so, the local solution is fine. If
it's more global, it should go somehow to dlgClasses.
>
> Please restore the functionality or I will back out the patch until it is completed in it's entirety.

Which functionality?
>
> You complain about the work that led to significant speed increase from the original code, but at least we busted a gut to make sure it didn't break any existing functionality.

Again: I said early enough the base was wrong. And I didn't see *any*
speed increase on linux. Probably, any virtual solution will be ok, but
any non-virtual solution *cant* be ok.

>
>
>>It's not a problem of the factories, they do what they should and will
>>work *if used*.
>
>
> Like I said, I'll look at this. I didn't grok that the failed attempt you mentioned was only a minor rejig.

It should have been, but things are horribly intervowen. I'd have to
understand in detail what's going on to continue, because apparently
removing MNU_XXX entries would kill methods too.

Regards,
Andreas

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Dave Page 2006-04-30 17:18:40 Re: Lightspeed for frmQuery and other issues.
Previous Message Andreas Pflug 2006-04-30 16:44:13 Re: Lightspeed for frmQuery and other issues.