Can we have MouseEnter and MouseLeave Events on all Controls?.

[dmrvb]

Is your feature request related to a problem? Please describe.

Could we have MouseEnter and MouseLeave events in all controls please? Also mouse events such as mousemove/mousedown etc in the combo box because in VB6 it has no mouse events.

Describe alternatives you've considered Currently have all sorts of flags trying to keep track of where the mouse is etc, and still can't reliable do what I want to do. I have to use mousemove in all controls to deduce when it has left another control and even then rapid mousemoves can go undetected. Mouseleave makes things so much easiere. Doing clever things with a combo box is really difficult as "dropdown" is the only mouse-related even event available.

[fafalone]

MouseHover, too. It would indeed be nice to not need to resort to subclassing for these... make tB friendlier for newcomers.

[sokinkeso]

MouseWheel also...😉

[DinyaZ]

Yes, a dedicated mousewheel event should be also very-very nice, instead of this working, but not too easy way to scroll with the wheel on a Datagrid:

Public Declare Function SetWindowLong Lib "user32" Alias "SetWindowLongA" (ByVal hWnd As Long, ByVal nIndex As Long, ByVal dwNewLong As Long) As Long Public Declare Function CallWindowProc Lib "user32" Alias "CallWindowProcA" (ByVal lpPrevWndFunc As Long, ByVal hWnd As Long, ByVal Msg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long Public Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As Long) Public Const GWL_WNDPROC = (-4) Public lpPrevWndProc As Long

Const WM_MOUSEWHEEL = &H20A Const WHEEL_DELTA = 120

Public ScrCount As Integer Public ScrElozo As Integer

Function WndProc(ByVal hWnd As Long, ByVal Msg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long On Error GoTo BSS_ErrorHandler Dim Delta As Long Static Ut As Long If Msg = WM_MOUSEWHEEL Then Delta = HiWord(wParam) Ut = Ut + Delta MouseWheel Ut \ WHEEL_DELTA, LoWord(lParam), HiWord(lParam) Travel = Ut Mod WHEEL_DELTA End If WndProc = CallWindowProc(lpPrevWndProc, hWnd, Msg, wParam, lParam) Exit Function BSS_ErrorHandler: If Err.number > 0 Then ProjErrHandler "Module2: WndProc" End Function

Sub MouseWheel(Ut As Integer, X As Long, Y As Long) On Error GoTo BSS_ErrorHandler ScrCount = ScrCount + Ut With adatbazis If ScrCount < ScrElozo Then If .Data1(0).Recordset.AbsolutePosition < .Data1(0).Recordset.RecordCount - 1 Then .Data1(0).Recordset.MoveNext Else If .Data1(0).Recordset.AbsolutePosition > 0 Then .Data1(0).Recordset.MovePrevious End If .Command1.SetFocus End With ScrElozo = ScrCount Exit Sub BSS_ErrorHandler: ' If Err.Number > 0 Then ProjErrHandler "Module2: Mouse" End Sub

Function HiWord(DWord As Long) As Integer On Error GoTo BSS_ErrorHandler CopyMemory HiWord, ByVal VarPtr(DWord) + 2, 2 Exit Function BSS_ErrorHandler: If Err.number > 0 Then ProjErrHandler "Module2: HiWord" End Function

Function LoWord(DWord As Long) As Integer On Error GoTo BSS_ErrorHandler CopyMemory LoWord, DWord, 2 Exit Function BSS_ErrorHandler: If Err.number > 0 Then ProjErrHandler "Module2: LoWord" End Function

[sokinkeso]

Yes, a dedicated mousewheel event should be also very-very nice, instead of this working, but not too easy way to scroll with the wheel on a Datagrid:

Public Declare Function SetWindowLong Lib "user32" Alias "SetWindowLongA" (ByVal hWnd As Long, ByVal nIndex As Long, ByVal dwNewLong As Long) As Long Public Declare Function CallWindowProc Lib "user32" Alias "CallWindowProcA" (ByVal lpPrevWndFunc As Long, ByVal hWnd As Long, ByVal Msg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long Public Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As Long) Public Const GWL_WNDPROC = (-4) Public lpPrevWndProc As Long

Const WM_MOUSEWHEEL = &H20A Const WHEEL_DELTA = 120

Public ScrCount As Integer Public ScrElozo As Integer

Function WndProc(ByVal hWnd As Long, ByVal Msg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long On Error GoTo BSS_ErrorHandler Dim Delta As Long Static Ut As Long If Msg = WM_MOUSEWHEEL Then Delta = HiWord(wParam) Ut = Ut + Delta MouseWheel Ut \ WHEEL_DELTA, LoWord(lParam), HiWord(lParam) Travel = Ut Mod WHEEL_DELTA End If WndProc = CallWindowProc(lpPrevWndProc, hWnd, Msg, wParam, lParam) Exit Function BSS_ErrorHandler: If Err.number > 0 Then ProjErrHandler "Module2: WndProc" End Function

Sub MouseWheel(Ut As Integer, X As Long, Y As Long) On Error GoTo BSS_ErrorHandler ScrCount = ScrCount + Ut With adatbazis If ScrCount < ScrElozo Then If .Data1(0).Recordset.AbsolutePosition < .Data1(0).Recordset.RecordCount - 1 Then .Data1(0).Recordset.MoveNext Else If .Data1(0).Recordset.AbsolutePosition > 0 Then .Data1(0).Recordset.MovePrevious End If .Command1.SetFocus End With ScrElozo = ScrCount Exit Sub BSS_ErrorHandler: ' If Err.Number > 0 Then ProjErrHandler "Module2: Mouse" End Sub

Function HiWord(DWord As Long) As Integer On Error GoTo BSS_ErrorHandler CopyMemory HiWord, ByVal VarPtr(DWord) + 2, 2 Exit Function BSS_ErrorHandler: If Err.number > 0 Then ProjErrHandler "Module2: HiWord" End Function

Function LoWord(DWord As Long) As Integer On Error GoTo BSS_ErrorHandler CopyMemory LoWord, DWord, 2 Exit Function BSS_ErrorHandler: If Err.number > 0 Then ProjErrHandler "Module2: LoWord" End Function

Yes..I agree 100%...subclassing was the only way to do this...I hope with tB we will no longer need to do something like this for mouse events..🙂

[wqweto]

How about subclassing (and multi-threading) being supported runtime feature, not bombing the IDE like in VBx.

Additional mouse events would be nice to have but making available all the subclassing goodness is what power users would need to get their job done.

[sokinkeso]

How about subclassing (and multi-threading) being supported runtime feature, not bombing the IDE like in VBx.

Additional mouse events would be nice to have but making available all the subclassing goodness is what power users would need to get their job done.

This idea is even better and I hope it will be part of tB to be able to subclass easier than VBx, with full oop implementation/capabilities.

[dmrvb]

Good safe subclassing with a "VB ethos" rather than "power user API calls" would be great, probably my top suggestion for new tB features. (though I appreciate that messing with windows messages always has some risk). But, even with subclassing I think MouseEnter and Mouseleave should be included as message handling will always be a bit of an hurdle for non experts. I am surprised that Microsoft never included these events in VB.

[WaynePhillipsEA]

We already track the mouse enter/leave internally for the tooltips support, so exposing them should be easy.

Allowing to handle window messages of a control without further subclassing would be great, but requires a bit more thought on the implementation to ensure we don't hinder the performance by raising those events unnecessarily for the 99% of cases where we don't need to handle them manually. Perhaps a filtered registration would work... e.g. Text1.RegisterWndProcBefore(WM_BLAH, AddressOf HandleBlah), which would pass all WM_BLAH messages to your desired callback before the normal handler (and of course the complimentary RegisterWndProcAfter).

Or, just Text1.RegisterWndProcBefore(WM_BLAH) and then that raises event Text1_CustomWndProcBefore(WM_BLAH, ...). Something along those lines.

[rexxitall]

By all love to be compatible. If we have subclassing that will keep old code intact. But silly standard things of the 21th century like mouse wheels, joystick events and a lot of other "modern" things should work out of the box.The target is to be 100% compatible. It does not mean nessecary to be 100% compatible by the things the left out , has forgotten, has missed or was to lazy too :) The good thing on vbx is and was that it is easy for beginners. Some tricky things can always be added. I have disabled mouse wheel support currently. I am not a master of subclassing and if you restart the program a lot of times in the IDE and it crashes, then you decide that its etter to have two buttons which work then keep subclassing during developement time. So a build in support would help me a lot :) It is a bit stonehenge to zoon in and out by buttons and not with the mouse wheel :D

