[BUG] HitTest differs between 13.4.2 &13.2.1 |
Post Reply |
Author | |
choochy
Groupie Joined: 27 October 2006 Status: Offline Points: 18 |
Post Options
Thanks(0)
Posted: 19 January 2011 at 10:05pm |
Unless I am totally wrong about it being a bug, and missed that this was a usage change, the following is a major problem for me.
In the MouseUp Event I run a HitTest to get the Area of the Report Control. This is used to determine which Context Menu is appropriate to display. This has been working fine for me ever since I upgraded to 13.4.2 from 13.2.1. When I hover over an area that is within the Report Area, but does not have any Rows directly under the mouse pointer, the .ht now returns xtpUnknown where before (13.2.1) it returned xtpHitTestReportArea. I need the enhancements of 13.4.2 for my product but now major parts of the product are not working properly! What do I do?!!! I am ment to release in 1 week. |
|
Product: Xtreme SuitePro (ActiveX) version 13.4.2
Platform: Windows 7 (32bit) Language: Visual Basic 6.0 & Delphi XE |
|
jpbro
Senior Member Joined: 12 January 2007 Status: Offline Points: 1355 |
Post Options
Thanks(0)
|
I hate it when existing functionality is broken as well....
You should open a support ticket at https://support.codejock.com and hopefully get this fixed, but here's a pain-in-the-butt example workaround:
You could search for all of your HitTest method calls, then add a call to TranslateHitTestInfoCode after it and use the return value with your current code without further modification. Hopefully you don't have too many HitTest calls to modify! |
|
Product: Xtreme SuitePro (ActiveX) version 16.2.6
Platform: Windows XP - SP3 Language: Visual Basic 6.0 SP6 |
|
Xander75
Senior Member Joined: 26 April 2007 Status: Offline Points: 353 |
Post Options
Thanks(0)
|
Hi,
Can I ask what type of popups you are trying to display and over which areas when clicked? I also use 13.4.2 and don't find this as a problem for me. |
|
Product: Xtreme SuitePro (ActiveX) v15.3.1
Platform: Windows 7 64-bit (SP1) Professional Edition Languages: C#.Net using Visual Studio 2012 & Visual Basic 6.0 (SP6) |
|
Aaron
Senior Member Joined: 29 January 2008 Status: Offline Points: 2192 |
Post Options
Thanks(0)
|
Hi Alexander,
In previous versions HitTest returned xtpHitTestReportArea where ever you clicked as long it wasn't column, groupbox, row etc etc... For some reason 'someone' (and we all know who did this, don't we Jason? ) changed this implementation into returning xtpHitTestUnknown
If you look in the Help, there's a sample with some comments:
[...]
'This case will never happen, Unknown is returned when HitTest is called and the mouse is positioned
'over an area outside of the report control Case xtpHitTestUnknown: Debug.Print "Mouse is in an Unknown Area" So if some ever used this like @choochy
You are in trouble
As I said before, once implemented and released (final not Beta), you can't change it anymore. You get stuck with it the rest of your life. But some developers don't seem to care...
|
|
Product: Xtreme SuitePro (ActiveX) version 15.0.2
Platform: Windows XP (32bit) - SP 2 Language: Visual Basic 6.0 Zero replies is not an option.... |
|
choochy
Groupie Joined: 27 October 2006 Status: Offline Points: 18 |
Post Options
Thanks(0)
|
I had opened a support ticket about the issue and got the following response:
"Actually this was a fix. If you worked with drag and drop you would see the importance. Internally that area is referenced to as unknown and it was a bug in the code that reported it as report area." While I dont understand how it was labeled a bug, seeming it previously worked exactly as stated in the documentation. I do welcome this change, but not in the way it was implemented. Like you said once its released it sticks for life. What they should have done was implemented a new enum value for this. The least they could have done was update the documentation, cause this was the first place I went. And if documented differently, I wouldn't have had an issue. But then that begs my next question, as to whether the ReportControl Tag property is inccorently coded as a string, instead of as the documentation states "the same as any other Tag property". Thanks guys!
|
|
Product: Xtreme SuitePro (ActiveX) version 13.4.2
Platform: Windows 7 (32bit) Language: Visual Basic 6.0 & Delphi XE |
|
jpbro
Senior Member Joined: 12 January 2007 Status: Offline Points: 1355 |
Post Options
Thanks(0)
|
Hmm...first, my apologies, because I think that I had some hand in the method return value modification. Some time ago, I did a lot of work with the ReportControl & DragDrop operations, and I ran into some issues that needed CJ support. It was a tough time (as Aaron can attest to), and the end result of that particular exchange may have broken the return value behaviour.
However, you are absolutely right - at a minimum, a new enum should have been created instead of using an enum that was documented as "impossible" (except I presume unless the mouse had been captured via API and the pointer was outside of the ReportControl window). In any case, this is a textbook example of why you don't break rules after a production release - your code is now broken, and if the behaviour is reverted, then other's code may be broken now. This is not a good situation. I hope that Oleg or SuperMario can respond to this so we can figure out the best remedy. |
|
Product: Xtreme SuitePro (ActiveX) version 16.2.6
Platform: Windows XP - SP3 Language: Visual Basic 6.0 SP6 |
|
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 |