Re: Lightspeed for frmQuery and other issues.
От | Dave Page |
---|---|
Тема | Re: Lightspeed for frmQuery and other issues. |
Дата | |
Msg-id | 008401c66c83$1296c11f$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 18:44:01 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. > > (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
В списке pgadmin-hackers по дате отправления: