# vb.net touch screen app help



## shuggans (May 5, 2016)

So I have an app using the same method as the sample below to create scrollable controls on a windows form.  This is a commonly found solution/method on how to create smart-phone like scrolling on a vb.net winform which uses a flowlayoutpanel with the autoscroll property set to true with some handlers to handle the touching of individual controls on the flowlayoutpanel, however, if you touch the actual flowlayoutpanel itself (say there is an area which does not have a control on it), the native scrolling takes over and works, and then prevents the handlers of the child objects until the application is restarted. 

You should be able to paste the following into a new project and run it and see... touching the buttons and sliding your finger up/down works, however, if you scroll to the area at the bottom where buttons are not populated (on purpose for this error demo), you will see that you can scroll still, until you try to scroll the buttons again, which you must double tap and hold in order to scroll after that.


```
Public Class Form1
    Dim FlowPanel As New FlowLayoutPanel
    Public MouseDepressed As Boolean = False
    Private Function GenerateButton(ByVal pName As String) As Button
        Dim mResult As New Button
        With mResult
            .Name = pName
            .Text = pName
            .Width = 128
            .Height = 128
            .Margin = New Padding(3, 3, 3, 3)
            .Padding = New Padding(0)
            .BackColor = Color.CornflowerBlue
            AddHandler .MouseDown, AddressOf Button_MouseDown
            AddHandler .MouseMove, AddressOf Button_MouseMove
        End With
        Return mResult
    End Function



    Private Sub Form1_Load(ByVal sender As Object, ByVal e As EventArgs) Handles MyBase.Load
        Me.Width = 806
        Me.Height = 480
        FlowPanel.Padding = New Padding(0)
        FlowPanel.Margin = New Padding(0)

        FlowPanel.Dock = DockStyle.Fill
        FlowPanel.AutoScroll = True
        Me.Controls.Add(FlowPanel)
        FlowPanel.AutoSize = False
        Dim i As Integer
        For i = 1 To 98
            FlowPanel.Controls.Add(GenerateButton("btn" & i.ToString))
        Next
        AddHandler FlowPanel.MouseDown, AddressOf Button_MouseDown
    End Sub

    Dim myMouseDownPoint As Point
    Dim myCurrAutoSMouseDown As Point
    Public Declare Auto Function SetCursorPos Lib "User32.dll" (ByVal X As Integer, ByVal Y As Integer) As Long
    Public Declare Auto Function GetCursorPos Lib "User32.dll" (ByRef lpPoint As Point) As Long
    Public Declare Sub mouse_event Lib "user32" Alias "mouse_event" (ByVal dwFlags As Long, ByVal dx As Long, ByVal dy As Long, ByVal cButtons As Long, ByVal dwExtraInfo As Long)
    Public Const MOUSEEVENTF_LEFTUP = &H4 '
    Private Sub Panel_MouseDown(ByVal sender As Object, ByVal e As MouseEventArgs)
        mouse_event(MOUSEEVENTF_LEFTUP, 0, 0, 0, 0)
    End Sub

    Private Sub Button_MouseDown(ByVal sender As Object, ByVal e As MouseEventArgs)
        myMouseDownPoint = PointToClient(Cursor.Position)
        myCurrAutoSMouseDown = FlowPanel.AutoScrollPosition
        MouseDepressed = True
    End Sub

    Private Sub Button_MouseMove(ByVal sender As Object, ByVal e As MouseEventArgs)
        If e.Button = Windows.Forms.MouseButtons.Left Then
            If MouseDepressed = True Then
         
                Dim mLocation As Point = PointToClient(Cursor.Position)
                If myMouseDownPoint <> mLocation Then
                    Dim mCurrAutoS As Point
                    Dim mDeslocation As Point = myMouseDownPoint - mLocation
                    mCurrAutoS.X = Math.Abs(myCurrAutoSMouseDown.X) + mDeslocation.X
                    mCurrAutoS.Y = Math.Abs(myCurrAutoSMouseDown.Y) + mDeslocation.Y

                    FlowPanel.AutoScrollPosition = mCurrAutoS
                End If
            End If
        End If
    End Sub
End Class
```

I am wondering if anyone can figure this out?  I seem to be quite stumped with this one.


----------



## FordGT90Concept (May 5, 2016)

I'd highly recommend porting/switching to WPF.  If you stick to using names, it isn't too different from WinForms.

Edit: I don't have a touch device to test this code on, unfortunately.

Edit: Tried duplicating behavior with mouse and it doesn't do it.


----------



## shuggans (May 6, 2016)

It is strange - the mouse does not do it.  In fact, adding handlers for the same events with the parent flowcontrolpanel to the same subroutines used on the buttons causes the mouse to act as desired on both tiles and the parent object.  It is only when actual touch comes in to play that everything works as expected, until the parent control is touched, after which you must double tap and hold the second tap on the buttons to resume touch scrolling... which doesn't work when you have an on mouseup event handler on the buttons.

