Sorry but we'd probably need to debug a very simple sample project that shows this to be able to assist. If you want to make one, please reference this post, email the project ZIP file to our support address, and rename the .zip file extension so it doesn't get spam blocked. Thanks!
↧
Re: How to switch other tabs when click the back button in backstage page?
↧
Re: Different icons for window titlebar and taskbar
Hi Marcel,
RibbonWindow, at least the current version, will use the icon specified in the WindowChrome's IconSource. But if that isn't set, it will fall back to using the Window.Icon, which should be what it did in older versions. It will look for a 16x16 icon in that.
↧
↧
RunTimeVersion v4.0.30319 and Version 13.1.582.0 work for .NetFrameWork 4.0 ?
Does RunTimeVersion v4.0.30319 and Version 13.1.582.0 work for .NetFrameWork 4.0 ?
↧
Re: RunTimeVersion v4.0.30319 and Version 13.1.582.0 work for .NetFrameWork 4.0 ?
Yes, all versions of our WPF controls are .NET 4.0 compatible.
↧
Click on a minimized ribbon and then click on the window X button to close the window
Click on a minimized ribbon and then click on the window X button to close the window doesn't close the window.
Need to click X one more time to close it.
This seems to be different with Windows Word ribbon behavior, if I click X there, it closes the document right away.
Is there a setting/property in the Actipro ribbon which addresses this behavior?
↧
↧
Re: Click on a minimized ribbon and then click on the window X button to close the window
Hi Francis,
This only seems to happen with native system buttons (like the Aero glass ones), and not when we fully chrome the window and use WPF buttons as the title bar buttons. I'm not sure this is something we can control though because when a WPF Popup is open and you click those native title bar buttons, the system doesn't seem to register the click for some reason. However if you click on any WPF buttons or controls, those clicks are registered.
↧
KeyTipAccessText issues with multiple ribbons
Hey guys,
In our application we have multiple "modes" which are usercontrols with their own ribbon controls. When a user is in one mode, the others become collapsed. Unfortunately pressing alt to bring up KeyTipAccessText only seems to work on the main ribbon inside of the ribbon window. Once inside of a mode the ribbons do not respond to alt / f11 etc.
I am wondering if there is any way to make these key tips work? So far I have toyed around with the KeyTipService.SetIsKeyTipModeActive with no luck.
↧
Re: KeyTipAccessText issues with multiple ribbons
Hi Austin,
Only one Ribbon can be registered on a RibbonWindow at a time. What you could probably do when you want to switch, is remove the old Ribbon from the visual tree and add the new Ribbon into the visual tree. I think that will allow the new one to register itself instead.
↧
Re: KeyTipAccessText issues with multiple ribbons
This will be tricky since our secondary ribbons are buried in usercontrols, but I'll let you know how it goes when I get a chance to try to re-architect.
Thanks for the info.
↧
↧
Re: KeyTipAccessText issues with multiple ribbons
Housing the main ribbon in a grid and then swapping it out as needed works fine. Thanks again.
↧
KeyTipAccessText without pressing a button to get into the tab?
Hey guys,
We have several ribbons with only one tab with <ribbon:Tab height = 0> set to collapse the tab title. In order to get access keys for the controls within the ribbon the canonical method is to first have an access key on the tab and press that.
If there was any way to bypass having to press the access key for a tab to get to the keys of its controls that would be amazing.
↧
RibbonButton and Touch input
Hi,
I'm using ribbon buttons on a Windows 8 device with touch input.
I would like the ribbon button to change its checked-state when I click on it. For this I'm using the Click event where I set IsChecked = !IsChecked.
The problem: after unchecking the button, it remains highlighted - probably because the "mouse" pointer is still over the button.
How can I avoid this behavior?
Thanks
Mark
↧
Re: KeyTipAccessText without pressing a button to get into the tab?
Hi Austin,
All that is handled internally so there's no real extensibility points, since this isn't really a scenario we designed the product for. You might be able to set the KeyTipService.IsKeyTipScope attached property to false on the Tab. I'm not sure if that will do the trick for you or not but it's worth a try.
↧
↧
Re: 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?
↧
Re: RibbonButton and Touch input
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
↧
Re: KeyTipAccessText without pressing a button to get into the tab?
Unfortunately I tried that and afterwards none of the keys show up at all. Thanks though.
↧
Re: RibbonButton and Touch input
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?
↧
↧
Re: RibbonButton and Touch input
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.
↧
Re: RibbonButton and Touch input
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.
↧
Re: RibbonButton and Touch input
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
↧