Codejock Forums Homepage
Forum Home Forum Home > Codejock Products > ActiveX COM > Report Control
  New Posts New Posts RSS Feed - [BUG] HitTest differs between 13.4.2 &13.2.1
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

[BUG] HitTest differs between 13.4.2 &13.2.1

 Post Reply Post Reply
Author
Message
choochy View Drop Down
Groupie
Groupie
Avatar

Joined: 27 October 2006
Status: Offline
Points: 18
Post Options Post Options   Thanks (0) Thanks(0)   Quote choochy Quote  Post ReplyReply Direct Link To This Post Topic: [BUG] HitTest differs between 13.4.2 &13.2.1
    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
Back to Top
jpbro View Drop Down
Senior Member
Senior Member
Avatar

Joined: 12 January 2007
Status: Offline
Points: 1355
Post Options Post Options   Thanks (0) Thanks(0)   Quote jpbro Quote  Post ReplyReply Direct Link To This Post Posted: 19 January 2011 at 11:26pm
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:


Option Explicit

Private Type POINTAPI
   x As Long
   y As Long
End Type

Private Declare Function GetCursorPos Lib "user32.dll" (ByRef lpPoint As POINTAPI) As Long
Private Declare Function ScreenToClient Lib "user32.dll" (ByVal hwnd As Long, ByRef lpPoint As POINTAPI) As Long

Private Sub Form_Load()
   With Me.ReportControl1
      .Columns.Add .Columns.Count, "Test", 100, True
     
      Dim i As Long
     
      For i = 0 To 3
      With .Records.Add
         With .AddItem("A")
         End With
      End With
      Next i
     
      .Populate
   End With
End Sub

Private Sub ReportControl1_MouseDown(Button As Integer, Shift As Integer, x As Long, y As Long)
   Dim lo_Ht As ReportHitTestInfo
   Dim l_Ht As XTPReportHitTestInfoCode
  
   Set lo_Ht = Me.ReportControl1.HitTest(x, y)
   If lo_Ht Is Nothing Then
      Exit Sub
   End If
  
   l_Ht = TranslateHitTestInfoCode(lo_Ht)
   Debug.Print l_Ht = xtpHitTestReportArea
End Sub

Private Function TranslateHitTestInfoCode(po_Ht As ReportHitTestInfo) As XTPReportHitTestInfoCode
   TranslateHitTestInfoCode = po_Ht.ht

   If po_Ht.ht = xtpHitTestUnknown Then
      Dim lt_Pt As POINTAPI
     
      GetCursorPos lt_Pt
      ScreenToClient Me.ReportControl1.hwnd, lt_Pt
     
      lt_Pt.x = Me.ScaleX(lt_Pt.x, vbPixels, IIf(Me.ScaleMode = vbUser, vbPixels, Me.ScaleMode))
      lt_Pt.y = Me.ScaleX(lt_Pt.y, vbPixels, IIf(Me.ScaleMode = vbUser, vbPixels, Me.ScaleMode))
     
      Debug.Print lt_Pt.x, lt_Pt.y, Me.ReportControl1.Width, Me.ReportControl1.Height
     
      If lt_Pt.x >= 0 And lt_Pt.x <= Me.ReportControl1.Width Then
         If lt_Pt.y >= 0 And lt_Pt.y <= Me.ReportControl1.Height Then
            TranslateHitTestInfoCode = xtpHitTestReportArea
         End If
      End If
   End If
End Function



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

Back to Top
Xander75 View Drop Down
Senior Member
Senior Member
Avatar

Joined: 26 April 2007
Status: Offline
Points: 353
Post Options Post Options   Thanks (0) Thanks(0)   Quote Xander75 Quote  Post ReplyReply Direct Link To This Post Posted: 21 January 2011 at 5:15am
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)
Back to Top
Aaron View Drop Down
Senior Member
Senior Member
Avatar

Joined: 29 January 2008
Status: Offline
Points: 2192
Post Options Post Options   Thanks (0) Thanks(0)   Quote Aaron Quote  Post ReplyReply Direct Link To This Post Posted: 21 January 2011 at 5:44am
Originally posted by Xander75 Xander75 wrote:

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.
 
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? Wink ) 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 Confused 
 
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....
Back to Top
choochy View Drop Down
Groupie
Groupie
Avatar

Joined: 27 October 2006
Status: Offline
Points: 18
Post Options Post Options   Thanks (0) Thanks(0)   Quote choochy Quote  Post ReplyReply Direct Link To This Post Posted: 21 January 2011 at 9:41pm
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
Back to Top
jpbro View Drop Down
Senior Member
Senior Member
Avatar

Joined: 12 January 2007
Status: Offline
Points: 1355
Post Options Post Options   Thanks (0) Thanks(0)   Quote jpbro Quote  Post ReplyReply Direct Link To This Post Posted: 21 January 2011 at 11:55pm
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

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.125 seconds.