Forum

Hi,

We have users of our software complaining that the file menu is slow to respond when they move the mouse over an arrow to open a submenu.  We have a ribbon bar and one of those big file menus with the MRU list beside it.  When they move the mouse over an arrow, the submenu is slow to appear, and I think also slow to go away once they move elsewhere.  They described it as "sticky".  I can see that there’s a delay on my machine, but it’s not bad for me.  Has anyone else reported this?

Is a timer used between moving the mouse over a submenu-arrow and the submenu appearing?  Is there a way we can get rid of this?  That is, set the time to zero?

I also notice even when moving the mouse from one item with a submenu to the next item which also has a submenu, the MRU list flashes up in between which is distracting.  This doesn’t happen in MS Word.

Another observation: if you move the mouse over the arrow in a split-item, and keep the mouse moving within the arrow button, the submenu never comes up, not till you stop moving.  On non-split submenus this doesn’t seem to happen.  Again, this doesn’t happen in Word.

Another thing: when moving the mouse over a split item, but on the item side rather than the arrow, the MRU remains rather than showing the submenu.  The submenu only comes up if the mouse is moved over the arrow.  In Word, the submenu comes up even when moving to the item part, not just the arrow.  I think this makes more sense as the user can see their other options more easily.

Finally, when the file menu is closed, it can take a very long time to fade out when the software is busy with other things, eg because you just selected a large file from the MRU list.  I presume you’re using a Windows timer to fade out, and restarting it each time.  But these timers can take much longer than requested when the process is busy elsewhere.  A better approach would be to use timers, but to test the real time elapsed when the timer event arrives and skip ahead if more time has passed.

Oh, and one more thing before I forget.  We also had complaints about unpinned control bars sliding in and out far too slow.  The same logic would apply here.  Skip ahead if more real time has passed rather than replying on timer events which can take orders of magnitude longer to return than requested.  Alternatively, is there a way we can get rid of the animation here and make them slide in/out instantly?

Thanks,

Rob.

This occurred in Prof-UIS 2.90. The HTML engine is used for painting both plain text and HTML everywhere. The bad performance is caused by massive CSS style computations performed even for each word in plain text. We already fixed this issue. You should re-download the latest Prof-UIS 2.91.

Just got some more info from the user having the problem.  In addition to the above...

(1) Once the mouse is on a submenu from the File menu, it becomes very unresponsive, with the highlighted item lagging well behind the mouse.

(2) The instinct all users seem to have (myself included) is to click on the submenu arrow if the submenu doesn’t appear straight away.  This doesn’t seem to reduce the delay before it appears though, and if clicked after the submenu appears, the whole File menu closes.  Very annoying.  I’ve reported this before long ago, and again, Word doesn’t do this.  People are clicking in an attempt to get the submenu to open, and instead it will sometimes (if they time it just as it’s appearing) close the whole menu instead.  I see no utility in that.

By the way, my earlier comments comparing with Word was for Word 2007.  Apparently Word 2010 doesn’t have any submenus on the file menu, so the comparison can’t be made.  It also seems to have a terrible full-window File menu, as if it wasn’t too big already!  I really hope you don’t implement that.

Thanks,

Rob.