Several bugs in grouped control

Hi all

We have informed our development team of the issue and will be looking into it.  Thank you for bringing this to our attention. 

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

Problem noted in v.16.26  up to 16.4

in XTPReportRows.cpp line 553 you have this:

Hi Algae, you wrote

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.  

Hi Oleksandr

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.

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.

actually ignore that comment about key up.

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.