RibbonButton and Touch input

Hi Mark,

You are correct, WPF seems to be telling the button it has mouse over when it is tapped.  But it never tells the button on tap release that the mouse is no longer over it.  Then if you tap another control, WPF finally tells the original button that it no longer has mouse over and it updates its state. 

I am seeing the same thing with a regular WPF ToolBar too (such as in our SDI Editor sample), even without our native themes active.  We did some searching on the web and found a couple instances of this being reported in general.  But there don't appear to be any good solutions.  Unfortunately I'm not sure there's anything we can really do on our end about this, since it's happening with the native controls as well.  Perhaps if something could be simulated to cause the IsMouseOver state to change, that would work around the problem?

Hi,

thanks for the quick reply.

So what would be a good way to disable the IsMouseOver state? Can I disable the highlighting of the ribbon button even if the mouse is over it?

What about the RegisterTouchWindow() method, might that work to avoid mouse pointer positioning when using touch?

On Windows 8 there is also the WM_POINTERDOWN windows message which, if handled, will not move the emulate the mouse. That could work if it was handled appropriately by Actipro.

Regards

Mark

Hi Mark,

The only way to prevent mouse over highlights would be to alter all our control default templates and remove related triggers, which is certainly not a trivial task.  Unfortunately that's not something we'd want to do on our defaults since it would affect all the mouse users.

All our controls are native WPF and don't watch Window API messages (which only go to the root Window in WPF anyhow).  We do watch some API messages on RibbonWindow, just to achieve the custom theming.  I would think that handling WM_POINTERDOWN would possibly block valid input, woudln't it?  I'm not sure what RegisterTouchWindow() does.  Is that an API too?

Well, in that case are you declaring Actipro Ribbon controls as not being touch compatible?

This will become a show-stopper for us in the future and we certainly aren't interested in replacing Actipro controls, but this might force us to do so.

Yes, RegisterTouchWindow (and RegisterPointerInputTarget) are APIs from Microsoft.

Hi Mark,

The Ribbon controls are touch compatible, and act the same way as native WPF controls in regards to touch, since they are designed in the same fashion.  For instance, I put together this test to run on my Surface:

<Window x:Class="WPFTouchHoverIssue.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Touch Test" Height="600" Width="800" FontSize="30">
    <DockPanel>
		<Menu DockPanel.Dock="Top">
			<MenuItem Header="File" Padding="40,20">
				<MenuItem Header="New" Padding="40,20" />
				<MenuItem Header="Open" Padding="40,20" />
			</MenuItem>
			<MenuItem Header="Edit" Padding="40,20">
				<MenuItem Header="Cut" Padding="40,20" />
				<MenuItem Header="Copy" Padding="40,20" />
				<MenuItem Header="Paste" Padding="40,20" />
			</MenuItem>
		</Menu>
		
        <ToolBar DockPanel.Dock="Top">
			<Button Content="Regular" Padding="40,20" />
			<ToggleButton Content="Toggle" Padding="40,20" />
		</ToolBar>
		
		<StackPanel DockPanel.Dock="Top" Orientation="Horizontal">
			<Button Content="Regular" Padding="40,20" />
			<ToggleButton Content="Toggle" Padding="40,20" />
		</StackPanel>
		
		<StatusBar DockPanel.Dock="Bottom" FocusManager.IsFocusScope="True">
			<Button Content="Regular" Padding="40,20" />
			<ToggleButton Content="Toggle" Padding="40,20" />
		</StatusBar>
		
		<TextBox />
    </DockPanel>
</Window>

If you focus the TextBox and then tap on the toolbar buttons or the buttons in the statusbar (both of which are in focus scopes) you can see how the mouse leave isn't passed by WPF to them.  The same thing is the root of the problem with our Ribbon controls.  Ideally after a tap was done on a control, the WPF system would pass a mouse leave event as well since that would solve the problem everywhere.

I'm not saying what currently is happening is good or desirable.  I'm just saying that is the reason it's occurring.  We're open to suggestions on how best to handle this scenario, and any ideas we come up with could be tested on the simple native WPF control XAML above.

Hi,

I have an interim solution in place, where I position the mouse position manually on the TouchUp event. Of course, this is not a nice design but it does work in my scenario.

What if you guys would treat the TouchUp event as a "MouseLeave" event? (Or PointerUp on Win8). TouchDown/TouchUp events are not fired by a real mouse, so that would probably work.

Ideally, I'd like to be able to disable the mouse-over effect in ActiPro, which would also solve the issue.

So in essence I do think there are quite a few possibilities even if MS is not helping the case by how the touch event is converted into a mouse event and notifying you as a consumer about. (In pure WINAPI, you can check if a WM_MOUSEXXX event is actually being triggered by a real mouse or some other pointer device).

Regards

Mark

Hi Mark,

We have some ideas of things we'll try to help improve this, ideally without losing mouse over effects.  We'll post a status update once we see how they work out.

Thanks. Yes, please keep me posted.

Hi Mark,

We've been able to update the ribbon controls to better support the touch scenario.  These updates will be in the 2013.2 version.

Hi,

that's great news! When will 2013-2 be released?

Thanks

Mark

Hi Mark,

It should be in the next several weeks, as soon as we wrap up some last things.