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

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 18:22:29
Message-ID: 008401c66c83$1296c11f$6a01a8c0@valehousing.co.uk (view raw or flat)
Thread:
Lists: pgadmin-hackers

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

> > (actually, frmReport has a listview->reporttable method that could be
> > used).

> I don't quite understand that.

void frmReport::AddReportTableFromListView(ctlListView *list);

> Since most of the work is specific, you'd better do it. I can assist 
> with menu/general stuff, which should reduce to some "new 
> reportSomethingFactory" in frmMain::CreateMenus(). Submenus are now 
>handled automatically, so even the events.cpp is totally generic now. 

Ok - it's a holiday weekend here though, so might not be until later this week.

> I'm going to extend programmers-readme.txt ASAP.

Wuh? Where's that then? Does it document the factories?

/D

-----Unmodified Original Message-----
Dave Page wrote:
> 
> 
> Yes, but it used wxGrid methods to build the report, thus, like the
> copy functionality, would have needed fixing to work with a listview

I already changed that to the new interface.

> (actually, frmReport has a listview->reporttable method that could be
> used).

I don't quite understand that.

> 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.

An improvement that ignores basics is useless.

>> 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.

Since most of the work is specific, you'd better do it. I can assist 
with menu/general stuff, which should reduce to some "new 
reportSomethingFactory" in frmMain::CreateMenus(). Submenus are now 
handled automatically, so even the events.cpp is totally generic now. 
I'm going to extend programmers-readme.txt ASAP.

Regards,
Andreas

Responses

pgadmin-hackers by date

Next:From: Dave PageDate: 2006-04-30 18:24:09
Subject: Re: programmers-readme.txt
Previous:From: Andreas PflugDate: 2006-04-30 17:58:38
Subject: programmers-readme.txt

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