Re: Lightspeed for frmQuery and other issues.

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: Lightspeed for frmQuery and other issues.
Дата
Msg-id 008201c66c79$99c36749$6a01a8c0@valehousing.co.uk
обсуждение исходный текст
Ответ на Lightspeed for frmQuery and other issues.  (Andreas Pflug <pgadmin@pse-consulting.de>)
Ответы Re: Lightspeed for frmQuery and other issues.  (Andreas Pflug <pgadmin@pse-consulting.de>)
Список pgadmin-hackers
-----Original Message-----
From: "Andreas Pflug"<pgadmin@pse-consulting.de>
Sent: 30/04/06 17:23:04
To: "Dave Page"<dpage@vale-housing.co.uk>
Cc: "pgadmin-hackers@postgresql.org"<pgadmin-hackers@postgresql.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
workwith 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'smove 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,
letme know and I'll do something else. 

/D


-----Unmodified Original Message-----
Dave Page wrote:
>
> -----Original Message-----
> From: "Andreas Pflug"<pgadmin@pse-consulting.de>
> Sent: 30/04/06 16:19:51
> To: "Dave Page"<dpage@vale-housing.co.uk>
> Cc: "pgadmin-hackers@postgresql.org"<pgadmin-hackers@postgresql.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
gutto 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

В списке pgadmin-hackers по дате отправления:

Предыдущее
От: Andreas Pflug
Дата:
Сообщение: Re: Lightspeed for frmQuery and other issues.
Следующее
От: "Dave Page"
Дата:
Сообщение: Re: Lightspeed for frmQuery and other issues.