Menu Control in Silverlight Needs Standardized Hide Behavior

I've created a menu control in Silverlight that consists of a menuitem class and a menuitem collection class. Each menuitem holds a menuitemcollection of subitems, so that I can easily build out a tree of menus. I need to know the best practice for hiding submenus. This menu should behave just like the menus in any Windows app. Should menu state be maintained in a separate class? Right now, I'm checking to see if the mouse pointer is in a submenu or its parent menu item, and if so, keeping it open. The problem is, I'm using the MouseEvent and the point from the MouseEventArgs, and if you move the mouse quickly, the values aren't tracked properly.

Anyway, what's a good practice for hiding nodes? Do you use recursion to close all the old submenus when the mouse moves onto a new parent node? Again, this is just the typical windows-app menu behavior. There must be an example of this somewhere. Thanks!

Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

adler77Connect With a Mentor Commented:
How are the mouse values not tracking properly? Are they just slow to update, or do they seem to be "off"?

You may just want to use MouseEnter and MouseLeave events. Generally, when I do this sort of menu (usually in JS, but same principle applies here), I set a MouseEnter for each menuitem. In this handler, it highlights the menuitem and expands it's child menu (if one exists). On MouseLeave for each menuitem, I unhighlight the menuitem and close any child menus. I also set MouseEnter and MouseLeave handlers for the child menu itself. The MouseLeave calls a timeout (or in the case of Silverlight, it should start a storyboard as a timer, with a Completed event) that will automatically close the child menu after a short period, maybe 100 - 200 ms. If either the child menu or the menuitem corresponding to the child menu is moused over again, the timer gets cancelled and the menu stays open.

There are a lot of JS menus out there, so it may be a good idea to base yours off of one of those. That will give you the primary structure to use, and you can modify it to use XAML instead of HTML code. If any of the above description doesn't make sense, let me know and I'll try to explain that part better.
electricstoryAuthor Commented:
Thanks, I made up a solution that seems to work well, and I used mouseenter and mouseleave instead of testing the bounds of the control. I composed a MenuItem class that holds a MenuItem collection class implementing IList<>. Each collection is responsible for its own animation behavior; on mouseenter, the menuitem digs down to find the terminal open node without children and then walks back up until it reaches its own node levels, initiating storyboard close animations behind itself.

The behavior you describe isn't exactly what I was looking for, but it's interesting to learn how other devs solve these problems. You're the only one who bothered to weigh in in a timely way, so the points are yours. Thanks!
All Courses

From novice to tech pro — start learning today.