Changed behavior in report item with checkbox!

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   I just upgraded from XTP 11.1.3 to 11.2.1 and have noticed a change in behavior with report control items that have a checkbox (m_bHasCheckbox = TRUE). 

In the previous version you had to click in the checkbox to change it (as expected), now clicking anywhere in the cell causes it to change!  This is especially problematic when you also have text in the cell, since double clicking the cell to edit the text also causes the checkbox to change state! 

I don't know if this is a bug, but I would like to get back to the previous behavior, can you tell me how to do this?

Thanks.

PS. I just had a look at the code and the problem appears to be in CXTPReportRecordItem::DrawCheckBox() method which no longer adjusts the m_rcGlyph member based on the icon position, and instead uses a copy of this rect!

There also appears to be another bug here, you use two switch statements to determine the horizontal and vertical icon alignment, but if both a horizontal and vertical alignment are set this will fail since the code does not mask for each of these styles before the switch statements.

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
brianh Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 30 April 2004 Location: United Kingdom Status: Offline Points: 83	Post Options Post Reply Quote brianh Report Post Thanks(0) Quote Reply Topic: Changed behavior in report item with checkbox! Posted: 13 December 2007 at 5:13am
	I just upgraded from XTP 11.1.3 to 11.2.1 and have noticed a change in behavior with report control items that have a checkbox (m_bHasCheckbox = TRUE). In the previous version you had to click in the checkbox to change it (as expected), now clicking anywhere in the cell causes it to change! This is especially problematic when you also have text in the cell, since double clicking the cell to edit the text also causes the checkbox to change state! I don't know if this is a bug, but I would like to get back to the previous behavior, can you tell me how to do this? Thanks. PS. I just had a look at the code and the problem appears to be in CXTPReportRecordItem::DrawCheckBox() method which no longer adjusts the m_rcGlyph member based on the icon position, and instead uses a copy of this rect! There also appears to be another bug here, you use two switch statements to determine the horizontal and vertical icon alignment, but if both a horizontal and vertical alignment are set this will fail since the code does not mask for each of these styles before the switch statements.

brianh Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 30 April 2004 Location: United Kingdom Status: Offline Points: 83	Post Options Post Reply Quote brianh Report Post Thanks(0) Quote Reply Posted: 13 December 2007 at 7:19am
	I fixed this problem in CXTPReportRecordItem::DrawCheckBox() by changing the line: CRect rcGlyph(m_rcGlyph); to CRect & rcGlyph(m_rcGlyph); // NB: a reference I also added two more mask values: enum { xtpColumnIconVMask = 0x0F000000, // A mask for vertical icon alignment styles. xtpColumnIconHMask = 0x00F00000, // A mask for horizontal icon alignment styles. //xtpColumnIconMask = xtpColumnIconVMask \| xtpColumnIconHMask, // A mask for icon alignment styles. } ; and changed the switch statements to AND (&) the nIconAlign value with the appropriate mask. I would like to know that these fixes will be in the next release so that my code doesn't break when I next upgrade (obviously you can code it your own way, I just need to know it will be fixed)? Thanks.

brianh Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 30 April 2004 Location: United Kingdom Status: Offline Points: 83	Post Options Post Reply Quote brianh Report Post Thanks(0) Quote Reply Posted: 14 December 2007 at 10:58am
	Can someone from CodeJock please confirm that these fixes will be in the next release? Thanks.

markr Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 01 August 2004 Status: Offline Points: 442	Post Options Post Reply Quote markr Report Post Thanks(0) Quote Reply Posted: 07 September 2009 at 11:58am
	I'm now experiencing this problem as well, and would like to see it resolved for the upcoming v13.2 release (if possible). The easiest way to reproduce the problem is to modify one of the report sample projects. Just add a checkbox - HasCheckbox(TRUE) - to an EXISTING CXTPReportRecordItem that contains text (don't add the checkbox to a new column, add it to an existing textual column). Then intercept XTP_NM_REPORT_CHECKED as you normally would. What you'll find is that clicking anywhere within the column (on the text or the checkbox) causes XTP_NM_REPORT_CHECKED to fire, which is clearly not desirable. This message should be sent only when the checkbox itself is clicked. I agree with the assessment of the originator of this topic - the problem lies in m_rcGlyph, the bounds of which are not properly adjusted in this scenario.

mdoubson Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 17 November 2008 Status: Offline Points: 1705	Post Options Post Reply Quote mdoubson Report Post Thanks(0) Quote Reply Posted: 08 September 2009 at 5:46pm
	Hey, guys, of course I did not know the problem dated 14 December 2007 You should at least refresh the post to attract attention but better to open Issue. I consider the way to click on item rectangle (not only on glyph) is simplification for clients. I changed it to glyph rectangle now. You can apply this update yourself - add last line in function void CXTPReportRecordItem::DrawCheckBox(XTP_REPORTRECORDITEM_DRAWARGS* pDrawArgs, CRect& rcItem) { ................................................................................... m_rcGlyph = rcGlyph; //to restrict click on Glyph area only }

brianh Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 30 April 2004 Location: United Kingdom Status: Offline Points: 83	Post Options Post Reply Quote brianh Report Post Thanks(0) Quote Reply Posted: 09 September 2009 at 5:08am
	Hi Mark, I just moved to version 13.1 myself and this bug has re-appeared as I had feared, so it's good to get an offical fix for it at last. You said "I consider the way to click on item rectangle (not only on glyph) is simplification for clients", but as I pointed out in my original post this just doesn't work if you have text AND a checkbox in the same cell, clicking on the text to edit it causes the checkbox to change state which is clearly wrong. So thanks for the fix, I've applied it and all is well again, although it looks like the other bug in this method that I reported in my original post is still present, i.e. if you have BOTH a horizontal and vertical alignment set it won't work correctly becuse no masking is done on the nIconAlign value (to extract the horizontal and vertical styles) before each switch statement.

mdoubson Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 17 November 2008 Status: Offline Points: 1705	Post Options Post Reply Quote mdoubson Report Post Thanks(0) Quote Reply Posted: 09 September 2009 at 7:46am
	Well - I tested fix on ReportSample - it react proprely. only on click inside glyph. I also extend it to cover combination of alignment flags

brianh Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 30 April 2004 Location: United Kingdom Status: Offline Points: 83	Post Options Post Reply Quote brianh Report Post Thanks(0) Quote Reply Posted: 09 September 2009 at 12:04pm
	Hi Mark, Yes, the 'click' problem was fixed with your first post, it was only the icon alignment that still needed fixing. I made the changes you have shown for the icon alignment, but it still didn't work correctly. After a bit of debugging I found the problem to be that the mask values in the code shown in your post (0x0F00000 and 0x00F0000) are only 7 digits long, they need an extra 0 on the end so they become 0x0F000000 and 0x00F00000. With those changes in place everything now works as expected. Thanks.

mdoubson Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 17 November 2008 Status: Offline Points: 1705	Post Options Post Reply Quote mdoubson Report Post Thanks(0) Quote Reply Posted: 09 September 2009 at 12:10pm
	Thanks for testing (copy - paste bug) and I don't have proper test case to check. This is fresh code and ocx https://forum.codejock.com/uploads/DemoVersion/ReportControlMFCUpdated.rar https://forum.codejock.com/uploads/BetaOCX/ReportControlBeta13-2.rar