Обсуждение: Bug in status window
I found a bug in the status window. When the activity lines are refreshed, it tries to update them in place, to avoid removing and re-adding every line. That doesn't work if the rows are sorted using the column headers on the list view, and results in blank lines replacing existing ones. Or at least, that appears to be whats happening. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Le 27/03/2010 20:02, Dave Page a écrit : > I found a bug in the status window. When the activity lines are > refreshed, it tries to update them in place, to avoid removing and > re-adding every line. That doesn't work if the rows are sorted using > the column headers on the list view, and results in blank lines > replacing existing ones. Or at least, that appears to be whats > happening. > I'm not able to reproduce this. Really, I wonder how a sort is possible in the status window. A click on an activity line cause a function to be executed, but it only deals with the "activating" of the cancel and terminate buttons. Care to tell us more about this issue? -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
On Sat, Apr 3, 2010 at 3:18 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 27/03/2010 20:02, Dave Page a écrit : >> I found a bug in the status window. When the activity lines are >> refreshed, it tries to update them in place, to avoid removing and >> re-adding every line. That doesn't work if the rows are sorted using >> the column headers on the list view, and results in blank lines >> replacing existing ones. Or at least, that appears to be whats >> happening. >> > > I'm not able to reproduce this. Really, I wonder how a sort is possible > in the status window. A click on an activity line cause a function to be > executed, but it only deals with the "activating" of the cancel and > terminate buttons. > > Care to tell us more about this issue? When the grid is refreshed, rather than remove and re-add all the rows (which would lose the users selection and scroll position), the code attempts to update each of the original rows with the correct data. We seem to have gained the ability to sort by each column, by clicking on the column header. However, if you do that, the in-place update appears to get confused, and in my testing resulted in rows getting blanked out. To reproduce: - Run pgAdmin, connect to a database - Open a query tool, in a database on the server other than the maintenance DB (at this point, I have a browser and querytool connection in the 'phpwiki' database, and the maintenance DB connection in 'postgres'). - Open the server status dialog - Double-click the 'Database' row header in the Activity pane to sort the rows Watch the first two rows vanish, one at a time on subsequent refreshes. Changing the database sort order (by clicking on the header) restores the rows on the next refresh. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Le 03/04/2010 17:08, Dave Page a écrit : > On Sat, Apr 3, 2010 at 3:18 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Le 27/03/2010 20:02, Dave Page a écrit : >>> I found a bug in the status window. When the activity lines are >>> refreshed, it tries to update them in place, to avoid removing and >>> re-adding every line. That doesn't work if the rows are sorted using >>> the column headers on the list view, and results in blank lines >>> replacing existing ones. Or at least, that appears to be whats >>> happening. >>> >> >> I'm not able to reproduce this. Really, I wonder how a sort is possible >> in the status window. A click on an activity line cause a function to be >> executed, but it only deals with the "activating" of the cancel and >> terminate buttons. >> >> Care to tell us more about this issue? > > When the grid is refreshed, rather than remove and re-add all the rows > (which would lose the users selection and scroll position), the code > attempts to update each of the original rows with the correct data. > > We seem to have gained the ability to sort by each column, by clicking > on the column header. However, if you do that, the in-place update > appears to get confused, and in my testing resulted in rows getting > blanked out. > > To reproduce: > > - Run pgAdmin, connect to a database > - Open a query tool, in a database on the server other than the maintenance DB > (at this point, I have a browser and querytool connection in the > 'phpwiki' database, and the maintenance DB connection in 'postgres'). > - Open the server status dialog > - Double-click the 'Database' row header in the Activity pane to sort the rows > > Watch the first two rows vanish, one at a time on subsequent > refreshes. Changing the database sort order (by clicking on the > header) restores the rows on the next refresh. > OK, I see that too. Happens only on Mac. Makes me wonder how wxWidgets can be qualified as a "cross-platform" toolkit. I'm gonna work on this. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
Le 03/04/2010 17:52, Guillaume Lelarge a écrit : > Le 03/04/2010 17:08, Dave Page a écrit : >> On Sat, Apr 3, 2010 at 3:18 PM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >>> Le 27/03/2010 20:02, Dave Page a écrit : >>>> I found a bug in the status window. When the activity lines are >>>> refreshed, it tries to update them in place, to avoid removing and >>>> re-adding every line. That doesn't work if the rows are sorted using >>>> the column headers on the list view, and results in blank lines >>>> replacing existing ones. Or at least, that appears to be whats >>>> happening. >>>> >>> >>> I'm not able to reproduce this. Really, I wonder how a sort is possible >>> in the status window. A click on an activity line cause a function to be >>> executed, but it only deals with the "activating" of the cancel and >>> terminate buttons. >>> >>> Care to tell us more about this issue? >> >> When the grid is refreshed, rather than remove and re-add all the rows >> (which would lose the users selection and scroll position), the code >> attempts to update each of the original rows with the correct data. >> >> We seem to have gained the ability to sort by each column, by clicking >> on the column header. However, if you do that, the in-place update >> appears to get confused, and in my testing resulted in rows getting >> blanked out. >> >> To reproduce: >> >> - Run pgAdmin, connect to a database >> - Open a query tool, in a database on the server other than the maintenance DB >> (at this point, I have a browser and querytool connection in the >> 'phpwiki' database, and the maintenance DB connection in 'postgres'). >> - Open the server status dialog >> - Double-click the 'Database' row header in the Activity pane to sort the rows >> >> Watch the first two rows vanish, one at a time on subsequent >> refreshes. Changing the database sort order (by clicking on the >> header) restores the rows on the next refresh. >> > > OK, I see that too. Happens only on Mac. Makes me wonder how wxWidgets > can be qualified as a "cross-platform" toolkit. > > I'm gonna work on this. > See patch attached. It fixes the issue by using the generic control rather than the native one (which means ordering the listview is no more possible). Sounds good to you? or would you rather keep the capacity to order the list? -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
Вложения
On Sat, Apr 3, 2010 at 5:26 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > See patch attached. It fixes the issue by using the generic control > rather than the native one (which means ordering the listview is no more > possible). > > Sounds good to you? or would you rather keep the capacity to order the list? Well, it would be nice to keep it, but if it's too much work at the moment, I'm not that wed to it. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Le 05/04/2010 11:21, Dave Page a écrit : > On Sat, Apr 3, 2010 at 5:26 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> See patch attached. It fixes the issue by using the generic control >> rather than the native one (which means ordering the listview is no more >> possible). >> >> Sounds good to you? or would you rather keep the capacity to order the list? > > Well, it would be nice to keep it, but if it's too much work at the > moment, I'm not that wed to it. > New patch attached. It only uses generic widget. But it adds sort capacity for all platforms. Image is a bit strange on Mac OS X, but at least it works. I propose the following: * apply my previous patch on the 1.10 branch * apply this patch on trunk So, you won't have the sort capacity in 1.10 (but you won't have the bug you reported), and 1.12 users will all get the sort capacity. Comments? -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
Вложения
Le 11/04/2010 01:58, Guillaume Lelarge a écrit : > Le 05/04/2010 11:21, Dave Page a écrit : >> On Sat, Apr 3, 2010 at 5:26 PM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >>> See patch attached. It fixes the issue by using the generic control >>> rather than the native one (which means ordering the listview is no more >>> possible). >>> >>> Sounds good to you? or would you rather keep the capacity to order the list? >> >> Well, it would be nice to keep it, but if it's too much work at the >> moment, I'm not that wed to it. >> > > New patch attached. > > It only uses generic widget. But it adds sort capacity for all > platforms. Image is a bit strange on Mac OS X, but at least it works. > > I propose the following: > > * apply my previous patch on the 1.10 branch > * apply this patch on trunk > > So, you won't have the sort capacity in 1.10 (but you won't have the bug > you reported), and 1.12 users will all get the sort capacity. > > Comments? > Dave, did you have some time to test or at least read this patch? I intend to commit it (and all the other ones, without ticket 3) tomorrow night. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
On Thu, Apr 15, 2010 at 11:05 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Dave, did you have some time to test or at least read this patch? I > intend to commit it (and all the other ones, without ticket 3) tomorrow > night. I've briefly eye-balled the patch. Seems reasonable - but any reason for using multiple imagelists? Can you use the same one for each listview? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
Le 16/04/2010 13:00, Dave Page a écrit : > On Thu, Apr 15, 2010 at 11:05 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: > >> Dave, did you have some time to test or at least read this patch? I >> intend to commit it (and all the other ones, without ticket 3) tomorrow >> night. > > I've briefly eye-balled the patch. Seems reasonable - but any reason > for using multiple imagelists? Can you use the same one for each > listview? > No reason at all. I fixed it in my git branch. Thanks for noticing. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com