Codejock Forums Homepage
Forum Home Forum Home > Codejock Products > Visual C++ MFC > Report Control
  New Posts New Posts RSS Feed - Several bugs in grouped control
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

Several bugs in grouped control

 Post Reply Post Reply
Author
Message
adrien View Drop Down
Senior Member
Senior Member


Joined: 30 April 2007
Location: New Zealand
Status: Offline
Points: 449
Post Options Post Options   Thanks (0) Thanks(0)   Quote adrien Quote  Post ReplyReply Direct Link To This Post Topic: Several bugs in grouped control
    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.
Back to Top
adrien View Drop Down
Senior Member
Senior Member


Joined: 30 April 2007
Location: New Zealand
Status: Offline
Points: 449
Post Options Post Options   Thanks (0) Thanks(0)   Quote adrien Quote  Post ReplyReply Direct Link To This Post Posted: 20 April 2015 at 10:54pm
p.s. this is 16.4.0 VS 2010.  Also it messes up the selection even if not grouped.
Back to Top
mcmastl View Drop Down
Admin Group
Admin Group
Avatar

Joined: 14 April 2015
Status: Offline
Points: 79
Post Options Post Options   Thanks (0) Thanks(0)   Quote mcmastl Quote  Post ReplyReply Direct Link To This Post Posted: 21 April 2015 at 12:56pm
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
Back to Top
adrien View Drop Down
Senior Member
Senior Member


Joined: 30 April 2007
Location: New Zealand
Status: Offline
Points: 449
Post Options Post Options   Thanks (0) Thanks(0)   Quote adrien Quote  Post ReplyReply Direct Link To This Post Posted: 05 May 2015 at 6:44pm
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.
Back to Top
olebed View Drop Down
Admin Group
Admin Group


Joined: 01 July 2014
Location: Ukraine
Status: Offline
Points: 841
Post Options Post Options   Thanks (0) Thanks(0)   Quote olebed Quote  Post ReplyReply Direct Link To This Post Posted: 13 May 2015 at 8:02am
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
Back to Top
adrien View Drop Down
Senior Member
Senior Member


Joined: 30 April 2007
Location: New Zealand
Status: Offline
Points: 449
Post Options Post Options   Thanks (0) Thanks(0)   Quote adrien Quote  Post ReplyReply Direct Link To This Post Posted: 13 May 2015 at 11:33pm
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
Back to Top
Algae View Drop Down
Senior Member
Senior Member
Avatar

Joined: 08 January 2007
Location: United States
Status: Offline
Points: 217
Post Options Post Options   Thanks (1) Thanks(1)   Quote Algae Quote  Post ReplyReply Direct Link To This Post Posted: 03 June 2015 at 2:59pm
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.

 

Back to Top
adrien View Drop Down
Senior Member
Senior Member


Joined: 30 April 2007
Location: New Zealand
Status: Offline
Points: 449
Post Options Post Options   Thanks (0) Thanks(0)   Quote adrien Quote  Post ReplyReply Direct Link To This Post Posted: 15 June 2015 at 10:40pm
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.
Back to Top
adrien View Drop Down
Senior Member
Senior Member


Joined: 30 April 2007
Location: New Zealand
Status: Offline
Points: 449
Post Options Post Options   Thanks (0) Thanks(0)   Quote adrien Quote  Post ReplyReply Direct Link To This Post Posted: 15 June 2015 at 11:10pm
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.
Back to Top
adrien View Drop Down
Senior Member
Senior Member


Joined: 30 April 2007
Location: New Zealand
Status: Offline
Points: 449
Post Options Post Options   Thanks (0) Thanks(0)   Quote adrien Quote  Post ReplyReply Direct Link To This Post Posted: 16 June 2015 at 12:20am
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)
Back to Top
olebed View Drop Down
Admin Group
Admin Group


Joined: 01 July 2014
Location: Ukraine
Status: Offline
Points: 841
Post Options Post Options   Thanks (0) Thanks(0)   Quote olebed Quote  Post ReplyReply Direct Link To This Post Posted: 22 June 2015 at 10:13am
Hi Algae, you wrote

Originally posted by Algae Algae wrote:

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.


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.  
Back to Top
olebed View Drop Down
Admin Group
Admin Group