[fafalone]

The AddressOf on class members feature already makes subclassing easy in the only place it was particularly difficult... all you need to do is call SetWindowSubclass now for everything. How much more could it be simplified without losing features that would make power users go right back to APIs?

But this would be a separate issue as the idea behind simple control events like MouseEnter/MouseLeave/MouseHover is making those commonly used events easy for people who aren't power users comfortable with WndProc, uMsg, wParam, lParam, etc.

[dmrvb]

Im still not an expert on low level stuff, I want to use VB as an easy high level language...but its limitations have forced me to learn API, GDI and subclassing etc. Could we have something like a "message" event controlled by a MessagePreview property, a bit equivalent to KeyPreview???. Whatever you can do is going to better than what VB does.

[rexxitall]

Those additional features could get a different back color in the editor or grayed out in strict mode. So the user knows that he will now leave the historic path if he uses this features.

[dmrvb]

I like your terminology, perhaps when certain feature are selected we could have a big messagebox, "Caution. You are straying from the Historic Path and enterring the dangerous world of Modern Programming".

More Seriously, do we need an (optional) explicit warning, a bit like the current "yellow squiggle" to indicate code that breaks compatibility with VB?

[sokinkeso]

So the user knows that he wil

I think not...There will be documentation later.. Everybody who knows to develop apps in VBx will continue in tB the way they knew...and if they read the documentation they will make a step ahead using the new features of tB... But mainly, because there will be no "break in compatibility"..VBx code will run as is. You just have to read the new capabilities of tB to become more productive.

[WaynePhillipsEA]

More Seriously, do we need an (optional) explicit warning, a bit like the current "yellow squiggle" to indicate code that breaks compatibility with VB?

I don't think it's needed. We'll eventually be getting a 'Legacy mode' option, which, when enabled, will prevent you from using any of the new features.

[Kr00l]

A per control MouseTrack property (Boolean) should be available, so that "tracking" and firing of those events happen only if it is set to True.

[KarlSevenSeven]

I can't imagine so many people will code in tB and then compile in VB. IMO 100% compatibility in one direction is enough.