I would be okay with trying out a WPF port of this, except I've never created a WPF app before, and this issue with touch is the last I need to finish development of my production app - do you think this issue would not exist in a WPF world? 

Thanks for the response Ford, your help is always appreciated!


----------



## FordGT90Concept (May 6, 2016)

WPF is DirectX-based so it completely circumvents the GDI+ that WinForm uses.  You will likely run into other issues with WPF but WPF at least natively supports touch devices:
https://msdn.microsoft.com/en-us/library/ee649090(v=vs.100).aspx


----------



## shuggans (May 6, 2016)

I almost wonder if I am looking at this wrong.  Is there any way to just completely disable native interaction with the flowcontrolpanel the buttons are on?  That would get rid of the cause of the issue as well, and still complete the required functionality.


----------



## FordGT90Concept (May 6, 2016)

You could try Enabled = false but that will disable all child elements too.  Alternatively, you could catch the event you want to ignore then just throw e.Handled = true so it ignores it.


----------



## shuggans (May 6, 2016)

Can you link an example of how I would go about that?  adding a handler for mouseevent args results in e.handled is not a member of mouseventargs, or even just plain eventargs.


----------



## shuggans (May 6, 2016)

It is interesting... adding handlers for mouse events to the flowcontrol panel and using the mouse to click and drag etc. has expected results... however, much different results when using touch... I wonder if it is raising different events...


----------



## FordGT90Concept (May 6, 2016)

WinForms has zero support for touch input.  You're having to jury rig the finger to the mouse which is likely why you're seeing unexpected behavior.  I'd at least take a look at WPF and see how much work it would be to change.  It can not only support touch, but also the two-finger gestures for resizing the UI and such:
https://msdn.microsoft.com/en-us/library/ee649090(v=vs.100).aspx

Edit: WPF supports VB code-behind.


----------



## shuggans (May 6, 2016)

I think I will try to figure out how to "block" or ignore touch input on the flowcontrolpanel the buttons are on... this is actually exactly what I need to do.


----------



## shuggans (May 6, 2016)

Ford, would you be able to help me convert this from C# into vb.net?  I've been trying and can't seem to get it right - it is a touch gestures sample from the MS windows 7 SDK.  If I can get this into vb.net I'm pretty sure I can use it to filter out or override the touch events on the parent flowcontrolpanel.
http://visuafusion.com/_Priv/MTGesturesCS.zip


----------



## FordGT90Concept (May 6, 2016)

You may be able to just compile it as a DLL and call what you need from it in your VB project.

There is quite a bit of code.  I could help convert parts of it that you can't figure out how to convert.


----------



## silentbogo (May 6, 2016)

shuggans said:


> think I will try to figure out how to "block" or ignore touch input on the flowcontrolpanel the buttons are on... this is actually exactly what I need to do.


You already have a handler set up for buttons, so what I think you should try is to remove this almost last line from Form1_Load:

```
AddHandler FlowPanel.MouseDown, AddressOf Button_MouseDown
```

This way if you click on the panel outside of any button - nothing happens.

Other than that, I agree with most people here - use WPF for layout (it has built-in scrolling containers), and read up on .NET 4.0 multitouch capabilities. I haven't done anything with touch, but I'm pretty sure it will be easier than using external Win32 libraries and emulating touch behavior with mouse.


----------



## shuggans (May 6, 2016)

Even without that, windows is natively handling the panel touch scrolling.  Clicking does nothing, but if you touch the panel behind the buttons and drag, it does scroll.  I either need to block that from happening, or pass that through onto the buttons and get rid of my handled code.  The app is a sample application... the actual one is much more complicated and developed way further along... this is actually the last part that I need to figure out before general/testing/production... so I am reluctant to completely scrap the project and start again if I can find a way to make this work.  The MS samples show that touch handling can be done with win forms...


----------



## silentbogo (May 6, 2016)

http://www.codeproject.com/Articles/37349/Creating-A-Scrollable-Control-Surface-In-WPF.aspx

Just spent 2 minutes in Visual studio and made a window with scrollable list. You should try it.

EDIT:
Another thing - why are you using imported winAPI functions to poll mouse state, if you can do the same thing with System.Windows.Input.Mouse?


----------



## shuggans (May 6, 2016)

I was messing with trying to handle native mouse input to block it before I realized that the input causing this isn't mouse simulation at all (and hence the problem).


----------



## FordGT90Concept (May 6, 2016)

I think you're either better off leaving it the way it is or, if it is that important to fix, switch to WPF.  By the time you work all of the kinks out of WinForms, you could have had it working in WPF.  WPF has a lot more advantages than just native touch support.


----------