Joined: 01 July 2014
Location: Ukraine
Status: Offline
Points: 841
Post Options Post Options   Thanks (0) Thanks(0)   Quote olebed Quote  Post ReplyReply Direct Link To This Post Posted: 22 June 2015 at 10:23am
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
Back to Top
adrien View Drop Down
Senior Member
Senior Member


Joined: 30 April 2007
Location: New Zealand
Status: Offline
Points: 449
Post Options Post Options   Thanks (0) Thanks(0)   Quote adrien Quote  Post ReplyReply Direct Link To This Post Posted: 24 June 2015 at 6:11am
Hi Oleksandr

thanks for that, I'll be sure to let you know.

Regards

Adrien
Back to Top
adrien View Drop Down
Senior Member
Senior Member


Joined: 30 April 2007
Location: New Zealand
Status: Offline
Points: 449
Post Options Post Options   Thanks (1) Thanks(1)   Quote adrien Quote  Post ReplyReply Direct Link To This Post Posted: 16 July 2015 at 2:48pm
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 
Back to Top
olebed View Drop Down
Admin Group
Admin Group


Joined: 01 July 2014
Location: Ukraine
Status: Offline
Points: 841
Post Options Post Options   Thanks (0) Thanks(0)   Quote olebed Quote  Post ReplyReply Direct Link To This Post Posted: 16 July 2015 at 4:52pm
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.
Back to Top
adrien View Drop Down
Senior Member
Senior Member


Joined: 30 April 2007
Location: New Zealand
Status: Offline
Points: 449
Post Options Post Options   Thanks (0) Thanks(0)   Quote adrien Quote  Post ReplyReply Direct Link To This Post Posted: 16 July 2015 at 6:40pm
HI

for insert we use ReportControl methods

BeginUpdate();
AddRecordEx(pRecord);
EndUpdate();
AdjustScrollBars();

for delete we do

BeginUpdate();
RemoveRecordEx(pRecord, TRUE);
EndUpdate();
AdjustScrollBars();

Adrien

Back to Top
adrien View Drop Down
Senior Member
Senior Member


Joined: 30 April 2007
Location: New Zealand
Status: Offline
Points: 449
Post Options Post Options   Thanks (0) Thanks(0)   Quote adrien Quote  Post ReplyReply Direct Link To This Post Posted: 16 July 2015 at 6:42pm
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
Back to Top
adrien View Drop Down
Senior Member
Senior Member


Joined: 30 April 2007
Location: New Zealand
Status: Offline
Points: 449
Post Options Post Options   Thanks (0) Thanks(0)   Quote adrien Quote  Post ReplyReply Direct Link To This Post Posted: 16 July 2015 at 6:45pm
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
Back to Top
adrien View Drop Down
Senior Member
Senior Member


Joined: 30 April 2007
Location: New Zealand
Status: Offline
Points: 449
Post Options Post Options   Thanks (0) Thanks(0)   Quote adrien Quote  Post ReplyReply Direct Link To This Post Posted: 16 July 2015 at 6:47pm
actually ignore that comment about key up.
Back to Top
adrien View Drop Down
Senior Member
Senior Member


Joined: 30 April 2007
Location: New Zealand
Status: Offline
Points: 449
Post Options Post Options   Thanks (0) Thanks(0)   Quote adrien Quote  Post ReplyReply Direct Link To This Post Posted: 21 January 2016 at 9:12pm
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.
Back to Top
Algae View Drop Down
Senior Member
Senior Member
Avatar

Joined: 08 January 2007
Location: United States
Status: Offline
Points: 217
Post Options Post Options   Thanks (0) Thanks(0)   Quote Algae Quote  Post ReplyReply Direct Link To This Post Posted: 21 January 2016 at 9:49pm
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.
Back to Top
adrien View Drop Down
Senior Member
Senior Member


Joined: 30 April 2007
Location: New Zealand
Status: Offline
Points: 449
Post Options Post Options   Thanks (0) Thanks(0)   Quote adrien Quote  Post ReplyReply Direct Link To This Post Posted: 24 January 2016 at 3:19pm
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.

Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 12.04
Copyright ©2001-2021 Web Wiz Ltd.

This page was generated in 0.141 seconds.