Home › Forums › Software Development › EyeX in WPF application
- This topic has 4 replies, 2 voices, and was last updated 10 years, 2 months ago by Saad.
- AuthorPosts
- 18/07/2014 at 15:20 #1396SaadParticipant
Hi
I am using the EyeX SDK in a WPF application which contains “Activatable” interactors. I have several controls that act as activitable componenets in the UI.
My understanding is that all WPF controls that derive from FrameworkElement can be activatable. From this logic, it should be posible to have user controls act as activatables. However, I learned that having a Path (System.Windows.Shapes.Path which is not a FrameworkElemnt) inside my user control throws an InvalidCastException (Unable to cast object of type ‘System.Windows.Media.ContainerVisual’ to type ‘System.Windows.FrameworkElement’) at runtime, when the user control is looked at.
Now I have the following questions:
1. Is there a workaround for this exception or will I have to remove all non-FrameworkElement componenets from my user control?
2. Do I have the possibility to achieve the same using Gaze SDK?
3. Are there any other alternatives that I could explore to solve the stated problem?Thanks!
Saad22/07/2014 at 16:17 #1410Jenny [Tobii]ParticipantHi Saad,
I have tracked down the problem to a cast in the EyeXFramework.Wpf.WpfCrawler class. The purpose of the class is to hit test and traverse the VisualTree to find elements that are EyeX interactors. There is an incorrect assumption that all the child elements in the tree are derivates of FrameworkElement.
I consider this a bug in the EyeXFramework for .NET that should be fixed in the next EyeX SDK for .NET release. Since it might take a while until the next release, you might want to go ahead and implement some workaround yourself in the mean time. (Remember, the source code for the EyeXFramework for .NET is readily available in the SDK).
23/07/2014 at 08:49 #1413SaadParticipantHi Jenny
Thanks a lot. I’ll see what I can do and hopefully share the solution until the next release is available with a fix.
23/07/2014 at 13:39 #1417Jenny [Tobii]ParticipantHi Saad,
Since the bug was situated in the middle of a double recursive loop, I felt bad not providing a solution. So, I took a look at it, and this is a quick solution I came up with.
I have only tested that it works with the WPF samples included in the SDK. Please, replace the existing implementation of GetChildInteractorElements in EyeXFramework.Wpf.WpfCrawler with the following, and let me know if it works for your application or not!
private static IEnumerable<FrameworkElement> GetChildInteractorElements(DependencyObject parent) { for (int i = 0; i < VisualTreeHelper.GetChildrenCount(parent); i++) { var childDependencyObject = VisualTreeHelper.GetChild(parent, i); var childFrameworkElement = childDependencyObject as FrameworkElement; if (null != childFrameworkElement && childFrameworkElement.IsInteractor()) { yield return childFrameworkElement; } else { foreach (var grandchild in GetChildInteractorElements(childDependencyObject)) { yield return grandchild; } } } }
24/07/2014 at 12:00 #1423SaadParticipantHi Jenny,
I haven’t done a thorough testing but the changes you suggested seem to work at first go without any other changes to my application.
Thanks again for your help!
- AuthorPosts
- You must be logged in to reply to this topic.