Several bugs in grouped control |
Post Reply |
Author | |
adrien
Senior Member Joined: 30 April 2007 Location: New Zealand Status: Offline Points: 449 |
Post Options
Thanks(0)
Posted: 20 April 2015 at 10:45pm |
Hi all
I'm having trouble with keyboard navigation and also selected items in a report control. We are using a report control to show active connections through a proxy. This changes frequently. We use AddRecordEx to add records (so we don't need to call Populate), and UpdateRecord if a record changes. This is so we don't need to constantly blow everything away with Populate calls. SELECTION ISSUE However, if the report is grouped on any column, and we have a selected row, and an item phsically above the item changes or is added or deleted, then the currently selected item loses the blue selection background. KEYBOARD NAV ISSUE Also navigating by keyboard is all over the place, it keeps losing current position, so it can jump anywhere in the whole control. This makes it largely unusable for the purpose we're try to use it for. GROUPING ISSUE We're also seeing some cases where we end up with multiple group trees for the same column value. Anyone else seeing problems like this? It seems the report doesn't like to be updated.... at least not items deleted and added / updated frequently.
|
|
adrien
Senior Member Joined: 30 April 2007 Location: New Zealand Status: Offline Points: 449 |
Post Options
Thanks(0)
|
p.s. this is 16.4.0 VS 2010. Also it messes up the selection even if not grouped.
|
|
mcmastl
Admin Group Joined: 14 April 2015 Status: Offline Points: 79 |
Post Options
Thanks(0)
|
We have informed our development team of the issue and will be looking into it. Thank you for bringing this to our attention.
|
|
Luke McMasters, Support Team
CODEJOCK SOFTWARE SOLUTIONS |
|
adrien
Senior Member Joined: 30 April 2007 Location: New Zealand Status: Offline Points: 449 |
Post Options
Thanks(0)
|
Hi, any progress on this? It's blocking development of a key feature for us.
Also can I suggest setting number of forum posts per page to more than 10? It's crazy, topics go to next page far too quick (esp with sticky posts on first page) and are then basically lost. Most forums have this user-configurable and default is about 20 topics.
|
|
olebed
Admin Group Joined: 01 July 2014 Location: Ukraine Status: Offline Points: 841 |
Post Options
Thanks(0)
|
Hi Adrien,
Can you please provide more detailed information and steps to take. If it cannot be re-produced in any of our sample applications provided I would appreciate you sending a sample application so that we could debug it. Regards, Oleksandr Lebed |
|
adrien
Senior Member Joined: 30 April 2007 Location: New Zealand Status: Offline Points: 449 |
Post Options
Thanks(0)
|
Hi Oleksandr
thanks for your reply. It's a bit hard for me to write a new app to do this, would it maybe be possible for me to demonstrate with remote access? Currently it does it in our product, but that's a bit involved to set up and trigger the problem. Regards Adrien |
|
Algae
Senior Member Joined: 08 January 2007 Location: United States Status: Offline Points: 217 |
Post Options
Thanks(1)
|
Problem noted in v.16.26 up to 16.4
Grouping the first frozen column will result in being unable to select the first column item in a row under the group. The scenario: 1. Report control with several frozen columns. 2. Run program. 3. Group by dragging the first column to the Group Box 4. Selection of the item in the first column under the Group will now fail. The fix: In XTPReportRow.cpp, find method: CXTPReportRecordItem* CXTPReportRow::HitTest(CPoint ptPoint, CRect* pRectItem, CXTPReportColumn** ppColumn) const Comment out: /* If (pColumn->GetIndex() >= nFreezeColCount) { rcItem.left = max(rcItem.left, nLeft); rcItem.right = max(rcItem.right, nLeft); } */ We shouldn't care if the column is frozen or not when doing a hit test on a rect. At any rate, this solves the inability to select the first item in a row under a grouped column.
|
|
adrien
Senior Member Joined: 30 April 2007 Location: New Zealand Status: Offline Points: 449 |
Post Options
Thanks(0)
|
I found some more information on this. If you are adding periodically things to the report control and it's grouped, if you change the sort order of the grouped-by column, then add more items, it puts them in a new group with the same group-by value (should be illegal) in the wrong sort order.
So it appears to be ignoring the sort order of the grouped-by column when adding, and it's trying to early out on insert - e.g. relying on ascending sort when looking for the group. If it doesn't find the group then it creates another one. If you have a collection of things which must be unique on a key, surely should use a map not a list.
|
|
adrien
Senior Member Joined: 30 April 2007 Location: New Zealand Status: Offline Points: 449 |
Post Options
Thanks(0)
|
in XTPReportRows.cpp line 553 you have this:
if (pColumn->m_bSortIncreasing && nCompareResult > 0 || !pColumn->m_bSortIncreasing && nCompareResult < 0) This is the early out code so you don't need to evaluate every group to find out the group isn't there. Problem is that when you click on a column header to sort, it isn't moving the groups around properly, so the groups end up in improper order, and then aren't found when it comes to adding a new record. I can fix for us by just using instead if(nCompareResult !=0)continue; However this still doesn't solve the sort bug, and doesn't scale well to large numbers of groups I guess.
|
|
adrien
Senior Member Joined: 30 April 2007 Location: New Zealand Status: Offline Points: 449 |
Post Options
Thanks(0)
|
Problem of duplicate groups goes away (reverting to shipped library code) if I just set
GetRecords()->SetCaseSensitive(FALSE) If I comment this, the problem comes back. I think there must be 2 implementations used to sort, and one takes this into account and the other doesn't (assumes case insensitive always)
|
|
olebed
Admin Group Joined: 01 July 2014 Location: Ukraine Status: Offline Points: 841 |
Post Options
Thanks(0)
|
Hi Algae, you wrote
Thanks for correct scenario to reproduce bug. But problem in other place. Frozen columns can be invisible when are in GroupBy, but keep own indexes. That is why comparing indexes of columns and count of frozen columns are wrong. I've fixed this bug and other related to frozen columns. |
|
olebed
Admin Group Joined: 01 July 2014 Location: Ukraine Status: Offline Points: 841 |
Post Options
Thanks(0)
|
Hi adrien,
We have already fixed many issues in ReportControl with selection, group row, merged cells after last release (v16.4). Those fixes will be available in the next beta release. We expect that beta #1 for v17 will be available this week. Once you have an update installed, please make sure everything works as expected, let me know if there are any issues left. Regards, Oleksandr Lebed |
|
adrien
Senior Member Joined: 30 April 2007 Location: New Zealand Status: Offline Points: 449 |
Post Options
Thanks(0)
|
Hi Oleksandr
thanks for that, I'll be sure to let you know. Regards Adrien |
|
adrien
Senior Member Joined: 30 April 2007 Location: New Zealand Status: Offline Points: 449 |
Post Options
Thanks(1)
|
Hi Oleksandr
I just installed 17 beta 1 and recompiled all our code for it. The report control is a great deal better, but there is still 1 bug I can see. If you have a row selected, then insert or delete a row above this selected row, then the blue selection shifts to a different record. More precisely, the blue selection row stays visually at the same screen location while the records move underneath, so the selected record appears to be different. Keyboard navigation is a LOT better, thanks! Thanks Adrien |
|
olebed
Admin Group Joined: 01 July 2014 Location: Ukraine Status: Offline Points: 841 |
Post Options
Thanks(0)
|
Hi adrien,
What code do you use to reproduce this behavior ? CXTPReportRecords::Add, RemoveAt, RemoveRecord, InsertAt and other don't take into account selected rows. To keep selection you need to reselect. For example see using CXTPReportControl::m_bKeepSelectionAfterSort in CXTPReportHeader::OnLButtonUp() method. |
|
adrien
Senior Member Joined: 30 April 2007 Location: New Zealand Status: Offline Points: 449 |
Post Options
Thanks(0)
|
HI
for insert we use ReportControl methods BeginUpdate(); AddRecordEx(pRecord); EndUpdate(); AdjustScrollBars(); for delete we do BeginUpdate(); RemoveRecordEx(pRecord, TRUE); EndUpdate(); AdjustScrollBars(); Adrien |
|
adrien
Senior Member Joined: 30 April 2007 Location: New Zealand Status: Offline Points: 449 |
Post Options
Thanks(0)
|
p.s. it still seems to know where the cursor is, because when I arrow up, it comes up from the place where the blue selection should have been.
This problem occurs on both insert and delete
|
|
adrien
Senior Member Joined: 30 April 2007 Location: New Zealand Status: Offline Points: 449 |
Post Options
Thanks(0)
|
what it looks like, is that you attach the bSelected flag to the ROW rather than the RECORD, and you re-assign records to different rows when records are added and deleted without updating this flag.
Adrien
|
|
adrien
Senior Member Joined: 30 April 2007 Location: New Zealand Status: Offline Points: 449 |
Post Options
Thanks(0)
|
actually ignore that comment about key up.
|
|
adrien
Senior Member Joined: 30 April 2007 Location: New Zealand Status: Offline Points: 449 |
Post Options
Thanks(0)
|
Hi. This is still a problem in 17, and I don't think it can be adequately fixed by me manually adjusting selected rows on every delete.
the problem is that we use grouping. If a group header row is selected, then a row above that is deleted, then the group header row is no longer selected, instead it's the first child row. Since we don't have any record associated with the header row, we have nowhere to store the selected state, so no way to reinstate the correct state. You guys really should just fix this, when a row is moved by deletion of a row above, the selection state of the row should move with it. If a group header row moves location, so should its selection state. Doing this afterwards is going to be buggy, and non-performant.
|
|
Algae
Senior Member Joined: 08 January 2007 Location: United States Status: Offline Points: 217 |
Post Options
Thanks(0)
|
How are you deleting a non-selected row? I tried with a multi-user system where a row is deleted by another user. In my test, it retained the group selection on the other user's list correctly.
I probably use a process similar to yours. I track the index of the deleted row(s), however. I also test to see if the row has an associated record. I believe group rows do not. Example in "delete" method: CXTPReportSelectedRows* pSelectedRows = GetReportCtrl().GetSelectedRows(); // make sure pSelectedRows exists... then do this: INT_PTR rowCount = pSelectedRows->GetCount(); while (rowCount--) { POSITION pos = pSelectedRows->GetFirstSelectedRowPosition(); pRow = pSelectedRows->GetNextSelectedRow(pos); if (!pRow || !pRow->GetRecord()) continue; // get marker for scroll position index = pRow->GetIndex(); VERIFY(GetReportCtrl().RemoveRowEx(pRow, FALSE)); }; // move selection to next row if possible pRow = GetReportCtrl().GetRows()->GetAt(index); if ( pRow ) GetReportCtrl().SetFocusedRow(pRow); GetReportCtrl().AdjustScrollBars(); GetReportCtrl().RedrawControl(); *this is using v. 16.26. I'm still hacking away at 17 so haven't tried that yet. With any luck, this may offer you a solution. |
|
adrien
Senior Member Joined: 30 April 2007 Location: New Zealand Status: Offline Points: 449 |
Post Options
Thanks(0)
|
We delete flagged records on a timer, so not deleting selected rows at all. This is so dead records can hang around for a while before disappearing so that fast adds and deletes still are visible. I don't believe this is contributing to the problem though.
We call RemoveRecordEx RemoveRowEx just calls through to that anyway. I've looked through the CJ source on this, and it's not clear yet why it's happening. It looks to delete row objects when you remove a record, so you'd think the other unaffected rows would keep the selected attribute (actually there is none, this is stored in a separate array of pointers to row objects). It only affects selected rows below the deleted row. It's like there's another array of rows that is just used for drawing, and that is the one that keeps the flag that makes it draw with the blue background. I never tried this on 16.x, maybe it wasn't broken in that version. |
|
Post Reply | |
Tweet
|
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |